Outcome Roadmap

Outcome Roadmap Expert

The agent transforms output-based roadmaps ("build feature X") into outcome-driven roadmaps ("enable customers to achieve Y") using the "so what?" technique and Now/Next/Later framing. It produces roadmaps that communicate strategy and measurable impact, not just feature lists and dates.

Workflow

1. Gather Current Roadmap Items

The agent collects the existing roadmap -- features, projects, or initiatives -- in any format (list, spreadsheet, JSON, or prose).

Validation checkpoint: Each item must have at least a name and a brief description. If items are just feature names with no context, the agent asks for the problem each feature is meant to solve.

2. Transform Each Item

The agent applies the transformation formula:

"Enable [customer segment] to [desired customer outcome] so that [business impact]"

For each feature, the agent uses the "so what?" chain to find the real outcome:

"Build advanced search"
  -> So what? "Users can find products faster"
  -> So what? "They spend less time browsing and more time buying"
  -> So what? "Conversion rate increases, reducing acquisition cost per sale"

The last answer is the outcome. The agent works backward to write the outcome statement:

Output: "Enable power users to find relevant products in under 5 seconds so that conversion rates increase by 20%"

Validation checkpoint: Every transformed item must answer Who benefits, What changes for them, and Why it matters to the business.

3. Categorize into Now / Next / Later

Validation checkpoint: "Later" items should NOT have detailed metrics or specific solutions. Forcing detail on uncertain items creates false precision.

4. Add Success Metrics

For each Now and Next item, the agent defines 2-3 measurable indicators:

• Primary metric: Directly measures the desired outcome
• Secondary metric: Captures a different dimension of success
• Counter-metric: Prevents perverse optimization (optional for Next items)

5. Identify Dependencies

For each item, the agent documents:

• Technical prerequisites (APIs, infrastructure, data)
• Organizational prerequisites (team capacity, stakeholder buy-in)
• Market prerequisites (customer demand signal, competitive timing)

6. Review with Stakeholders

The agent produces a stakeholder-ready roadmap document for alignment review.

Validation checkpoint: Walk stakeholders through the outcome roadmap. If anyone asks "but when exactly will this ship?", redirect to commitment levels -- Now items have dates, Later items do not.

Example: Roadmap Transformation

Input (output-based roadmap):

{
  "initiatives": [
    {"name": "Build advanced search", "quarter": "Q2"},
    {"name": "Launch mobile app", "quarter": "Q3"},
    {"name": "Add Slack integration", "quarter": "Q3"},
    {"name": "Redesign dashboard", "quarter": "Q4"}
  ]
}

$ python scripts/roadmap_transformer.py --input roadmap.json

Outcome Roadmap Transformation
==============================

NOW (In Progress):
  Original: "Build advanced search"
  Outcome: "Enable power users to find relevant products in under 5 seconds
            so that conversion rates increase by 20%"
  Metrics:
    - Search-to-purchase conversion: 12% -> 15%
    - Avg search time: 18s -> 5s
    - Counter: Maintain search result relevance score above 0.8
  Dependencies: Elasticsearch cluster upgrade, product taxonomy cleanup

NEXT (1-3 Months):
  Original: "Launch mobile app"
  Outcome: "Enable field sales reps to close deals on-site so that
            average deal cycle shortens by 30%"
  Metrics:
    - Mobile-originated deals: 0% -> 15% of total
    - Avg deal close time: 14 days -> 10 days
  Dependencies: API v2 completion, mobile auth infrastructure

  Original: "Add Slack integration"
  Outcome: "Enable teams to act on alerts without context-switching
            so that mean response time drops by 40%"
  Metrics:
    - Alert-to-action time: 25min -> 15min
    - Alerts resolved in Slack: 0% -> 60%
  Dependencies: Webhook infrastructure, Slack app approval

LATER (3-6 Months):
  Original: "Redesign dashboard"
  Problem area: Users report dashboard is overwhelming and they
                can't find the metrics that matter to their role.
  Strategic intent: Role-based views that surface relevant data,
                    reducing time-to-insight.
  Dependencies: User research (not yet started)

Why Output Roadmaps Fail

Output roadmaps create three problems:

1. False precision -- Dates promise certainty that does not exist. When dates slip, trust erodes. 2. Misaligned teams -- Engineers optimize for shipping features. Product optimizes for impact. An output roadmap makes these goals invisible to each other. 3. Lost context -- Six months later, nobody remembers why "advanced search" was important. The feature ships, but the problem it solved may have changed.

The outcome roadmap solves these by anchoring every item to customer value and business impact, with commitment levels that match certainty.

Output Structure

For each initiative, the transformed roadmap includes:

1. Original Initiative -- What was on the old roadmap 2. Outcome Statement -- "Enable [segment] to [outcome] so that [impact]" 3. Success Metrics -- 2-3 measurable indicators 4. Dependencies -- Technical, organizational, or market prerequisites 5. Strategic Context -- Connection to company objectives or OKRs

Tools

Troubleshooting

Success Criteria

• Every roadmap initiative has an outcome statement answering Who benefits, What changes, and Why it matters
• Now items have full outcome statements with 2-3 measurable success metrics and dependencies documented
• Next items have outcome statements with draft metrics (no counter-metrics required)
• Later items have problem statements and strategic intent only (no false-precision metrics or solutions)
• Stakeholders understand and accept the commitment level framework (Now = high, Next = medium, Later = low)
• Roadmap is reviewed quarterly with stakeholders to validate horizon placement
• Output-to-outcome transformation reduces "when will it ship?" questions by 50%+

Scope & Limitations

In Scope:

• Transforming output-based feature lists into outcome-driven roadmap items
• Now/Next/Later horizon classification based on quarter-to-current-date distance
• "So what?" chain generation for each initiative
• Strategic question prompts and metric suggestions by initiative type (feature, improvement, infrastructure)
• Markdown and text report output with grouped-by-horizon formatting

Out of Scope:

• Feature prioritization or scoring (see execution/prioritization-frameworks/)
• Detailed sprint-level planning or capacity allocation (see scrum-master/)
• Product strategy or vision definition (outcome roadmaps communicate strategy, they do not create it)
• Dependency management across teams (see program-manager/)

Important Caveats:

• Outcome roadmaps require a cultural shift. Teams accustomed to date-driven feature lists need coaching on commitment levels.
• The tool generates outcome statement templates, not finished outcomes. The templates must be filled in with real customer and business data.
• Later items intentionally lack detailed metrics. Adding false precision to uncertain items undermines the roadmap's credibility.

Integration Points

Tool Reference

roadmap_transformer.py

Transforms output-based roadmap initiatives into outcome-driven format with horizon classification, strategic questions, and metric suggestions.

Supported initiative types: feature, improvement, infrastructure

References

• references/outcome-roadmap-guide.md -- Detailed guide with comparison, formulas, and stakeholder strategies
• assets/outcome_roadmap_template.md -- Roadmap document template with Now/Next/Later sections

Outcome Roadmap: [Product/Team Name]

Owner: [Name] Last Updated: [YYYY-MM-DD] Strategic Theme: [One sentence describing the overarching goal for this period]

---

Now

Commitment Level: High -- team assigned, scope defined, work in progress.

Initiative 1: [Title]

Outcome Statement:

Enable [customer segment] to [desired customer outcome] so that [business impact].

Success Metrics:

Team: [Assigned team or individuals] Dependencies: [What must be true for this to succeed?] Strategic Connection: [How does this connect to company OKRs or strategy?]

Initiative 2: [Title]

Outcome Statement:

Enable [customer segment] to [desired customer outcome] so that [business impact].

Success Metrics:

Team: Dependencies: Strategic Connection:

---

Next

Commitment Level: Medium -- direction set, scope flexible, subject to learnings from Now items.

Initiative 3: [Title]

Outcome Statement:

Enable [customer segment] to [desired customer outcome] so that [business impact].

Draft Metrics:

• [Metric 1]
• [Metric 2]

Open Questions:

• [ ] [What do we need to learn before committing?]
• [ ] [What dependencies need to be resolved?]

Initiative 4: [Title]

Outcome Statement:

Enable [customer segment] to [desired customer outcome] so that [business impact].

Draft Metrics:

• [Metric 1]
• [Metric 2]

Open Questions:

• [ ] [Question]

---

Later

Commitment Level: Low -- strategic intent only, no solution defined.

Opportunity Area 1: [Problem/Theme]

Problem Statement: [What customer or business problem are we considering?] Why It Matters: [Strategic rationale for keeping this on the radar] Signals to Watch: [What would cause us to move this to Next?]

Opportunity Area 2: [Problem/Theme]

Problem Statement: Why It Matters: Signals to Watch:

---

Initiative Transformation Worksheet

Use this to convert output-based items to outcome-based items.

---

Success Metrics Tracker

---

Change Log

Example: Transforming Pylon's Q3 Roadmap from Output to Outcome

Real-world scenario showing how to transform a feature-list roadmap into Now/Next/Later outcomes.

Context

Pylon is a Series-A vertical SaaS for industrial-equipment service teams (~120 customers, $4M ARR). The current Q3 roadmap is a feature list: "Build offline mode", "Build SSO", "Build mobile native". The CEO has been asking, "what will be different for customers if we ship this list?" and the team has struggled to answer.

The PM (Hugo Aalto) is transforming the roadmap from output-heavy to outcome-driven before the next exec review on 2026-05-29. The team needs Now/Next/Later horizons, clear outcomes, and measurable indicators.

Inputs

• Current Q3 roadmap: 11 features in a flat list with quarter tags
• Customer feedback triage output (see customer-feedback-triage/) -- 12 deduped opportunities
• North Star Metric (input metric tree available)
• Engineering capacity: 80 days for Q3
• Quarterly objective: "Make Pylon stickier for the field-tech segment"

Applying the skill

1. Gathered the current output-based roadmap -- 11 features. 2. Applied the "so what?" chain to each. Several features collapsed to the same outcome ("Build offline mode" + "Build conflict resolution" + "Build mobile native" all roll up to "Field techs can work without connectivity at customer sites"). 3. Categorized into Now / Next / Later based on commitment level and stage of validation. 4. Added success metrics for Now and Next items (2-3 per item). 5. Identified dependencies -- offline mode depends on the data-platform change to support local cache. 6. Reviewed with the CEO -- the question "what's different for customers?" now has a one-sentence answer per row.

Key decision quoted: "'Later' items do not have detailed metrics. If we knew the metrics with precision, they would not be Later -- they would be Next."

The artifact

````markdown

Pylon Q3-Q4 Outcome Roadmap (v1)

PM: Hugo Aalto As of: 2026-05-22 Quarter: Q3 2026 (start 2026-07-01) + Q4 outlook Quarterly objective: Make Pylon stickier for the field-tech segment

How to read this roadmap

• Format: Enable [segment] to [outcome] so that [business impact]
• Each item answers: Who benefits, What changes for them, Why it matters to the business
• Now items have dates and detailed metrics; Later items do not (by design)

NOW (in flight or starting in next 2 weeks)

N1 -- Enable field technicians to access and update work orders without connectivity, so that we are usable at the 40% of customer sites with no coverage

• Source features (output): offline mode, local cache, conflict-resolution
• Outcome: A field tech can pick up a job at the dispatch shop, drive to a remote customer site, log work, mark the job complete, and sync when back in coverage -- with no "you're offline" failure
• Success metrics:
• Primary: % of work orders completed at low/no-coverage sites without sync errors (target: 95%)
• Secondary: Median session duration on mobile while offline (target: > 12 min)
• Counter: Sync-conflict rate per 100 jobs (target: < 5%)
• Owner: Mobile + Data Platform squads
• Status: In design; eng start 2026-06-01
• Dependency: Data Platform local-cache schema (see dependency-map/)
• Commitment: Locked for Q3 ship

N2 -- Enable dispatch supervisors to reassign jobs in fewer clicks, so that urgent reassignments don't lose 5 minutes per job

• Source features: re-assign UX, list-view tech filter
• Outcome: Dispatcher sees job queue + tech assignments in one view; reassignment is 2 clicks
• Success metrics:
• Primary: Median time-to-reassign (target: < 30s from 90s baseline)
• Secondary: Reassignment volume per dispatcher per day (no change expected; behavior change isolated)
• Counter: Reassignment-revert rate (target: < 10%)
• Owner: Web squad
• Status: In flight; design done; eng start 2026-05-26
• Commitment: Locked for Q3 ship

N3 -- Enable customers to share work-order status with stakeholders who don't use Pylon, so that we stop being a single-tenant tool

• Source features: shareable status link, audit log
• Outcome: Customer admin can generate a read-only link, send to their stakeholder, see view count
• Success metrics:
• Primary: % of workspaces generating >= 1 share link in 30 days post-launch (target: 40%)
• Secondary: Recipient NPS (target: >= 30)
• Counter: Share-link revoke rate within 7 days (target: < 15%, indicates regret)
• Owner: Web + Platform squads
• Status: In design; eng start 2026-07-01
• Commitment: Locked for Q3 ship

NEXT (1-3 months out)

X1 -- Enable enterprise admins to manage user access via their existing IDP, so that we close $80k+ deals we are currently losing on security review

• Source feature: SSO (Google, Okta, Azure AD)
• Outcome: Workspace admin connects their IDP; new users provision automatically; deprovisioning is instant
• Success metrics (draft):
• Primary: # of accounts with SSO enabled (target: 25 by end of Q4)
• Secondary: Sales deals closed citing SSO as enabler
• Counter: User-confusion tickets on SSO setup
• Owner: Web + Auth squads
• Status: Discovery + RFC; build start 2026-08-15
• Commitment: Direction set; scope flexible (which IDP first?)

X2 -- Enable dispatch supervisors to bulk-edit job priorities, so that morning re-prioritization takes 2 minutes instead of 25

• Source feature: bulk-edit priority
• Outcome: Dispatcher selects multiple jobs, changes priority in one action
• Success metrics (draft):
• Primary: Median time-per-morning-re-prioritization (target: < 3 min from 25)
• Counter: Bulk-edit revert rate
• Owner: Web squad
• Status: Refining; eng start 2026-09-01
• Commitment: Direction set

X3 -- Enable customer admins to customize job-status taxonomy, so that we fit enterprise workflows without forcing them to compromise

• Source feature: custom job-status per workspace
• Outcome: Admin defines custom statuses; reports adapt; UI honors customer terminology
• Success metrics (draft):
• Primary: # of workspaces using custom statuses (target: 30)
• Secondary: Enterprise deal cycle days (looking for reduction)
• Owner: Web squad
• Status: Discovery -- needs validation with the 3 enterprise accounts requesting
• Commitment: Direction set; scope undefined

LATER (3-6 months, problem space only)

L1 -- Enable field technicians to update jobs via their phone's native app instead of mobile web

• Source feature: native iOS + Android app
• Outcome (problem): Mobile web has friction; native may unlock offline-first UX patterns
• Status: In strategic radar; will validate after offline mode (N1) ships -- if N1 solves the core problem, native may not be needed
• Commitment: Strategic intent only; no scope, no metrics yet

L2 -- Enable customers to integrate Pylon with their existing CMMS

• Source feature: API + webhook integrations
• Outcome (problem): Several enterprise prospects use SAP, Maximo, IBM Maximo; Pylon as a silo is a deal-killer
• Status: Strategic radar; validated by 2 sales conversations, not yet enough for Next
• Commitment: Strategic intent only

L3 -- Enable Pylon to surface predictive failure indicators to dispatchers

• Source feature: ML-based predictive maintenance
• Outcome (problem): Could be a differentiator; needs data volume we don't yet have
• Status: Far horizon; depends on offline mode and integrations to gather enough data
• Commitment: Watch only

Output-to-outcome transformation table

Dependencies (across horizons)

Risks

What this roadmap is NOT

• A delivery commitment beyond Now items.
• A feature wish-list ordered by squeaky wheel.
• A timeline for each output.
• A guarantee that Later items will ever ship.

How we use this with stakeholders

Review cadence

• Weekly: PM updates Now item status
• Monthly: Re-review Now -> Next transitions; new Later items added
• Quarterly: Full re-validation; promote Later -> Next; demote Next -> Later if needed
• Strategy change: Trigger full re-derivation

````

Why this works

• The "so what?" chain collapses 3 features into 1 outcome (N1), which prevents shipping "offline mode" without "conflict resolution" and calling it done.
• Now items have specific dates and metrics; Later items have only problem statements. The discipline of NOT pre-committing Later metrics is rare and valuable.
• The output-to-outcome transformation table is preserved as a translation key so anyone asking "where did feature X go?" can find it.
• Each item names exactly who benefits, what changes for them, and the business impact -- the CEO's "what's different for customers?" question now has a one-row answer.
• The "what this roadmap is NOT" section heads off Sales pressure to commit Now-level dates on Next items.

What's next

• Pair with ../north-star-metric/ -- ensure every Now outcome maps to an NSM input metric.
• Use ../brainstorm-okrs/ to translate Now outcomes into Q3 KRs.
• Pair with ../prioritization-frameworks/ (RICE) when promoting Next -> Now.
• Use ../roadmap-communication/ for the stakeholder-specific variants (exec, sales, customer).
• Use ../dependency-map/ for the cross-team dependencies (N1 + N3).

Outcome Roadmap Guide

A detailed reference for building outcome-driven roadmaps that communicate strategy, not just feature lists.

---

Output vs Outcome Roadmap

Side-by-Side Comparison

Why Outcomes Win

When a roadmap says "Build advanced search in Q2," the team ships advanced search in Q2. Success. But if customers do not use it, or it does not improve conversion, was it actually a success?

When a roadmap says "Enable customers to find products 50% faster," the team might build advanced search. Or they might improve navigation. Or they might add better categorization. The outcome is fixed; the solution is flexible. If advanced search does not work, the team can pivot without declaring failure.

---

Outcome Statement Formula

Enable [customer segment] to [desired customer outcome] so that [business impact]

Breaking It Down

[Customer segment]: Who specifically benefits? Be precise. "Users" is too broad. "New users in their first week" or "Enterprise admins managing 50+ seats" is specific enough to design for.

[Desired customer outcome]: What changes in the customer's experience? This should be something the customer would recognize and value. "Find products in under 5 seconds" -- a customer understands this. "Improved search indexing" -- a customer does not care about this.

[Business impact]: Why does the business care? Connect to a metric: revenue, retention, cost, market share, competitive position.

Examples

---

The "So What?" Technique

The most powerful tool for finding outcomes. Start with the feature and keep asking "so what?" until you reach something a customer or executive would care about.

Example 1

"Add CSV export"
  -> So what?
"Users can get their data out of the system"
  -> So what?
"They can share reports with stakeholders who don't have accounts"
  -> So what?
"Decision-makers see the data, which accelerates deal approvals"

Outcome: "Enable users to share insights with external stakeholders
          so that deal approval cycles shorten by 2 weeks"

Example 2

"Implement caching layer"
  -> So what?
"Pages load faster"
  -> So what?
"Users experience less friction during peak hours"
  -> So what?
"Abandonment rate during high-traffic periods decreases"

Outcome: "Enable users to complete transactions without slowdowns during
          peak traffic so that peak-hour abandonment drops below 5%"

When to Stop

Stop when you reach a statement that satisfies both: 1. A customer would nod and say "yes, that matters to me" 2. A business leader would say "yes, that moves a metric I care about"

If only one is satisfied, keep asking.

---

Time Horizon Recommendations

Now / Next / Later

This framework replaces calendar quarters with commitment levels.

Now (0-6 weeks)

• Team is actively working on this or will start within 2 weeks.
• Scope is defined. Solution is chosen. Dependencies are identified.
• Detail level: Full outcome statement, specific metrics, assigned team.
• Commitment: "We are doing this."

Next (6 weeks - 3 months)

• Direction is clear. Solution may still be flexible.
• The problem is validated, but the approach may change based on learnings from "Now" items.
• Detail level: Outcome statement with draft metrics. Team identified but not fully assigned.
• Commitment: "We intend to do this, subject to learning."

Later (3-6 months)

• Strategic opportunity or problem area identified.
• No solution chosen. May be reframed based on what we learn.
• Detail level: Problem statement or opportunity description. No solution details.
• Commitment: "We are thinking about this."

Why Not Quarters?

Calendar quarters create two problems:

1. False precision: "Q3" implies a specific 3-month window. But 6 months out, you cannot predict scope, dependencies, or team availability with any reliability. The date becomes a promise you cannot keep.

2. Rigidity: When a Q2 item slips to Q3, the entire roadmap shifts. With Now/Next/Later, items move between horizons based on strategic priority, not calendar math.

---

Success Metrics for Outcome Roadmaps

Every outcome needs 2-3 metrics that tell you whether the outcome was achieved.

Metric Types

Leading indicators: Predict future success. Measurable quickly. Examples: sign-up rate, feature adoption in first week, NPS after onboarding.

Lagging indicators: Confirm actual impact. Take longer to materialize. Examples: revenue change, churn rate, market share.

Counter-metrics: Ensure you are not achieving the outcome at the expense of something else. Examples: if you increase sign-ups, track activation rate to make sure quality is not dropping.

Metric Selection Checklist

• [ ] Is this metric directly influenced by the initiative?
• [ ] Can we measure it within the quarter?
• [ ] Do we have a reliable baseline (current value)?
• [ ] Would improving this metric genuinely indicate success?
• [ ] Is there a counter-metric to catch unintended consequences?

---

Stakeholder Communication Strategies

For Executives

Executives want to know: "Are we making progress toward our strategic goals?"

• Lead with outcomes, not features.
• Show metrics: baseline, target, current progress.
• Use Now/Next/Later to show strategic sequencing.
• Highlight dependencies and risks, not task-level status.

For Sales Teams

Sales wants to know: "What can I tell customers is coming?"

• Share "Now" items as commitments. Be specific about what customers will experience.
• Share "Next" items as direction. Use language like "We are investing in [outcome area]."
• Do not share "Later" items. They change too frequently.

For Engineering Teams

Engineers want to know: "What problem am I solving and how will I know I succeeded?"

• Lead with the outcome statement and success metrics.
• Share the "so what?" chain so engineers understand the full context.
• Let engineers propose solutions. The outcome is fixed; the approach is theirs.

For Customers

Customers want to know: "Will this product keep solving my problems?"

• Share themes, not features. "We are investing in making collaboration faster" is better than "We are building real-time editing."
• Use outcome language: "You will be able to [desired outcome]."
• Never share dates unless you are confident. Missed dates destroy trust faster than vague timelines.

---

Roadmap Review Cadence

Red Flags: Outcome Roadmap

Common ways this skill's output goes wrong — concrete examples, why they're bad, and how to fix them.

How to use this document

Scan the transformed roadmap before sharing with stakeholders. Each red flag shows the bad version next to the good version, anchored to the Now/Next/Later commitment-level framework and the "so what?" technique.

---

Red Flag 1: Outcome-themed but output-driven

Symptom. Each roadmap item has the "Enable [X] to [Y] so that [Z]" template at the top. Underneath is a feature list with dates. The team operates against the feature list; the outcome statement is decorative.

Why it's bad. The roadmap looks outcome-driven to executives but engineering treats it as a feature backlog with extra prose. The outcome statements add overhead without changing decisions. Worst, stakeholders think the team is outcome-driven when it isn't.

Bad example:

"Now: 'Enable users to find products faster, so conversion improves.' Underneath: 'Ship advanced search by July 15. Ship filter dropdown by July 22. Ship saved searches by July 29.' Team meetings focus on the dates; conversion is never measured."

Good example:

"Now: 'Enable power users to find relevant products in under 5 seconds, so conversion rate increases by 20%.'

Success metrics: Search-to-purchase conversion 12% → 15%; avg search time 18s → 5s.

Working hypothesis: ship Elasticsearch upgrade + relevance tuning (NOT a fixed feature list); measure conversion after 2 weeks; if not moving, change tactic.

Standup question: 'are we moving conversion or just shipping features?'"

How to catch it. Read the team's standup notes. Do they reference the outcome metric or the feature names? If only the feature names, it's output dressed as outcome.

---

Red Flag 2: Missing measurement

Symptom. Now items have outcome statements but no success metric ("Enable users to be productive" — measured how?).

Why it's bad. Without measurement, the outcome cannot be validated. The team ships the work and declares success based on what they did, not on what changed. The team learns nothing about whether the work actually delivered value.

Bad example:

"Now: 'Enable customers to make better decisions, so they can grow their business.' (No measurable indicators.)"

Good example:

"Now: 'Enable mid-market retailers to choose merchandise mixes that match their store traffic patterns, so they reduce overstock by 25%.'

Primary metric: overstock value per store per month, from $42k to $32k.

Secondary: % of stores using the new merchandising tool weekly, from 0% to 60%.

Counter: stockout rate stays below 4% (don't trade overstock for stockout).

Owner of the metric pull: BI team; reporting cadence: weekly."

How to catch it. For each Now item, does the success metric have a baseline and a target with a date? If no, measurement is missing.

---

Red Flag 3: Now items > 3

Symptom. Now column lists 8 active initiatives.

Why it's bad. A team that has 8 "Now" items has 0 priorities. Now is supposed to be high-commitment, fully-scoped work — capped at what the team can ship in 6-8 weeks. 8 items means most are not real; they will not all ship; the column lies about commitment.

Bad example:

"Now (Q3): 8 initiatives, each with team assignment. (Reality: 4 are starting; 3 are aspirational; 1 was bumped down from last quarter.)"

Good example:

"Now (Q3, capped at 2-3): 'Improve mid-market activation' (active) and 'Reduce enterprise onboarding friction' (starting Aug 1). Others are Next. Cap enforced because activation experiments take 6-8 weeks each; more Now items means we're not really running any of them seriously."

How to catch it. Count Now items. > 3 = the commitment level is false.

---

Red Flag 4: Later items with detailed scope

Symptom. Later column has full feature lists, mockups, P0/P1/P2 designations, dates.

Why it's bad. "Later" is strategic intent only. Adding precision to uncertain items creates false confidence. Stakeholders read the detail and commit emotionally to it; when reality forces a different choice, trust erodes ("you promised this!").

Bad example:

"Later (Q1 2027): 'Mobile app redesign — 14 P0 features, mockups linked, ship date Mar 15, success metric DAU +25%, owner Sarah K, eng estimate 8 weeks.'"

Good example:

"Later (3-6 months out, intentionally vague):

'Mobile experience deserves a refresh — current mobile NPS is 22 vs web 45, suggesting a gap. We are tracking 'mobile abandonment' as a leading indicator. In Q4 we'll decide whether to invest in mobile-app redesign or mobile-web optimization or both, based on the experiment in Q3.'

(No mockups. No P0/P1. No dates. No success metric beyond directional intent.)"

How to catch it. Read Later items. Search for: dates, mockup links, P0/P1, specific feature counts. Each is false precision.

---

Red Flag 5: "So what?" chain stopped too early

Symptom. Original initiative was "Build advanced search". After 1 "so what?", the team wrote: "users can find products faster". They wrote that as the outcome and moved on.

Why it's bad. "Find products faster" is still an activity-level outcome ("user does X faster"). The business outcome — what changes for the company — is 2-3 "so whats" further: conversion rate, revenue, retention. Stopping early produces user-experience-level outcomes that may not connect to business impact.

Bad example:

"Original: 'Build advanced search.'

So what? → 'Users find products faster.'

Outcome: 'Enable users to find products faster.'"

Good example:

"Original: 'Build advanced search.'

So what? → 'Users find relevant products faster.'

So what? → 'They spend less time browsing without buying.'

So what? → 'Conversion rate increases, reducing acquisition cost per sale.'

Outcome: 'Enable shoppers to find relevant products in <5 sec, so conversion rate increases from 12% to 15%.'"

How to catch it. Count "so what" iterations. If only 1, push 2-3 deeper to reach a business metric.

---

Red Flag 6: All outcome statements sound the same

Symptom. "Enable users to be productive so the business grows." "Enable customers to use the product so revenue increases." "Enable teams to collaborate so they have better outcomes." Each item has the template applied mechanically.

Why it's bad. Generic outcome statements are worse than honest feature lists. They imply outcome thinking without doing the work. The team can't differentiate priorities; stakeholders can't tell what's important.

Bad example:

"Now 1: 'Enable users to be more productive, so we grow revenue.'

Now 2: 'Enable customers to succeed, so they retain better.'

Now 3: 'Enable teams to collaborate, so they have better outcomes.'"

Good example:

"Now 1: 'Enable mid-market sales leaders to cut pre-call research from 90 minutes to 10 minutes, so their reps spend 80% of their day in customer conversations instead of preparing for them.'

Now 2: 'Enable enterprise admins to provision new users in under 2 minutes (currently 18 minutes), so their average time-to-first-team-value drops below 24 hours.'

Now 3: 'Enable hybrid teams to see who is working on what without joining a sync meeting, so async teams stay aligned with 30% fewer meetings.'

(Each outcome names specific segment, specific job, specific number.)"

How to catch it. Read 3 outcome statements aloud. If they could be swapped between items without anyone noticing, they are too generic.

---

Red Flag 7: Stakeholders keep asking "when exactly?"

Symptom. Every roadmap review, the same question: "but when will [X] actually ship?" Team explains commitment levels; stakeholder is unsatisfied.

Why it's bad. Repeated date questions signal the commitment-level framework hasn't been internalized. Stakeholders may have been trained by years of date-driven roadmaps; switching to Now/Next/Later requires re-education they have not received.

Bad example:

"Review meeting #4. Sales VP: 'I know it's "Next" but when will the API actually ship?' PM: 'commitment level is medium; we don't have a date.' Sales VP: 'I need a date for the customer.' [Repeat every quarter.]"

Good example:

"Quarterly roadmap kickoff: 30-min education for stakeholders on the commitment-level framework. Slides cover: 'Now = high commitment, dates available'; 'Next = direction set, dates approximate'; 'Later = strategic intent, no dates'. Followed by Q&A. Sales VP receives a separate 'sales-ready commitments' artifact showing only Now items with firm dates plus Next items with date windows (e.g. 'Aug-Oct'). The wide-window dates are firm enough to commit to customers conservatively."

How to catch it. If the same date question recurs 3 reviews in a row, the framework hasn't been taught.

---

Red Flag 8: Roadmap re-shuffled mid-quarter

Symptom. Now column on July 15 looks completely different from Now column on June 15. Items appear and disappear; no one tracks why.

Why it's bad. A roadmap that re-shuffles mid-quarter has no commitment level — Now is just "whatever we're working on this week". Teams cannot plan against it. Stakeholders cannot rely on it. The artifact becomes a vanity board.

Bad example:

"June 1 Now: A, B, C. July 1 Now: A, D, E. (B and C silently moved; D and E appeared with no note.)"

Good example:

"Now items locked for the quarter at kickoff. Mid-quarter changes require a documented decision: 'Removed item C on July 5 because user research invalidated the assumption; replaced with item D approved by VP Product.' Changelog at the bottom of the roadmap doc; reviewed at the monthly roadmap-review meeting."

How to catch it. Compare Now column at quarter start to mid-quarter. Each addition/removal should have a documented reason. Silent swaps = no commitment level.

---

Red Flag 9: Roadmap as project plan

Symptom. Roadmap is a Gantt chart with engineer names, hours, weekly milestones. 27 dependencies marked.

Why it's bad. This is a project plan, not a roadmap. Roadmaps communicate strategy and outcomes to a broad audience. Project plans communicate scheduling to the working team. Conflating them produces a document too detailed for executives and too high-level for engineers.

Bad example:

"'Outcome roadmap': 32-row Gantt chart with engineer assignments, hourly estimates, dependency arrows, daily milestones. Shown to the board."

Good example:

"Outcome roadmap (strategic, for execs/customers/cross-functional): 3 Now / 4 Next / 5 Later items with outcomes and success metrics. No dates beyond month-level on Now items. No engineer names. No hourly estimates. The project plan / Gantt lives separately in the team's planning tool; it is the execution detail. The roadmap is the strategic abstraction."

How to catch it. Open the roadmap. Does it have engineer names? Hourly estimates? Daily milestones? Each is project-plan content polluting the roadmap.

---

Red Flag 10: No connection to the NSM or OKRs

Symptom. Roadmap items have outcomes. NSM and OKRs exist separately. No mapping between them.

Why it's bad. Outcomes that don't ladder to the company's NSM and the team's OKRs are local optimizations. The team can hit every roadmap outcome and still not move the strategic levers. Roadmap-OKR alignment is what makes the work add up.

Bad example:

"Roadmap Now item: 'Enable users to find products faster, so conversion rate improves.' Q3 OKR: 'Reduce churn from 4% to 2.5%.' (No connection. Conversion-rate improvement doesn't move churn.)"

Good example:

"Roadmap Now item: 'Enable repeat shoppers to find products faster, so weekly repeat-visit conversion rate improves from 8% to 12%.'

Strategic linkage: NSM is 'weekly active engaged accounts'; this initiative moves the 'repeat visit conversion' input which combines with WAU to produce WAEA. Q3 OKR KR2 is 'WAEA from 28k to 40k' — this initiative is expected to contribute ~30% of that lift."

How to catch it. For each Now item, ask: "which OKR KR does this serve?" If the team can't answer, the roadmap is locally optimized.

---

Red Flag 11: Dependencies hidden

Symptom. Now item "Enable [X]" lists no dependencies. Engineering reveals at week 4 that it depends on a Platform team migration that hasn't been planned.

Why it's bad. Hidden dependencies are roadmap timebombs. They surface late, cause slips, and embarrass the team in stakeholder reviews. The roadmap promised an outcome but cannot deliver because the team did not surface the prerequisites.

Bad example:

"Now: 'Enable customers to share dashboards externally.' (Dependencies field: blank.) (Week 4: PM realizes this requires the auth team's external-sharing infrastructure, which is not on Platform's roadmap.)"

Good example:

"Now: 'Enable customers to share dashboards externally.'

Dependencies:

• Technical: external-auth service from Platform team (DEP-014, needed by Aug 1, expected Jul 28).

• Organizational: Legal review of GDPR data-sharing implications.

• Market: SOC 2 certification of the sharing surface (current; verified May).

Each dependency tracked in dependency-map/ and visible in the cross-team weekly sync."

How to catch it. For each Now/Next item, are technical + organizational + market dependencies documented? If blank, surface them.

---

Red Flag 12: Roadmap reviewed only at quarter boundaries

Symptom. Roadmap published April 1. Next review June 28. In between, the team works against it but never updates it.

Why it's bad. Roadmaps drift in 90 days. Items complete (or fail); new information emerges; assumptions get validated or invalidated. A roadmap reviewed only at quarter boundaries is an autopsy, not a steering instrument.

Bad example:

"Q3 roadmap published Jul 1. Next review: Sep 28. Mid-quarter: 2 Now items completed (not removed); 1 invalidated by user research (still listed); 3 new opportunities surfaced (not added)."

Good example:

"Roadmap reviewed monthly (3 times per quarter):

Month 1: focus on Now item progress; mid-flight decisions.

Month 2: confirm Next items as Q3 progresses; promote/demote based on data.

Month 3: shape next quarter's Now; confirm strategic Later items still relevant.

Quarterly: full re-baseline with stakeholders."

How to catch it. Compare the published roadmap to actual team work. If the roadmap shows items the team isn't working on, or omits items they are working on, the artifact is stale.

---

Red Flag Quick Reference

Related Reading

• SKILL.md Troubleshooting
• references/outcome-roadmap-guide.md
• brainstorm-okrs/ (OKRs anchor Now items)
• north-star-metric/ (initiatives target input metrics)
• prioritization-frameworks/ (RICE/ICE inform Now vs Next vs Later)
• dependency-map/ (cross-team dependencies on roadmap items)
• create-prd/ (Now items become PRD candidates)