A few slides covering what a product manager does, what skills one needs to be a successful PM, and what methodologies one needs to master.

1. What does a Product Manager do?
And what is good product management about?
Product
Management Overview

2. Where do PMs sit?
“A good PM must be experienced in at least one, passionate about all three, and conversant with practitioners in all.”
Martin Eriksson, Founder, MindTheProduct

3. "Your job is to deliver a product that is valuable, usable and feasible."
Marty Cagan, Partner, Silicon Valley Product Group
Three things to remember:
1. Bring value to the users.
2. Bring value to the business.
3. Be the voice of the users.
What’s your job? (1)

4. What’s your job? (2)
Source

5. 5
A quick recap on the product life cycle
4D Product Development Model
1. Discover
2. Define3. Design
4. Deliver

6. 4D Product Development Model
A more structured approach to building products together
Define problem statement
- Map customer journey & pain points
- Identify root causes
- Define customer problem statement
and KPIs
Discover opportunities & insights
- Mix of Qualitative & Quantitative research
- Analyse feature data (funnel analysis etc.)
- Market research
- User research
- Customer development interviews
Design & test prototypes to reduce risk
- Brainstorm solutions (cross-functional)
- Cheap prototypes
- User testing
- Peer feedback
- Iterate at this stage and select final
solution to bet on
Deliver feature & measure
- User stories & acceptance criteria
- Plan and align for rollout
- Explore v2 iterations as needed
(Build, measure, learn)
1. Discover
2. Define
3. Design
4. Deliver
PM 50%
PD 30%
ENG 10%
DS 10%
PM 70%
PD 10%
ENG 10%
DS 10%
PD 50%
PM 25%
ENG 10%
DS 5%
ENG 75%
PM 10%
PD 10%
DS - 5%
PM - Product Manager
PD - Product Designer
ENG - Engineers
DS - Data Science
Note: Numbers are approximations

7. PMs:
1) WHY should you tackle a specific problem, market opportunity or feature? (business & user value, problem definition etc.)
2) WHAT feature shall we build? (what is the solution, what is the user journey, what are the user stories and acceptance
criteria etc.)
Note: The PM defines the WHAT collaboratively, leveraging the opinions of engineers, UX designers and other experts
around them.
Engineering teams have autonomy to decide:
1) HOW shall we implement this feature? Using what technology? What kind of architecture?
2) WHEN do we think we’ll be able to release this feature?
What do you do at a high-level?

8. Examples of outputs
Artifact Purpose
Pre-Launch
Initiative Doc (1-2 pages max) PM
(aka BusinessCase)
High-level proposal for a feature, including any user research to back it up and/or quantifying the potential commercial
opportunity.
Internal Roadmap PM
Can be outcome driven, but should ultimately also track features or work packages too. It is used internally to help plan ahead,
to update on progress and to spot & align dependencies.
External Roadmap PM Used externally to inform and align with stakeholders.
Product RequirementsDo
cument (PRD) PM
Contains the problem statement, business case, and high-level user flow together with high-level requirements such that the
engineering teams can start an and RFC based on it.
During its writing, product designers can do user testing with prototypes and PMs can align with engineers for input to write
better functional requirements.
ArchitecturalProposal (Request for Comments - RFC) EM For large, complex features, an architectural proposal should be written up and reviewed (RFC).
User stories and Acceptance Criteria
Can be written in Gitlab/Github or wherever the prioritised Backlog resides (close to the engineering team), or in Confluence.
Stories should be groomed with the eng team before sprint planning.
TBD: Tracking Specs Doc
UX Specs PD Final UX specs, to be reviewed with the engineers and amended as needed.
Bug bash To weed out any critical or high priority bugs before you actually run a pilot.
Pilot Plan
For large, complex features, a pilot should be run before A/B testing or rolling out, to weed out any defects and battletest the
solution ahead of scaling (e.g. IDMA, RTA)
Rollout& A/B Testing Plan PM
Details how the feature is going to be a/b tested, KPIs, what cities, how etc.
Also details the rollback thresholds as well as the rollout criteria and plan.
Feature Press Pack PM & PD
Used for informing subsidiaries. Presents the feature and its intended benefits (PM), it includes screenshots and details the
behavior (PD). Links to the external Roadmap and the Rollout & A/B Testing Plan (This can also include FAQs for Customer
Care)
PM = Product Manager
PD = Product Designer
EM = Engineering Manager

9. Roadmap Example – keep looking ahead

10. Helping shape high-performing teams
Agile methodologies:
- Build to learn, iterate, break things down into small increments (MVPs etc.)
- Ceremonies: Sprints, planning, stand-ups, retrospectives, demos
Additions:
- Team motivation & production vision
- Be the voice of the Users
- Everybody understands the Why behind What we’re building
Design thinking methodologies
- Together with the Product Designer or UX
designer
- Involving the engineering team early on

11. Depends on the type of the PM… but let’s look at a few Venn diagrams
Skills (1)

12. Skills (2)
Using agile
methodologies
Could be any gender, ofc.

13. Overlap with other roles?

14. Different market opportunities require different PM flavours
Optimizer PMs
Optimise existing features and funnels
Entrepreneurial PMs
Find product market fit and scale
Horizontal PMs
Build consistent customer journeys
Technical PMs
Build infrastructure that is fit for purpose
AI/Data PMs
Build data-driven products using ML

15. Three Core PM Jobs (Marty Cagan)
“1. Risks are tackled up front, rather than at the end.
These risks include:
- value risk (whether customers will buy it)
- usability risk (whether users can figure out how to use
it)
- feasibility risk (whether our engineers can build what
we need with the time, skills, and technology we have)
- business viability risk* (whether this solution also
works for the various aspects of our business—sales,
marketing, finance, legal, etc.).”
“2. Products are defined and designed
collaboratively, rather than sequentially.
In strong teams, product, design, and engineering work
side by side, in a give‐ and‐ take way, to come up with
technology‐ powered solutions that our customers love
and that work for our business.”
“3. It’s all about solving problems, not implementing
features.
Conventional product roadmaps are all about output.
Strong teams know it's not only about implementing a
solution. They must ensure that solution solves the
underlying problem. It's about business results.”
Source: Marty Cagan, Beyond Lean and &
Agile

16. Important things this presentation did not tackle
1. The importance of team building & motivation
2. Vision, Mission, Strategy, Objectives (VMSO doc)
3. Agile mindset & ceremonies
4. Fillings in gaps where needed (QA, rollout etc.)
5. Relationship with engineers
6. Relationship with stakeholders
7. Project and Program management
8. Customer centricity
9. Design Thinking
10. etc.

17. Thank You

18. Extra

19. Design Thinking (link)

20. Design Thinking

21. Design Thinking