This chapter is about the step where strategy becomes a plan of work: why the conventional features-and-dates roadmap systematically misleads, what structure replaces it (problem → key result → hypothesis → feature candidate, with time frames instead of ship dates), and how progress gets measured once "shipped on schedule" stops counting as success. It also covers the prioritization discipline that makes any of it real — naming the trade-offs and the explicit no — and the work most roadmaps hide: tech debt, compliance, and keep-the-lights-on capacity that has to be named and budgeted rather than squeezed in between "real" items.
In the sense most companies practice it, a Roadmap (Feature/Project List) is a prioritized list of features and projects handed down to product teams — and it is the artifact most companies mistake for strategy. It cannot do that job. A list can't adjudicate between competing priorities, because everyone advocating for their item on it already believes their item matters: "Every leader in the company thinks they know what's important. And none of them are wrong." The problem it's being asked to solve isn't prioritization in the first place — "We don't have a prioritization problem. We have a lack of focus problem." Only a real strategy, evidence-backed and sequenced and transparent about its reasoning, resolves that, and producing one is the business of Strategy, Vision, and the Decision Stack.
Leah Hickman's diagnosis of the failure is narrower and more useful than "roadmaps are bad." A roadmap that is just a list of ideas is harmless. The moment a date is attached to an idea, it stops being an idea and becomes a commitment, a promise, an expectation — made before discovery has validated anything. She has seen well-intended roadmaps destroy trust in a company because a single stakeholder was left with a missed expectation or a failed commitment. The antipattern is structural, not a matter of bad intent: the specific mechanical step is binding a date to an unvalidated idea.
From that root, Roadmap Antipattern Taxonomy catalogues the recognizable variants:
A close relative is authority standing in for validation. Christian Idiodi's example: an executive says build a Stripe integration; because it's the boss's idea the team assumes it must be good, builds it without testing value, and gets no signups. Value was assumed rather than tested.
The reason executives keep asking for the feature-and-date version is that it feels like control. Hickman calls this false control (Roadmaps as False Control): a team can deliver 100% of a roadmap on schedule and produce zero business impact if the underlying assumptions were wrong — "was that product team successful? No, the product team wasn't successful because the company failed." Her coaching response is not to ask executives to give up control but to relocate it: from picking features and dates to setting strategic context — objectives, vision, strategy, priorities, and the definition of success. Framed that way it isn't a loss, because demanding tactical control drags an executive into decisions builders are better positioned to make, which reduces rather than increases their real leverage.
The cheapest way to make all of this land in a room is Unused Roadmap Items Diagnostic Question: ask how many people have delivered a roadmap item that was never used by a single user. Most hands go up. It works less as an argument than as social proof — the audience experiences the failure mode instead of being told about it. And the cost isn't only commercial: engineers and product people are demoralized by shipping features nobody uses.
The replacement is not "no roadmap." It's a roadmap whose rows are outcomes rather than deliverables. Hickman's version of Outcome-Based Roadmap Reframing has four layers, read top-down: the problem or objective the team is chasing; the key results that define how success will be measured; the hypothesis — the team's current best guess at what will move that key result; and beneath it the specific bets, which are explicitly not commitments. Where an org already runs OKRs the mapping is direct: objective = the problem to solve, key results = the measurement of success, bets underneath. That framing matters politically, because it makes the roadmap the tactical layer beneath objectives the organization already owns rather than a competing artifact stakeholders have to be sold separately.
The naming at the bottom layer is deliberate. Items are feature candidates, not features or deliverables ("Feature Candidate" as Deliberate Anti-Commitment Framing): hypotheses to be tested against a key result, so that dropping or replacing one when it fails to move the metric isn't a broken promise. It's the same anti-promise instinct that governs dates in the next section.
Getting to that shape means inverting the default instinct to open a planning conversation with "what are we building." Working Backward Methodology runs the sequence problem → value proposition → measure of success → candidates to test, and the reason is stated bluntly: "If I give you the solution, you become a delivery team... If I give you the problem, I empower you." The closing checklist for any roadmap or backlog item is why it exists, what problem it solves, how success will be measured, and what evidence exists that it's valuable, usable, feasible, and viable.
Most organizations aren't ready to drop feature lists outright, and the material offers an explicit bridge rather than pretending otherwise. A Transitional Roadmap still lists features, but every item has to carry its "why" — the problem it solves, the value proposition, and the measure of success — with the intent of migrating items toward the fuller structure over time. The generalized rule behind it is Annotate Roadmap Items with the 'Why': never tell people what they're working on without telling them why, written concretely next to the deliverable ('building X to increase conversion, to increase revenue'). Hickman's point about this is organizational rather than motivational — even engineers handed a top-down, unvalidated solution still want the why, and its routine absence is a leadership communication failure, not disinterest from the delivery team.
Two practical entry points exist for teams inside companies that still issue feature roadmaps from above. Work backward from a scheduled feature to the underlying problem and success measure, then present that back as an outcome-based roadmap. And when a stakeholder hands down a named feature, hold a short discussion to extract the real problem behind it before building. Both convert a feature roadmap into an outcome roadmap without waiting for the company to formally adopt the operating model described in The Product Operating Model. The first triage question on any incoming request is whether it's keep-the-lights-on work or a genuine opportunity that deserves its own problem statement — the distinction the last section of this chapter takes seriously.
On adoption, Cagan is unsparing: almost no company actually does this, and most roadmaps still list features and dates even where leadership says it wants outcomes. His stated reason for bothering is a base rate — roughly 20% of features that get built actually solve the problem they were meant to solve — so naming a feature before discovery validates it locks in the wrong solution before anyone knows it's wrong. The ROI argument follows from that rather than from speed: releasing a capability is a means to an end, not success itself. "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."
One consequence worth carrying into every roadmap argument, from McCarthy and Appel: "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." Which means disagreement about what's on the roadmap is usually unresolved disagreement about the goals. Arguing the items treats the symptom.
The default position in this material is Hickman's: "I would never commit to a date. I'd commit to a time frame but I would not commit to a date." A fixed date forces a team to trade building the right thing against hitting the day; a time frame like "late Q2" leaves room for discovery to change the plan without breaking a promise (Commit to Time Frames, Not Fixed Dates). The underlying argument is that demanding a fixed date and a fixed valuable outcome from the same commitment is internally inconsistent — guaranteeing the date cannot structurally guarantee the outcome. She puts the choice to stakeholders directly: "Would you rather me deliver something that has no value by that date, or would you rather have me deliver something that has value to your customers... because you allowed me to have some time to build the right thing?"
Dates aren't banned, though. They're rationed. A High Integrity Commitment (High Integrity Commitment (HIC)) is a rare, explicitly labeled date commitment reserved for large initiatives, cross-team dependencies, and hard external constraints like a regulatory deadline or a contractual launch. It's legitimate only when two conditions hold: discovery and feasibility work has already been done, so the team can estimate honestly; and the commitment on scope comes from the builders, not from leadership. Leadership may fix the date; the delivering team determines what fits inside it. That inversion is the whole difference from the fixed-timeline antipattern, where a date is promised before discovery and scope is dictated downward. Hickman's framing: "You have to earn it though right, it doesn't come for free, you have to earn that." Practically, tag true commitments "HIC:" on the roadmap so a stakeholder can tell them apart from an ordinary feature candidate. The organizational counterpart is Blagoja Golubovski's disagree-and-commit standard — not everyone has to agree with a decision, but everyone commits to executing it once made: "Aligning people means everybody understands what we're doing... It does not mean that everybody agrees with it."
One genuine counter-case sits in the corpus and is worth holding onto rather than smoothing away. In hardware, the train model ("Train Model" (Hardware Release Cadence)) ships products on a fixed cadence — every six months, or once a year — and a feature that isn't ready misses the train and waits for the next one. The release date never slips for a feature. That inverts the software instinct to hold the release, and it works because manufacturing, supply chain, and retail windows make the date itself far more rigid than any single feature. The material is explicit that the logic doesn't automatically transfer to software, where the date is usually the more negotiable variable.
Dates also depend on honest progress tracking, and here Jason Fried's Hill Charts: Known/Unknown Progress Tracking (vs. Percent-Complete) does work no percentage can. The premise is that a project's work isn't uniform: the first half is dominated by unknowns, and only once the team is over the hill on the hard problem does the rest become straightforward execution. So progress is mapped as uphill (figuring out the approach), over the top (core unknown resolved), and downhill (known execution). Fried's argument against '25% done,' '80% done,' '90% done' is that the numbers are meaningless without knowing what's known versus unknown — the one remaining task could be the hardest, least understood part of the whole thing. The right measure is what's known and unknown, "not undone and not done." And the practical payoff is a specific warning: a team still stuck at the top of the hill with big unknowns unresolved and little time left before a deadline is in deep trouble, even though a task count would show the project as nearly finished.
Once shipping on schedule stops counting as success, something else has to. The starting move is to force the causal chain onto paper before anyone debates features: the Metrics One-Pager maps the organization's single top current business goal, then shows how the product and its sub-areas — acquisition, engagement, retention — connect to it. The sequencing is the point. The one-pager comes first and the roadmap is downstream of it. For marketplace businesses the anchoring sub-metric is usually the rate at which the two sides get successfully paired, since that's typically the proximate driver of the revenue goal.
OKRs are the mechanism by which a business strategy shows up as concrete targets for the product org (OKRs/KPIs as Business-Strategy Mechanism) — 'a third of revenue from Europe by year end.' Crucially, a strategy shift sets the target; it doesn't say what to build. Discovery determines what, if anything, the product needs to change to hit it. Cagan traces the tool back to Andy Grove's original intent: a mechanism for handing a team a problem plus a measure of success, then leaving the solution to them — not a personal goal-tracking ritual, which is how most companies now use it. Hence: assign OKRs to teams, not individuals. Palace Hotels is the concrete instance — a pilot team attached to a single measurable key result, the share of bookings made online versus through the call center, with funding and evaluation tied to movement on that one number rather than to a backlog. The recurring misconception to guard against is treating OKR adoption as the transformation itself; it's one piece nested inside a rethought whole, as Transformation in Practice shows repeatedly.
Predictive Indicators give this teeth. The idea is to find a leading metric tied directly to the top-line number leadership is already measured on, quantify it with the team, and then fund the team against moving it instead of against a feature spec. Gibson Biddle's Netflix example: rather than waiting years to see whether a change moved long-term retention, the team tracked the percent of customers watching 15+ minutes of streaming video per month as a faster-moving proxy plausibly predictive of the slow outcome, and optimized the proxy in the near term.
The management relationship this changes is captured in the Output-to-Outcomes Shift Triad: managing output → managing outcomes, funding projects → funding people (durable teams), directing solutions → empowering people to solve problems. Cagan restates the same shift in three vocabularies depending on the audience — output → outcomes for engineering and product, projects → products for PMO and program-management orgs, time-to-market → time-to-money for finance leaders. Christian's blunt version of why durable funding matters: "My job is to grow revenue... growing revenue is not a project." That line comes out of the 'Who Wakes Up Every Day to Grow Revenue?' Exercise — asking an executive team who specifically wakes up every day with the job of growing revenue. Executives claim ownership of the goal, but the question exposes that nobody is actually assigned to it daily; sales captures revenue already in the pipeline, it doesn't create new sources of it. The discomfort is the setup for assigning a dedicated team funded against a predictive indicator.
Stukan (CEO of Bizzy) adds the layer most teams skip. In Output → Outcome → Impact Framework, output is the thing built, outcome is the behavior or business result it drove, and impact is that outcome translated into the business's own financial or strategic language. Teams narrate output and outcome fluently and stop — 'improve onboarding so customers are less frustrated,' with no revenue or acquisition tie-in. Stukan traces a historical cause: product management once sat closer to outcomes, bundling product, packaging, sales and go-to-market, then drifted toward backlog and delivery execution as a separate function, severing the line to business impact. Tamar Yehoshua states the same bar as a hiring and performance lens — did the work actually get used, and did it make the whole organization more productive, not whether the task was technically completed.
One guardrail on all of this, also from Stukan: precise attribution of revenue to a single team's work is "a waste of time" (Revenue Attribution Futility (Attribution Fights)). A customer may need roughly twelve touch points before signing up, spanning marketing, product, design and engineering; no function can isolate its share. In larger orgs, attempts at precision degenerate into attribution fights between departments. The alternative isn't precision — it's connection: show how the work maps to top-level goals via the one-pager, and communicate in output/outcome/impact terms rather than defending a dollar figure.
Explicit Trade-off Prioritization sets the bar: real prioritization names four things, not one — what you will do, what you explicitly will not do, what gets delayed, and which competing goal you're consciously choosing over another (growth over retention, say). Ranking everything 'high' is not prioritization. Golubovski's diagnostic is the sharpest test in the chapter: "If you cannot really articulate the downside of a decision, you don't have a decision. If all the decisions look good, you're not making a decision." And his read on why leaders dodge it is uncomfortable — avoiding an explicit no protects relationships, not the business.
He extends the critique to the tooling. RICE scoring, opportunity trees, and continuous discovery loops get named as things teams hide behind instead of doing the harder work of judgment and ownership: the framework becomes a way to defer the accountable call rather than a tool that produces one. He notes a cultural variant in Europe specifically, where citing 'the right framework' functions as a credibility signal that spares a leader the more uncomfortable admission — 'I don't know, but here's the bet.'
Martin Eriksson names the exact move executives use to escape a trade-off, quoting a CEO's objection: 'the problem with you guys is that you're an OR organization and we're an AND organization' ('OR Organization' vs. 'AND Organization' (Trade-Off Avoidance Framing)). An AND organization declares competing priorities equally important and pursues all of them; an OR organization accepts finite resources and forces the choice. 'Equally important' is how the discomfort of ranking gets avoided.
The counters in this chapter are all structural rather than rhetorical — they make the AND move unavailable rather than argue against it.
Underneath the roadmap, Product Backlog (Prioritized List with Deletion Discipline) carries its own discipline: every addition should result in a deletion. A backlog that only grows isn't being curated; treat its shrinking, not its length, as the signal of progress.
Two smaller failure modes round this out. Yehoshua names a near-universal PM bias — believing your own feature deserves top billing in the UI, with the counter "well no, you got to earn that right" (PM Self-Promotion Bias in Feature Placement); prominence is justified by demonstrated value, not by authorship. And Julia Barham's "Don't Scale Chaos" (Leader-as-Bottleneck Mistake): a leader who remains the single person making every trade-off and priority call as the team grows "scales chaos" instead of scaling the product, because the org's capacity is capped by how many rooms one person can be in. Her fix is to replace personal judgment calls with durable artifacts — written decision criteria, SLAs and bug-severity rubrics that let anyone triage consistently as volume grows, self-service dashboards so people can answer questions without routing through the leader. The political dimension of all this — how the no actually gets delivered and survives — belongs to Stakeholder Power and Trust.
A team's real workload splits three ways (Three Buckets of Product Work: New, Existing, Protect Value): new value (net-new bets), existing value (improving what already ships), and protect value (compliance, security, tech debt). The third is chronically underestimated and routinely hidden from stakeholders during a transformation, because it produces no visible feature and is easy to defer — until dependencies and unaddressed debt become "the root of all evil" for delivery slowness and undermine the transformation's ability to show results even when discovery is going well. Reporting only on new-value work looks fast right up until protect-value debt catches up. Strategy is commonly misread as being only about what's next; protecting current revenue and the current customer base is itself a strategic choice, not something that happens by default while attention goes elsewhere.
The budgeting rule is separation. Separating Keep-the-Lights-On Work from Strategic Focus says operational maintenance and tech debt should be tracked as a distinct, always-funded bucket that continues regardless of which strategic bets won the quarter's argument — they aren't competing bets, they're the baseline cost of keeping the product running. Practically that means tracking the percentage of team time spent on KTLO as its own metric, and never letting the focus conversation implicitly starve it. Compliance is the standing example of work miscast as an emergency: "you're a bank — like, why is a request from a regulator always a panic? You haven't strategically understood that to be a bank you need to respond to regulatory requests and changes in compliance."
Barham's Four Slices of the Pie (Product Portfolio Balance) is the same instinct at portfolio level: innovation and strategic bets, optimization, capability/platform work, and production support or 'run the business.' Some teams deliberately reserve roughly 20% of capacity for the production-support slice up front, so it can't be silently starved by the other three — budgeting an otherwise-inevitable interruption as a planned line item. A related capacity distinction is Building to Learn vs. Building to Earn: experiments where being wrong is cheap and expected, versus operational-excellence work meant to be stable, performant and revenue-generating where being wrong is expensive. Holding experiments to production-reliability bars, or revenue-critical systems to move-fast tolerances, misapplies the wrong standard to each — and naming the split is what stops discovery quietly losing to the delivery work that's visible on the ledger.
None of this budgeting can happen while the debt is invisible, which is why Marcus Castenfors states First Rule of Tech Debt as plainly as he does: the first rule of tech debt is talking about it — openly, in planning and stakeholder conversations, quantified — rather than hiding it as underground work squeezed between 'real' roadmap items. Debt hidden from stakeholders becomes debt stakeholders never fund. A useful diagnostic for how far a transformation has actually progressed: whether a product manager can pitch tech debt as a compelling business initiative standing alongside an engineer. If tech-debt pitches are always engineer-only, product hasn't genuinely taken shared ownership of protecting value, whatever the stated intentions.
Three framings help make the funding case:
The calibration comes from Pioneers, Settlers, Town Planners, which Barham uses to argue against overengineering and underengineering at once: pioneers explore unvalidated territory and should build cheaply and fast; settlers make a validated idea repeatable and maintainable; town planners industrialize the mature, high-scale parts. Don't build town-planner-grade architecture under a pioneer's untested desirability — but equally, don't leave a settler- or town-planner-stage system running on pioneer-era shortcuts once its costs are known.
Finally, Car/Vehicle Analogy for Transformation Readiness gives the whole audit a shape: the destination is the vision, the steering wheel is product vision and strategy, the engine is the technology including debt and dependencies, and team topology is whether the vehicle fits the road ahead. Good strategy alone gets an org nowhere if the engine is broken or the vehicle is the wrong shape. Ask "do you have the vehicle to accomplish your vision" as a distinct diagnostic step, checking engineering health, debt, dependency load and topology fit.
A plan degrades unless something forces it to be re-derived. Two cadence models in this chapter do that at different altitudes.
Tom Verrilli's Play the Accordion (Alternating Zoom-Out/Zoom-In Cadence) describes healthy product rhythm as alternating between zooming out — planning, learning, revisiting strategy — and pressing in to ship against what was just decided. The framing is explicitly aimed at two failure modes at opposite extremes: pure blind iteration that never zooms out to re-plan, and long fixed roadmaps that never zoom back in. Neither end is the virtuous one; the alternation is.
Gibson Biddle's Four-Quarter Rolling Roadmap applies the same idea at portfolio cadence. The roadmap always covers four quarters: the near-term quarter or two carry high-confidence, largely committed projects, while the out-quarters are explicitly provisional and expected to change. Rather than a fixed annual plan, it rolls forward each quarter, re-deriving the far-out contents from what was learned in the near term. That's how a roadmap stays honest about uncertainty without abandoning near-term commitment.
The review meeting is where output-thinking most quietly reasserts itself, and 'Did You Do X' to 'How Did You Do X' Review Shift is the correction: move product and design reviews from status questions ('did you ship it,' 'is it done') to process questions ('how did you validate it, what did you test, with which user, what did you learn, what's the next action'). The status version rewards completion; the process version makes a team narrate its judgment and its evidence, which is what actually builds a reviewer's trust in that team's decision-making over time. The catch is on the reviewer: it only works if they can sit with "we learned it didn't work" without treating that as a status failure.
Reviews also have to survive scale, and Yehoshua's account of Slack's OKR process is the concrete case (Async OKR Review via Video Clips). Live per-team review meetings ballooned to roughly 300+ hours across the org — a quantified trigger, not a vague sense that the process felt heavy — which forced a redesign. Teams instead submitted a written doc plus a time-limited Slack Clips video walking through their OKRs; leadership triaged each with a red/yellow/green flag; and only the highest-priority or most-flagged teams, on the order of five to ten, got a live follow-up. Within status reporting, only red at-risk items were discussed live, protecting meeting time for real problems. A quick clarifying question got resolved in a Slack Huddle in minutes rather than a scheduled meeting. The information value survives — every team still reports, every status still gets seen — while synchronous time is reserved for exceptions.