A technique for converting stakeholder feature requests into problem/outcome statements before they enter a Roadmap (Feature/Project List). For each incoming request, first triage: is this keep-the-lights-on work (see Separating Keep-the-Lights-On Work from Strategic Focus), or is it a genuine opportunity that needs its own problem statement? If it's the latter, reframe the ask as the underlying problem or outcome to solve, rather than accepting the stakeholder's specific requested feature at face value.
This reframing is what keeps a Product Model (vs. Roadmap Model) org from silently reverting to a feature-request roadmap: stakeholders are still heard, but their input becomes an input to problem discovery (see Discovery (Product Discovery Process)) rather than a commitment to build the literal thing they asked for.
At Palace Hotels, the product-model shift redefined team success as the intersection of customer happiness and business viability, replacing a model where teams were handed a 'list of futures to build' and success meant shipping the list. See Product Model (vs. Roadmap Model) for the outcome metrics this produced (booking conversion <1% → >5%).
Leah Hickman's version of the outcome-based roadmap has four layers, read top-down:
Dates are replaced by Commit to Time Frames, Not Fixed Dates rather than fixed ship dates. This is the mechanism by which the roadmap stops converting ideas into promises — see Roadmap (Feature/Project List) for why that conversion is the root failure of traditional roadmaps, and Roadmaps as False Control for why executives should let go of feature-level control in exchange for this structure.
When an org already runs OKRs, an outcome-based roadmap maps directly onto that structure: objective = the problem to solve, key results = how success will be measured, and feature candidates (see "Feature Candidate" as Deliberate Anti-Commitment Framing) sit underneath as unvalidated solution ideas, not commitments. Presented this way, the roadmap becomes the tactical layer beneath objectives the organization already owns, rather than a competing artifact stakeholders have to be sold on separately.
This reframing is reinforced by a blunter fact: a team can ship 100% of a feature roadmap on schedule and the company can still go out of business — on-time delivery and business success are decoupled metrics, and only the outcome side (the key result) tracks the one that matters. Also worth remembering: no one hands a PM a mandatory roadmap template — the objective/key-result/feature-candidate shape is one way to structure it, not a prescribed format.
Real transformation ROI isn't "we shipped a capability faster." Releasing a capability is a means to an end, not success itself. Reframe the ROI conversation around the cost of continuing to ship the wrong thing: fewer wasted quarters, fewer political escalations, less burnout, and clearer prioritization — not raw delivery speed.
"Releasing a capability is not success... releasing a capability is a means to an end."
"Maybe the better question is what's the cost of continuing to ship the wrong thing?... maybe the ROI is not faster delivery. The ROI is fewer wasted quarters, fewer political escalations and less burnout, and better clarity on what we're doing." — Leah Hitman
See Unused Roadmap Items Diagnostic Question and Value as Totality of Experience, Not Feature Count.
Even inside companies still run on stakeholder-issued feature roadmaps, a team can work backward from a scheduled feature to the underlying problem and success measure it's meant to address, then present that back as an outcome-based roadmap — a practical entry point into Discovery (Product Discovery Process) without waiting for the company to formally adopt the Product Model (vs. Roadmap Model).
Even when stakeholders hand down a feature request, hold a short discussion to extract the real underlying problem and success measure behind it before building. That reverse-engineering step is what converts a feature roadmap into an outcome roadmap, even when the inputs still arrive as named features.
Cagan claims almost no company actually does this — most roadmaps still list features and dates even when leadership says they want outcomes. His stated reason: only roughly 20% of features that get built actually solve the problem they were meant to solve, so committing to a feature by name, before discovery validates it, locks in the wrong solution before you know it doesn't work. An outcome-based roadmap item names the problem/outcome to hit and leaves the solution open until discovery has tested it.
A roadmap is not a list of features and dates — it's a reflection of goals and objectives. Because of this, disagreement over what's on a roadmap is usually a symptom of unresolved disagreement over the underlying goals, not a disagreement about the roadmap items themselves. Arguing about roadmap contents without first resurfacing and aligning on goals treats the symptom rather than the cause.
Quote: "a road map is not a list of things to do, it's not a list of deliverables, it's not a bunch of features with dates — it's a reflection of your objectives, it's a reflection of your goals." (McCarthy & Appel)