Product Roadmap

OKRs — Objectives and Key Results

OKR stands for Objectives and Key Results — a goal-setting and leadership tool used by organisations to communicate what they want to accomplish and how they'll measure progress.

• Objectives — clear, ambitious, qualitative descriptions of what an organisation wants to achieve. Example: "Increase revenue by 20%."

• Key Results — specific, measurable, time-bound outcomes that indicate the successful achievement of the objectives. They are the measurable results needed to reach the objective.

OKRs are typically written with an Objective at the top and 3–5 supporting Key Results below:

"I will [Objective] as measured by [Key Results]."

Objective: Lose 10 kg over the next 6 months.

• Go to gym 4 times per week for next 24 weeks.

• Eat fewer than 2,000 calories per day for the next 24 weeks.

Objective: Increase revenue by 20% in the next quarter.

• Increase new users acquired by 10% every month.

• Increase Month 1 retention by 30%.

• Increase free-to-paid conversion rate by at least 10% this quarter.

When Conor Walsh joined Duolingo, the Duolingo Stories feature had been declining for months. Resources were tight and management was sceptical. Rather than starting with an Objective like "increase Stories traffic by 50%," Walsh set an OKR centred on deeply understanding their Stories users.

After hours of user interviews, the team identified that users found it challenging to use Stories on their phones. Enhancing the mobile experience became another Objective. After redesigning the entire UX, Stories users grew from fewer than 20,000 to more than 80,000 in just over a year.

Prioritisation

If you've put effort into brainstorming ideas, finding improvement opportunities, and collecting feedback, you'll have a roadmap full of good ideas. But the order in which you tackle them deserves just as much thought.

• It's satisfying to work on pet ideas you'd use yourself, instead of projects with broad reach.

• It's tempting to focus on clever ideas, instead of projects that directly impact goals.

• It's exciting to dive into new ideas, instead of projects you're already confident about.

• It's easy to discount the additional effort one project will require over another.

RICE Score

RICE is an acronym for the four factors used to evaluate each project idea: Reach, Impact, Confidence, and Effort.

• Reach — how many people will this affect within a given period? Measure in number of people/events per time period using real product metrics.

• Impact — estimated impact on an individual person. Use a scale: 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal).

• Confidence — your level of confidence about your estimates. 100% (high), 80% (medium), 50% (low). Be honest about how much support you have for your estimates.

• Effort — total time a project requires from all team members in "person-months". More effort is a bad thing.

MoSCoW Framework

The MoSCoW method categorises requirements into four groups:

• Must Have — critical to the current delivery timeline. Without even one, the project is considered a failure.

• Should Have — important but not absolutely necessary for current delivery. Second priority.

• Could Have — desirable but not necessary. Included if time and resources permit after Must Haves and Should Haves.

• Won't Have — lowest priority. Not implemented in the current delivery but may be reconsidered for future releases.

Note: these frameworks shouldn't be used as hard rules. Sometimes a lower-scored project needs to happen first as a dependency, or a feature is "table stakes" for certain customers. With a scoring system, you can clearly identify when you're making these trade-offs.

Product Roadmap

A product roadmap is a high-level visual summary that maps out the vision and direction for a product over time. It communicates the why and what behind what you're building — both a guiding strategic document and an execution plan for the product strategy.

• Describe the product vision and strategy.

• Provide a plan for executing the strategy.

• Align internal stakeholders around shared goals.

• Facilitate discussion and scenario planning.

• Communicate with external stakeholders like customers.

Roadmaps encapsulate how the product strategy becomes a reality. They help prioritise competing priorities and focus efforts on work that drives key metrics. Roadmaps inspire teams, provide shared ownership, and prevent chaos from unimportant tasks.

• Define the job(s) — list the core functional jobs/tasks your product helps customers get done.

• List desired outcome statements — for each job, list the outcomes customers want. Score each for importance and satisfaction to calculate an "opportunity score".

• Map features to outcomes — use MoSCoW to prioritise which features are essential to deliver each outcome.

• Package an MVP — group "Must" features into an initial MVP release solving the highest-opportunity outcomes.

• Plan releases — package additional features into future releases, focused on high-opportunity outcomes not addressed in the MVP.

Stakeholder Management

No one in the tech industry works in isolation, and no product is made in isolation. Product Managers connect teams, meet with many people, and — critically — manage stakeholders.

A stakeholder is anyone who has an interest or is involved in a product. In a tiny startup that might be seven people. As investors join, the pool grows. When acquired by a larger company, it gets much larger. Customers, PR companies, and stockists are all stakeholders.

Not all stakeholders are created equal. The CEO has the final say on high-level product decisions. Engineers have intimate day-to-day knowledge. The PM runs interference between all of them.

The goal of stakeholder management is alignment — ensuring everyone understands and agrees on three key aspects:

• The Vision — everyone has the same North Star and knows the desired outcome.

• The Outputs — everyone agrees on what the product does and how it works.

• The Outcomes — how users are supposed to feel about the product and how it fits into their lives.

• Stakeholder Mapping — a visual map of your stakeholder pool, showing who needs to be involved and when.

• Stakeholder Prioritisation — organise stakeholders into 4 groups by power and interest:

• High power, low interest → keep satisfied, routine reporting.

• High power, high interest → maximum effort, your highest priority.

• Low power, low interest → minimum effort, monitor.

• Low power, high interest → update regularly.

• Always Bring the Data — without data, you're just another person with an opinion. Come armed with more than just opinions when communicating with stakeholders.

• Be Human — remember stakeholders are people too. They have goals and things they need from you. Work out what those are and you'll know how to best relate to them.

Writing Product Requirement Documents (PRDs)

A PRD is a high-level document that outlines the features and attributes of the product you're working on. But more practically — it's how a PM communicates to every other team what needs to be built, why, and how it's supposed to work.

• The design team uses the PRD to understand what's required and come up with designs.

• The tech team uses the PRD and designs to understand what needs to be built.

• The marketing team looks at the PRD to understand the product and create campaigns.

A PRD is generally written once the problem has been identified and a solution has been thought of. It then evolves as other teams interact with it and add their inputs.

How to Write a PRD

• 1. Define the product — summarise your plan. State the product you'll create, the project team and stakeholders, and a tentative release date. Include the product's purpose and the pain points it alleviates.

• 2. Determine goals — write the team's objectives for the product development process. Generate SMART goals — specific, measurable, achievable, relevant, and time-bound — that serve as goalposts.

• 3. Identify assumptions and constraints — assumptions are known roadblocks you'll encounter. Constraints are unknown external pressures. Defining them upfront leads to more accurate final expectations.

• 4. Limit the scope of work — define what is and isn't within the project scope. Setting boundaries prevents scope creep and keeps the team on track.

• 5. List features — identify the product's primary features, describing how end users will use them. Describe each requirement in as much detail as possible. This section should be the most robust.

• 6. Define release criteria — identify the criteria that determine whether your product is customer-ready. This might include functionality, usability, and reliability.

• 7. Set metrics for success — decide on a methodology for approving work and ensuring quality. Track these metrics as you develop the product.