--- name: product-roadmapping description: Build and communicate a product roadmap that survives change: outcomes rather than feature lists, Now-Next-Later confidence horizons, dates only where they are genuinely fixed, and a format matched to the audience. Covers the "Enable [segment] to [outcome] so that [impact]" statement and the swap test, the Now cap of two to three items sized to six to eight weeks, confidence decay across horizons, the portfolio mix by product stage, a feature-factory diagnostic, and a script for when leadership demands dates. Use it when someone says build a roadmap, now-next-later, quarterly or product plan, turn this feature list into outcomes, my roadmap is just a feature list, or leadership wants dates. Do NOT use it to rank or score which items to build (see prioritisation-frameworks), or to plan a single launch's messaging and channels, which is go-to-market work. --- # Product roadmapping A roadmap is a statement of intent and confidence, not a delivery schedule. The most common roadmap failure is attaching high precision, an exact date, to low confidence, a far-off idea, and then watching the whole company read that date as a promise. This skill makes an AI agent build a roadmap that survives contact with reality: outcomes rather than feature lists, confidence horizons rather than a Gantt chart, dates only where they are real, and a format matched to who is reading it. It sequences and communicates the work; it does not rank it. Ranking is the prioritisation-frameworks skill, and a good roadmap starts from its output. ## When to use this skill, and when not to Use it when someone needs to lay out what the product will work on and in what order, communicate direction to a team or to stakeholders, turn a prioritised backlog into a plan, convert a feature list into outcomes, or decide whether a roadmap should carry dates. Use it when someone says build a roadmap, now-next-later, quarterly plan, my roadmap is just a feature list, leadership wants dates, or our roadmap keeps slipping. Do not use it to decide which items are worth doing or to produce their rank order; send that to the prioritisation-frameworks skill and build the roadmap from the result. Do not use it to plan the mechanics of a single launch, the messaging, the channels, the launch-day checklist; that is go-to-market work. Do not treat a roadmap as a project schedule: if what is wanted is a dated plan of committed deliverables with dependencies, that is delivery planning, and forcing it into a roadmap is how roadmaps become broken promises. ## What the agent must have before starting Ask for whatever is missing, and do not invent direction: 1. The goals or outcomes the product is trying to move this period, ideally as measurable targets, not a list of features someone already picked. 2. The prioritised candidate work, or an agreement to prioritise it first, so the roadmap sequences a real order rather than a wish list. 3. The product's maturity stage (pre-product-market-fit, growth, or mature), because it changes how much of the roadmap should be near-term bets versus long-term exploration. 4. Who will read the roadmap, exec, sales, customers, or the engineering team, because the same roadmap is communicated differently to each. 5. Which dates, if any, are genuinely fixed: a contractual deadline, a regulatory date, a dependency on another team, a launch tied to an event. Everything else stays a horizon, not a date. If someone hands you a dated feature list and asks you to "make it a proper roadmap", the first move is to separate the goals from the features and ask which outcome each feature is meant to produce. If a feature cannot name an outcome, that is the finding, not a blocker. ## The workflow ### Step 1: Start from outcomes, not outputs For each roadmap item, write the outcome in the form: "Enable [segment] to [outcome] so that [business impact]". Then test it with a "so what?" chain: a feature leads to what changes for the user, which leads to which number moves, which leads to what the business gets. If an item cannot complete the chain, it is an output masquerading as a plan. Reject outcome statements that start with an output verb, build, launch, migrate, ship, because those name the drill, not the hole. Run the swap test on the finished set: read three outcome statements aloud. If you could swap them between items and no one would notice, they are too generic; push the "so what?" two or three levels deeper until each is specific to its item. ### Step 2: Choose the roadmap format from the audience and the certainty - **Now-Next-Later** (confidence horizons): the default for most products and for communicating direction under uncertainty. The columns are not time buckets in disguise; they are confidence levels. Now = validated, actively worked, the problem is well understood. Next = big bets broken down from Later, discovery narrowing the options. Later = strategic problem areas not yet shaped, where confidence is lowest on purpose. - **Outcome or theme roadmap**: when leadership needs to see the strategy, group work under outcomes or themes (one measurable result each) rather than features. A theme is a step up from a feature list; an outcome with a target is better still, because it does not pin you to one solution. - **Timeline or Gantt**: legitimate only for the slice of work where dates are real, launches, contractual commitments, hard dependencies. Use it for those items and keep the rest on horizons. A timeline roadmap turns every date into a commitment, so only put a date there when you would accept being held to it. Match to the reader: engineers need the Next detail and dependencies; executives need the outcomes and the one or two real dates; sales and customers need direction and the committed items, clearly separated from the exploratory ones. ### Step 3: Let confidence decay with distance, and keep precision and confidence on separate axes Near-term items (Now): high confidence, specific, may carry a date range if one is real. Middle (Next): directional, quarter-grained at most, no hard dates. Far (Later): thematic, "we intend to work on this area", no dates and deliberately metric-light, because false precision on a far item costs you credibility when it moves. The rule that prevents most roadmap damage: never attach a precise date to a low-confidence item. Precision and confidence are different things; the failure is pairing a high-precision date with a low-confidence idea. ### Step 4: Size the Now column honestly Cap Now at two to three items, each sized to roughly six to eight weeks of work. More than three Now items means the commitment level is false and the column is a backlog in disguise. A long Now column is the clearest sign of weak prioritisation; if it is long, the prioritisation is not done, so return to the prioritisation-frameworks skill before continuing. The whole roadmap should fit on one or two slides or screens; if it does not, raise the level of abstraction or split it by team. ### Step 5: Balance the portfolio to the maturity stage Mix near-term certain work with longer-term bets according to stage, as a starting point to adjust: - Pre-product-market-fit: roughly 70% near-term, 20% medium, 10% long bets. - Growth: roughly 40% / 40% / 20%. - Mature: roughly 20% / 30% / 50%, more investment in the future because the present is stable. A roadmap that is 90% or more short-term work is a red flag at any stage: it means the team is shipping and not investing. Also balance item types: incremental wins, big bets, and table-stakes work that merely keeps parity. All three belong; a roadmap that is all table-stakes builds nothing that differentiates. ### Step 6: Sequence by dependency and by learning Order within and across horizons by two things, not one. First, hard dependencies: what must exist before what. Second, learning: front-load the cheap work that reduces the most uncertainty, a spike, a prototype, a fake-door test, so that a dead hypothesis is killed before it costs a quarter. Do not fill capacity to 100%; leave slack, because slack absorbs the discovery you have not planned for yet. Tie each item to an outcome so that if a hypothesis dies, the item can be dropped without the plan collapsing. ### Step 7: Set the communication and the re-planning cadence Decide the review rhythm (monthly or per sprint for Now, quarterly for the horizon) and the off-cadence triggers that force a re-plan (a bet invalidated, a new constraint, a missed target). State plainly that the roadmap is direction and confidence, and that any firm promise is a separate, deliberate, rare "high-integrity commitment" made after discovery, when the business genuinely needs a date. The clean line to give stakeholders: the roadmap communicates direction; OKRs or explicit commitments communicate what is promised. ## Worked example Input: a dated feature list from leadership, "Q1: SSO, dark mode, AI assistant; Q2: mobile app, SOC 2; Q3: integrations". Stage: growth. Audience: exec and engineering. Step 1 separates goals from features and asks the outcome of each. SSO and SOC 2 both serve "enable enterprise buyers to approve us so that we can close up-market deals", and SSO has two signed contracts behind it, so it carries a real date. Dark mode cannot complete the "so what?" chain beyond "users asked", so it is flagged as an output. The AI assistant is a big bet with no validation. The rebuild: a Now-Next-Later with one real date. Now (two items, high confidence): SSO, dated to the signed contracts; and the activation bet that came top of prioritisation. Next: SOC 2 (directional, this half), and a scoped discovery spike on the AI assistant to test whether anyone would use it before committing a quarter. Later (thematic): "deeper enterprise readiness" and "mobile presence", no dates. Dark mode moves to the backlog with a note that it lacks an outcome. The exec view shows the outcomes and the single SSO date; the engineering view shows SSO and the activation work in detail with dependencies. The output is a roadmap where one date is a promise the team made on purpose, and nothing else reads as a commitment it cannot keep. ## Templates you can use verbatim Outcome statement: "Enable [segment] to [outcome] so that [business impact], measured by [metric: baseline to target]." Now-Next-Later skeleton: - Now (validated, in progress, 2 to 3 items, ~6 to 8 weeks each): outcome, metric, counter-metric. - Next (discovery narrowing, directional, this quarter or half): outcome, open question. - Later (strategic areas, no dates, metric-light): theme, the problem we believe matters. "Leadership wants dates" script: "I can commit a date on [the one or two items we have validated and are willing to be held to]. For the rest, a date would be a guess dressed as a promise. Here is the direction and the confidence level of each, and here is the trigger that will turn a Later item into a dated commitment." ## Failure modes and anti-patterns 1. **The feature factory.** Shipping measured as success with little discussion of impact; teams cannot connect their work to a business or customer metric; features exist because a big customer or sales demanded them and success is a signed contract. Spot it: outcome statements that are really a dated feature list, or standup notes that name only features. Fix it: force every item through the "so what?" chain and drop the ones that cannot complete it. 2. **Dates as commitments by accident.** A tidy timeline of future features reads as a set of promises to everyone outside the team, and then every slip is a broken promise. Spot it: precise dates on items that have not been through discovery. Fix it: move uncertain work to horizons, reserve dates for genuinely fixed commitments, and say which is which. 3. **The bloated Now.** Six items in the Now column, none truly committed. Spot it: a Now column longer than three items or that will not fit on a slide. Fix it: prioritise properly, cap Now at two or three, and push the rest to Next. 4. **Interchangeable outcomes.** Outcome statements so generic they could belong to any item. Spot it: the swap test fails. Fix it: deepen the "so what?" chain until each statement is specific, with its own metric and target. 5. **The frozen roadmap.** Built once, never revisited, still driving work after the assumptions behind it died. Spot it: no review cadence and no re-plan triggers. Fix it: set the rhythm and the off-cadence triggers in the roadmap itself, and treat a dead hypothesis as a signal to re-plan, not a failure to hide. ## Quality bar Before handing over a roadmap, confirm: every item names an outcome that completes the "so what?" chain and passes the swap test; no item starts with an output verb; the format matches the audience; confidence decays with distance and no low-confidence item carries a precise date; the Now column holds no more than two or three items and the whole thing fits on one or two slides; the portfolio mix fits the maturity stage and is not 90% short-term; items are sequenced by dependency and by learning value with slack left in; and the review cadence and re-plan triggers are stated. The roadmap should make clear, to anyone who reads it, what is a committed promise and what is a direction held with stated confidence. A roadmap is a communication tool and a plan of intent; publishing a date is a commitment a person makes deliberately, and only a person should make it. ## Tool appendix - **ProdPad, Aha!, Productboard, Roadmunk**: all support Now-Next-Later or outcome views natively; use the horizon or theme view, not the timeline view, unless you are showing the dated slice. Keep the outcome and metric fields filled, not just the item title. - **Jira / Linear roadmaps**: these lean toward timeline and epic-date views, which pull you back toward dates-as-commitments. If you must use them, treat the dates as internal planning only and communicate externally from a separate horizon view. - **Slides or a doc**: often the best external roadmap, because it forces the one-or-two-slide discipline and keeps the reader on outcomes rather than tickets. Export the horizon view to slides for stakeholder and sales audiences. - No tool enforces outcomes or honest confidence; those are yours to maintain. A tool that auto-generates a Gantt from tickets will happily produce the exact roadmap this skill warns against. ## Sources - ProdPad glossary, "Now-Next-Later Roadmap" (Janna Bastow, who created it), prodpad.com. Last verified 10 November 2026. - ProductPlan, "Outcome-Driven Roadmaps", productplan.com/learn/outcome-driven-roadmaps. Last verified 10 November 2026. - Marty Cagan / SVPG, "The Alternative to Roadmaps" (business results, high-integrity commitments). Last verified 10 November 2026. - Itamar Gilad, "Your Roadmap Isn't Really a Roadmap" (adaptive, goal-driven roadmaps, the confidence meter). Last verified 10 November 2026. - John Cutler, writing on the feature factory (success theatre, work disconnected from metrics). Last verified 10 November 2026. - Teresa Torres, continuous discovery and opportunity framing (outcomes over outputs). Last verified 10 November 2026. --- 1.0.0, 10 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for your own product judgement.