Prioritize and build an outcome-based roadmap
Arbitrate between streams of work from measurable outcomes and publish a Now, Next, Later roadmap that owns its uncertainty.
Arbitrate between several streams of work based on the outcomes you are after, not on the list of requested features. You learn to tell outputs, product outcomes and business outcomes apart, to write OKRs that actually help, to pick the right prioritization method for the right question (RICE, ICE, Kano, opportunity scoring, cost of delay and WSJF) while knowing their limits, to handle requests from sales and other stakeholders, to say no without closing the door, then to publish a Now, Next, Later roadmap that owns its uncertainty, is reviewed on a fixed rhythm and uses AI to synthesize inputs without handing it the judgement. You finish with your product's roadmap, tied to measurable outcomes.
What you will be able to do
- Tell outputs, product outcomes and business outcomes apart, and phrase a team's goal as a measurable change in behavior it can influence.
- Write useful OKRs (a qualitative objective, measurable key results, guardrails) and spot their common failure modes.
- Choose and apply a prioritization method suited to the question at hand (RICE, ICE, Kano, opportunity scoring, cost of delay, WSJF), taking its limits into account.
- Handle requests from sales, support and leadership starting from the problem behind them, and say no or not now with reasons.
- Build a Now, Next, Later or theme-based roadmap tied to measurable outcomes, with external commitments shown separately.
- Communicate uncertainty and dates according to horizon and audience, and review the roadmap on a written rhythm and set of triggers.
- Use AI to synthesize roadmap inputs (feedback, requests, data) while keeping evidence traceable and the decision human.
Prerequisites
- Have already maintained a backlog or helped build a roadmap, with an engineering team
- Know the basics of RICE and the Now, Next, Later format; this course goes further and does not repeat those introductory calculations
- Recommended course before this one: Design and Validate a Product Experience with AI, which introduces the backlog, RICE, MoSCoW and the outcome roadmap on a single case.
- To define and instrument metrics, see the course Instrument a product and use data to make decisions; to measure the effect of a bet, the course Design and analyze an A/B test.
Syllabus
What will I be able to do by the end of this course, and in what order?
- Course overview3 steps
Objective · By the end of this overview, you will know what you are going to produce (your product's roadmap, tied to measurable outcomes), which trade-offs Nadia has to make at Atelio throughout the course and which five modules take you there.
What does my team need to move, and how do I write it so everyone aims at the same thing?
Objective · By the end of this lesson, you will be able to tell an output, an adoption metric, a product outcome and a business outcome apart, and rewrite a feature list as a chain that links the target business outcome to the behavior changes your team can achieve.
Objective · By the end of this lesson, you will be able to write a team OKR whose objective names a customer problem and whose key results are quantified product outcomes with a guardrail, and to spot in a set of OKRs the failure modes that make it useless.
Out of all the possible bets, which ones come first, and with which method?
Objective · By the end of this lesson, you will be able to choose the prioritization method that answers the question at hand (compare ideas, quickly sort experiments, compose an offering, find underserved needs), apply it to real data and say what it does not see.
Objective · By the end of this lesson, you will be able to estimate the cost of delay of several streams of work and its urgency profile, order them with CD3 or WSJF, and spot the fixed deadlines these calculations do not show.
How do I handle requests from sales, support and leadership without losing either direction or trust?
Objective · By the end of this lesson, you will be able to turn a feature request into a quantified problem (who, what, how many, what is at stake), record it in a single log, and organize how stakeholders are kept informed according to their role.
Objective · By the end of this lesson, you will be able to answer a request with a principled no, a “not now” with a criterion or a conditional “yes, if”, and to have a lasting disagreement settled by the right person, with quantified options.
How do I present my choices so they guide the team, reassure stakeholders and stay honest about uncertainty?
Objective · By the end of this lesson, you will be able to build a Now, Next, Later or theme-based roadmap in which each line links a problem, a target outcome, bets, a success criterion and a confidence level, to show external commitments separately, and to derive one version per audience.
Objective · By the end of this lesson, you will be able to answer a request for a date according to horizon and audience (firm date, range, no date), to show a confidence level for each line, and to set up a review rhythm and review triggers recorded in a change log.
Objective · By the end of this lesson, you will be able to have an AI group customer feedback and requests into counted, sourced problems, check that synthesis on a sample, and keep the trade-offs and their justification for yourself.
How do I assemble and defend my own product's roadmap?
Objective · By the end of this lesson, you will have assembled your product's Now, Next, Later roadmap, tied to measurable outcomes and justified by your trade-offs, you will have self-assessed it with a grid, and you will leave with an exit kit and a 7-day and 30-day application plan.