Defining Graduation Criteria Between Roadmap Horizons

Write the evidence an initiative needs to move from Later to Next and from Next to Now, so roadmap moves follow learning instead of pressure.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Graduation criteria are the written conditions an initiative must meet before it moves one horizon closer to Now. They answer the question Janna Bastow suggests leaders ask instead of "when": "What would need to be true for this to move to Now?" (Why Time-Based Roadmaps Are Promises You Can't Keep). Written criteria turn that question from a negotiation into a checklist.

The need comes from how the horizons are defined. In the Now Next Later framework the columns are confidence horizons, so an item should move only when the team's confidence has risen. ProdPad's confidence horizons entry is explicit: items "do not graduate inward because time passes or because a stakeholder pushes hard. They graduate because the team has learned enough to raise its confidence." Without criteria, the loudest request tends to win, Now fills up, and the board stops describing what the team knows.

There are two transitions to govern. Later to Next is a decision to invest discovery effort: the problem looks real and important enough to explore solutions. Next to Now is a decision to commit delivery capacity: the team has a solution it trusts, understands the effort and has room to do it. The criteria for the two differ, because the questions differ.

Criteria also work in reverse. An item in Next whose evidence weakens should move back to Later or leave the roadmap, with the reason recorded. ProdPad's guidance is to keep the rationale "so the team remembers why." Demotion criteria are shorter to write but just as important, because they stop the roadmap from accumulating items nobody believes in.

The output is a one-page checklist per transition that anyone on the team can apply, and a habit of citing it in reviews. Good criteria are specific enough that two people applying them reach the same answer most of the time, and loose enough to leave room for judgment on unusual work.

How It Works

The criteria are built from types of evidence, ranked by how much trust each deserves. Itamar Gilad's Confidence Meter is a useful model. It treats self-conviction, thematic support and other people's opinions as weak evidence, gives more weight to estimates, market data and customer research, gives more to results from tests with real users, and puts launch data at the top. In Gilad's words, the only way to calculate confidence is by looking for supporting evidence. Your criteria can name which kinds of evidence count for each transition.

For Later to Next, the question is whether the problem is worth exploring. Typical criteria cover the problem and the strategy: customer or business evidence that the problem exists and matters, a link to a current objective, and no known blocker that makes the problem unworkable. ProdPad's glossary describes Next as the place where "opportunities get sharper" and where discovery narrows the options, so the bar at this transition is evidence of a real problem. A chosen solution is not required yet.

For Next to Now, the question is whether the team can commit. Criteria usually cover three risks: the problem is validated, a solution has been tested enough to trust, and the effort and technical approach are understood. The confidence horizons entry stresses that technical feasibility "is a major input to where work sits," so engineering's view belongs in the Now criteria. Capacity is the last check: an item that meets every evidence criterion may still wait in Next until the team has room.

ProdPad's conversion guide adds a simple rule that works as a backstop: "If confidence hasn't increased, the Initiative shouldn't move left" (Convert a Timeline Roadmap). The guide also warns against the reverse failure, an initiative moved into Now only because of a deadline, which usually means discovery is unfinished. Hard external deadlines are the one legitimate override, and the criteria should say how they are handled: the item moves, is flagged, and discovery is compressed rather than skipped.

The criteria sit in a short matrix: transitions as columns, evidence areas as rows, and a plain description of what "enough" looks like in each cell. Keep numbers out unless your team already measures them reliably, since a made-up threshold looks precise and invites gaming. Review the matrix against real decisions after a few cycles and tighten any criterion that let a weak item through.

Step-by-Step Guide

Step 1: Agree the horizon definitions

Confirm what Now, Next and Later mean for your team before writing criteria. Use the confidence definitions in ProdPad's glossary as a starting point and adjust the wording to your context. Criteria cannot be consistent if the horizons themselves are read differently by different people.

Step 2: List the evidence your team can produce

Write down the discovery activities you actually run: interviews, support ticket analysis, usage data, surveys, prototypes, experiments, technical spikes. Rank them by strength, using Gilad's Confidence Meter as a reference. Criteria that demand evidence your team never produces will be ignored.

Step 3: Draft Later to Next criteria

Write three or four conditions about the problem. A typical set is: evidence from customers or data that the problem exists; a clear link to a current objective; a rough sense of how many customers or how much value is involved; no known blocker. Phrase each as a yes or no question so it can be checked in a review.

Step 4: Draft Next to Now criteria

Write conditions about the solution and delivery. A typical set is: the problem is validated; at least one solution has been tested with users or data; engineering has scoped the approach and effort; dependencies are identified; capacity exists. Add how a hard deadline is handled, so exceptions are visible rather than silent.

Step 5: Add demotion and removal triggers

Write the conditions that send an item back or off the roadmap. Examples: discovery shows the problem is smaller than thought, the linked objective is retired, or a test shows the leading solution does not work. Require a one-line rationale for every demotion so the history is kept.

Step 6: Test the criteria on past decisions

Apply the draft to the last several items that moved between horizons. Check whether the criteria would have allowed each move, and whether any item that later stalled would have been stopped. Adjust criteria that are too loose or too strict before rolling them out.

Step 7: Use them in every review

Bring the checklist to each roadmap review and cite it when proposing a move. When a stakeholder asks for an item to move, answer with the criteria it still needs to meet. Revisit the checklist every few cycles and whenever the team's discovery practice changes.

Best Practices

• Tie criteria to evidence types. "Validated in customer interviews" is checkable; "we feel confident" is not, and the Confidence Meter shows why opinion is weak evidence.
• Keep each checklist short. A handful of questions per transition gets used; a long form gets skipped.
• Include engineering in the Now criteria. The confidence horizons entry treats technical feasibility as part of confidence, and a proven customer need does not make an unknown build ready.
• Write criteria for moving back as well as forward. A roadmap with only promotion rules only grows.
• Make exceptions visible. When a hard deadline forces a move, flag the item so the team knows discovery was compressed.
• Publish the criteria. Stakeholders who can read the checklist know what evidence an item still needs.

Common Mistakes

• Using time as a criterion: "Has been in Next for a month" moves items without learning. Only evidence and capacity should move work forward.
• Invented numeric thresholds: A made-up bar such as a fixed number of interviews looks rigorous but invites box-ticking. Use numbers only where your team already measures them reliably.
• Skipping feasibility: Promoting a validated problem to Now without an engineering view leads to stalls in delivery. Put effort and technical approach in the Now checklist.
• Letting deadlines bypass the criteria silently: A deadline can justify a move, but it should be flagged. Otherwise the team loses track of which Now items are under-validated.
• Writing criteria once and never revisiting them: As discovery practice matures, the evidence available changes. Test the criteria against real decisions and update them.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Now Next Later Framework

Related Skills

• Now Next Later Categorization: Sorting Work Into Horizons
• Reprioritizing Roadmap Items Across Now, Next and Later
• Now Next Later Roadmap Template: How to Build One
• Communicating Now Next Later Roadmaps to Stakeholders
• Now Next Later vs Timeline Roadmap: Choosing a Format
• Now Next Later Framework for SaaS Product Roadmaps

Sources

• ProdPad Glossary: What Are Confidence Horizons?
• ProdPad Glossary: What Is a Now-Next-Later Roadmap?
• ProdPad: Why Time-Based Roadmaps Are Promises You Can't Keep
• ProdPad: How to Convert a Timeline Roadmap to Now-Next-Later
• Itamar Gilad: Product Discovery With ICE and The Confidence Meter

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.