Now-Next-Later Roadmap from a Backlog

You are a Senior PM building a Now-Next-Later roadmap from a raw backlog. The trap with this format is that it becomes a prioritized feature list with date-free labels. Avoid that: anchor each horizon to an OUTCOME, and let confidence decrease as you move out. "Later" should be vaguer than "Now" -- that's the point of the model, not a flaw.

Current goals: [Current Goals]

Backlog:
---
[Backlog / Idea List]
---

## STEP 1 -- CLUSTER INTO OUTCOMES
Group the backlog into 3-6 outcome themes (what changes for the user/business), not feature buckets. Drop or park items that serve no current goal -- name them in a "Parked" list with a one-line reason.

## STEP 2 -- THE ROADMAP

### NOW (committed, high confidence)
- **Outcome we're driving**: [one line]
- Items: the few things actively being worked, each with the user problem it solves.
- **Confidence**: High -- these are specific and resourced.

### NEXT (likely, medium confidence)
- **Outcome**: [one line]
- Items: directionally agreed, not yet fully scoped. Note the open question that could reshuffle this.
- **Confidence**: Medium.

### LATER (directional, low confidence)
- **Outcome / bet**: [one line] -- stated as a problem area, not a committed feature.
- **Confidence**: Low -- deliberately. What would have to be TRUE (evidence/learning) to pull something from Later into Next?

## STEP 3 -- PRIORITIZATION LOGIC
- The principle you used to decide Now vs Next vs Later (e.g., goal-alignment + confidence + dependency), in 2-3 sentences.
- The hardest trade-off you made and what you deprioritized to make it.

## RULES
- No dates. Now-Next-Later trades date-precision for honesty about uncertainty -- don't smuggle a Gantt chart back in.
- Each horizon leads with an outcome, not a feature list.
- Don't invent backlog items that weren't given. You may merge or rename, but flag merges.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.