Defining Graduation Criteria Between Horizons to Create Now Next Later Roadmap
This skill teaches you how to establish clear, measurable criteria and confidence thresholds that determine when a product initiative is ready to graduate from Later to Next, or from Next to Now, removing ambiguity from promotion decisions.
Define graduation criteria by establishing measurable confidence thresholds for each horizon transition. For Later to Next, require validated problem statements and initial user evidence. For Next to Now, require a scoped solution, resource availability, and high confidence in impact. Document these criteria explicitly so promotion decisions are consistent and defensible.
Outcome: You produce a documented graduation criteria matrix that your team uses to evaluate every promotion decision, eliminating subjective debates about whether an initiative belongs in Now, Next, or Later.
Prerequisites
- Familiarity with the Now-Next-Later Framework and its three horizons
- A populated Now-Next-Later roadmap with at least 10-15 items across horizons
- Understanding of product discovery concepts such as problem validation and solution scoping
- Ability to assess confidence levels across dimensions like desirability, feasibility, and viability
Overview
When teams first create a now next later roadmap, the initial categorization feels intuitive. Items land in Later because they are speculative, in Next because they seem promising, and in Now because they are urgent. But within weeks, the hard question surfaces: what exactly needs to change for a Later item to earn a spot in Next? Without explicit graduation criteria, promotion decisions devolve into opinion battles, recency bias, or whoever speaks loudest in the planning meeting. Graduation criteria solve this by converting the fuzzy notion of "readiness" into observable, measurable checkpoints that an initiative must pass before moving closer to execution.
This skill sits at the operational core of the Now-Next-Later Framework. While categorizing items handles the initial placement and reprioritizing across horizons handles the ongoing reshuffling, graduation criteria provide the rules of the game for those movements. Think of horizons as stages in a pipeline and graduation criteria as the stage gates. Without gates, the pipeline collapses into a single undifferentiated backlog, which defeats the purpose of the framework entirely.
The concrete artifact you produce is a graduation criteria matrix: a table that lists each transition (Later to Next, Next to Now), the dimensions evaluated at each gate (such as problem clarity, solution confidence, resource availability, and strategic alignment), and the specific thresholds that must be met. This matrix lives alongside your roadmap and is referenced in every planning cycle. Teams that invest in this skill report faster planning meetings, fewer escalations about priority disagreements, and a healthier ratio of well-scoped work entering Now versus half-baked ideas that stall engineering capacity.
Defining graduation criteria also creates a shared vocabulary for confidence. Instead of arguing whether something is "ready," the team can point to the matrix and say, "We have strong evidence on desirability and feasibility, but viability is still a question mark. Let's keep it in Next until we resolve the pricing model." That precision is what transforms a now next later roadmap from a visual organizer into a genuine decision-making tool.
How It Works
Graduation criteria work by decomposing the vague concept of "readiness" into independent, assessable dimensions, then setting explicit thresholds on each dimension for each horizon transition. The mental model is borrowed from stage-gate processes in product development, but adapted for the lighter-weight, sequence-over-dates philosophy of the Now-Next-Later Framework.
The foundational insight is that different horizons demand different types of confidence. Later items need only strategic relevance and a plausible hypothesis. Next items need validated problems and directional evidence that a solution is feasible. Now items need scoped solutions, allocated resources, and high confidence that delivering the work will produce the expected outcome. Each horizon transition is a step increase in confidence across multiple dimensions, not a binary yes/no on a single factor.
The dimensions themselves come from product risk frameworks. Most teams find four dimensions sufficient: desirability (do users want this?), feasibility (can we build this?), viability (does this make business sense?), and usability (can users actually use what we build?). Some teams collapse usability into feasibility or add a fifth dimension for strategic alignment. The key is choosing dimensions your team can actually assess with available evidence.
For each dimension, you define what "good enough" looks like at each gate. At the Later to Next gate, desirability might require at least five user interviews confirming the problem exists. At the Next to Now gate, desirability might require a prototype test with positive signal from 70% or more of participants. These thresholds are not universal formulas. They are team-specific norms calibrated by your risk tolerance, data maturity, and domain.
The system works because it separates the question of "should we do this eventually" from "are we ready to commit resources now." An initiative can be strategically important (high alignment) but operationally unready (low feasibility confidence). Graduation criteria make that gap visible and create a clear action list: what evidence do we need to collect to close the gap? This turns the roadmap from a static snapshot into an active discovery backlog.
One common misunderstanding is treating graduation criteria as rigid bureaucracy. They are not approval workflows. They are shared heuristics that make implicit reasoning explicit. The matrix should evolve as your team learns what evidence actually predicts successful delivery. Reviewing and refining your criteria quarterly is part of the skill, not a sign that the initial criteria were wrong.
Step-by-Step
Step 1: Identify the transitions you need to govern
Start by mapping the transitions that exist in your roadmap. The two primary transitions are Later to Next and Next to Now. Some teams also define an entry gate for Later (what qualifies an idea to appear on the roadmap at all) and an exit gate for Now (what does "done" look like beyond shipping). Write each transition as a row in a table.
For each transition, note the current implicit criteria your team uses, even if those criteria are just gut feeling or stakeholder pressure. Interviewing two or three team members about how they decide something is "ready" will surface hidden assumptions. This step produces a draft transition map with 2-4 gates identified.
Tip: If your team struggles to articulate implicit criteria, ask them to recall the last item that moved between horizons and walk through why it moved. The specific example surfaces real reasoning better than abstract discussion.
Step 2: Select your assessment dimensions
Choose 3-5 dimensions that your team will evaluate at each gate. The most widely applicable set is desirability, feasibility, viability, and strategic alignment. Desirability asks whether users want or need this. Feasibility asks whether your team can build it within reasonable constraints.
Viability asks whether it makes business sense (revenue impact, cost, regulatory risk). Strategic alignment asks whether it advances your product vision and current company priorities. Write a one-sentence definition for each dimension so every team member interprets them consistently. Avoid adding dimensions you cannot realistically assess.
If your team has no way to evaluate regulatory risk independently from viability, do not create a separate dimension for it.
Tip: Limit yourself to five dimensions maximum. Every dimension you add multiplies the assessment effort. Teams with more than five dimensions tend to shortcut the process by rating everything a 3 out of 5 across the board, which defeats the purpose.
Step 3: Define evidence types and thresholds for Later to Next
For each dimension, specify what evidence is required before an item can graduate from Later to Next. This gate is about validating that the problem or opportunity is real and worth investigating further. For desirability, you might require a documented problem statement supported by at least three customer signals (support tickets, interview quotes, or usage data anomalies). For feasibility, you might require a preliminary technical assessment confirming there is no known blocker.
For viability, a rough estimate of addressable market size or revenue impact range. For strategic alignment, confirmation from a product leader that the initiative maps to a current strategic pillar. Write each threshold as a concrete, checkable statement, not a subjective rating scale.
Tip: Phrase thresholds as yes/no checkpoints rather than numeric scores. "Problem statement documented with three or more customer signals" is more actionable than "Desirability score of 3 or higher" because it tells the team exactly what to produce.
Step 4: Define evidence types and thresholds for Next to Now
The Next to Now gate is stricter because graduating to Now means committing engineering capacity. For desirability, you might require usability testing or prototype validation with a defined success metric (such as 7 of 10 participants completing the core task). For feasibility, a technical design document or spike showing the approach works, plus a rough effort estimate in team-weeks. For viability, a validated business case with projected impact on a key metric (revenue, retention, activation).
For strategic alignment, inclusion in the current quarter's strategic bets or explicit executive sponsorship. Add a resource readiness check: the team that would execute has capacity in the current or next sprint cycle. This step produces the second half of your graduation criteria matrix.
Tip: Include a resource readiness dimension at this gate even if you skip it elsewhere. The single most common failure mode is promoting items to Now when no team has capacity, which creates a Now column full of stalled work that erodes trust in the roadmap.
Step 5: Assemble the graduation criteria matrix
Combine the outputs from Steps 1 through 4 into a single reference document. The format is a table with transitions as rows, dimensions as columns, and each cell containing the specific threshold for that combination. Add a header section explaining the purpose and how the matrix is used. Include a brief glossary of terms so new team members can onboard without oral tradition.
Store the matrix wherever your roadmap lives, whether that is a wiki page, a Notion doc, a Confluence page, or a shared spreadsheet. The document should be short enough to scan in under two minutes. If it takes longer, you have too many dimensions or overly complex thresholds.
Tip: Put the matrix in the same tool or workspace as your roadmap so it is visible during planning. A graduation criteria doc buried in a separate wiki that nobody opens during sprint planning is as useless as having no criteria at all.
Step 6: Test the matrix against recent promotion decisions
Take the last five items that moved between horizons and retroactively evaluate them against your new criteria. For each item, check whether it would have passed the gate. If an item that was promoted successfully would have failed the criteria, your thresholds may be too strict or you may be missing a dimension. If an item that struggled after promotion would have passed the criteria, your thresholds are too loose.
Adjust thresholds based on this calibration. This is the most important quality check before rolling out the matrix to the team. Document the calibration results as evidence that the criteria are grounded in real experience, not theory.
Tip: Expect to adjust at least two thresholds during this calibration step. If everything passes perfectly on the first try, you are probably being too generous with your criteria or cherry-picking favorable examples.
Step 7: Introduce the matrix to the team and integrate into planning rituals
Present the graduation criteria matrix to your product team, engineering leads, and key stakeholders. Walk through the rationale for each dimension and threshold. Demonstrate with a real example from Step 6 so the team sees how the matrix works in practice. Then integrate the matrix into your existing planning rituals.
During roadmap reviews or sprint planning, when someone proposes promoting an item, reference the matrix and check each criterion. This does not need to be a formal ceremony. A quick scan of the checklist during the meeting is sufficient. The goal is making the criteria a habit, not a bureaucratic process.
Assign one person (usually the PM) as the owner responsible for maintaining the matrix and facilitating gate reviews.
Tip: Frame the matrix as a tool that protects the team's focus, not a gate that blocks ideas. Engineers especially appreciate criteria that prevent half-baked work from landing in Now, because they have experienced the cost of building without clear problem validation.
Step 8: Review and refine criteria quarterly
At the end of each quarter, review the graduation criteria matrix. Examine every item that was promoted during the quarter and assess whether the criteria predicted success. Look for patterns: are items failing after promotion because a dimension was missing or a threshold was too low? Are items stuck in Next because a threshold is unrealistically high for your team's discovery capacity?
Adjust thresholds, add or remove dimensions, and update the glossary. Document what changed and why so the team can see the criteria evolving based on evidence. This quarterly refinement is what makes the criteria a living system rather than a one-time exercise.
Tip: Track the ratio of items that pass the gate and deliver successfully versus those that pass and stall or fail. A healthy gate should have at least a 70-80% success rate. Below that, your criteria are not catching real readiness gaps.
Examples
Example: B2B SaaS team with 15 engineers and a growing roadmap
A B2B SaaS company sells project management software. The product team has 40 items on their now next later roadmap: 6 in Now, 12 in Next, and 22 in Later. Sprint planning meetings regularly stall because stakeholders disagree about which Next items are "ready" for Now. The team has three engineering squads, each with capacity for roughly two medium-sized initiatives per quarter.
The PM starts by interviewing each squad lead and the head of product about how they currently decide readiness. Three implicit criteria emerge: stakeholder urgency, engineering interest, and rough customer demand. The PM selects four dimensions: desirability (customer evidence), feasibility (technical assessment), viability (revenue impact estimate), and resource readiness (squad capacity). For the Later to Next gate, the PM sets thresholds: problem statement documented with at least three customer interview quotes or support ticket references, a brief technical note confirming no architectural blockers, and confirmation that the initiative maps to one of the company's three annual strategic themes.
For the Next to Now gate, thresholds increase: prototype or mockup tested with five or more users, technical design document with effort estimate in squad-weeks, projected impact on a key metric quantified with assumptions stated, and a named squad with capacity in the upcoming quarter. The PM tests this matrix against the last six promotions. Two items that stalled after reaching Now would have failed the resource readiness criterion. One item that was successful would have failed the viability threshold, so the PM adjusts the viability criterion to accept qualitative strategic value for initiatives below two squad-weeks of effort.
The refined matrix is introduced at the next planning meeting, and the team uses it to evaluate three pending promotion requests in under 20 minutes, compared to the 45 minutes the same discussions used to take.
Example: Early-stage startup with a small team and limited discovery data
A seed-stage startup with two engineers and one PM/designer has 8 items on their roadmap. They have limited access to users and no formal discovery process. The founder tends to pull items into Now based on investor feedback or competitive pressure.
The PM recognizes that requiring prototype tests with 10 users is unrealistic for a team with a handful of beta users. She selects three dimensions instead of four: desirability, feasibility, and strategic alignment. For the Later to Next gate, desirability requires at least one concrete user signal, such as a beta user request, a churned user's exit interview mention, or an observable behavior in analytics. Feasibility requires the engineer to confirm the work is possible within the current architecture.
Strategic alignment requires the founder to confirm the initiative supports the next fundraising milestone. For the Next to Now gate, desirability requires the PM to have spoken to at least two users who confirm the problem. Feasibility requires a rough estimate of under two weeks of effort, since the team cannot afford longer bets at this stage. Strategic alignment requires the founder's explicit agreement that this is the highest-leverage use of the next sprint.
The PM tests this against recent decisions and finds that two items were pulled into Now based solely on investor feedback, skipping user evidence entirely. Both items shipped but saw minimal adoption. The matrix would have caught this gap. The team adopts the lightweight matrix and commits to reviewing it monthly rather than quarterly, given the pace of change at the seed stage.
Example: B2C mobile app team balancing feature requests with platform stability
A consumer mobile app team has a now next later roadmap split between user-facing features and platform stability work (performance improvements, tech debt reduction, infrastructure upgrades). The team struggles because stability work never meets the same "customer evidence" bar as feature requests, so it perpetually sits in Later while the app grows slower and buggier.
The PM identifies the root problem: the graduation criteria implicitly favor desirability evidence that comes from user requests, which stability work rarely generates. She creates two criteria tracks: one for user-facing features and one for platform/stability initiatives. Both tracks share feasibility and resource readiness dimensions, but the evidence types differ. For stability work, desirability is replaced with "impact evidence," which requires data showing degradation, such as p95 latency exceeding a threshold, crash rate above a target, or developer velocity declining by a measurable percentage.
For the Later to Next gate on stability work, the threshold is a documented metric showing a specific KPI crossing a defined warning level. For Next to Now, it requires an engineering proposal with estimated improvement and a rollback plan. The PM tests this against the last quarter. Three stability items were stuck in Later despite p95 latency doubling.
Under the new criteria, two of those three would have graduated to Next immediately. The team adopts the dual-track matrix, and in the next planning cycle, one stability initiative graduates to Now alongside two feature initiatives, balancing the portfolio for the first time in months.
Example: Enterprise product team with multiple stakeholder groups
An enterprise software company has product, sales, customer success, and executive stakeholders who each lobby for different items. The Now column is overloaded with 14 items because every stakeholder group has pushed their priority through without a shared bar for readiness. Engineering throughput supports 4-5 Now items at a time.
The PM conducts a retrospective on the 14 Now items and finds that only 5 have complete technical designs, 3 have validated customer evidence, and 6 were added based on a single executive request. She defines graduation criteria with five dimensions: desirability (customer evidence from three or more accounts for B2B), feasibility (technical design reviewed by engineering lead), viability (impact estimate with finance review for items above a revenue threshold), strategic alignment (maps to published quarterly OKRs), and resource readiness (assigned to a squad with sprint capacity). She sets the Next to Now gate as requiring all five checkpoints to pass. The PM applies the criteria retroactively to all 14 Now items.
Nine items fail at least one criterion and are moved back to Next with clear action items for each. The executive sponsor of two moved items pushes back, and the PM uses the matrix to show exactly which evidence gaps remain, converting a political argument into a factual discussion about missing technical designs. Over the next quarter, the Now column stabilizes at 4-6 items, sprint completion rates improve from 60% to 85%, and stakeholders learn to prepare evidence before proposing promotions.
Best Practices
Write thresholds as binary checkpoints rather than numeric scores. "Technical spike completed with documented approach" is unambiguous, while "Feasibility: 4 out of 5" invites haggling over what a 3 versus a 4 means. Binary checkpoints reduce meeting time because the team is verifying facts, not debating subjective ratings.
Keep the total number of criteria per gate between four and six. Fewer than four tends to miss important dimensions like resource readiness. More than six creates assessment fatigue and teams start rubber-stamping everything. If you notice criteria being skipped or glossed over in planning meetings, you likely have too many.
Differentiate thresholds by initiative size or risk level. A small UX improvement graduating from Next to Now does not need the same level of business case rigor as a new product line. Create two tiers, standard and high-stakes, so the criteria are proportional. Without tiering, small improvements get stuck in Next because they cannot justify a full business case, while large bets slip through with insufficient diligence.
Make the graduation criteria matrix visible during every planning meeting. Print it, project it, or pin it to the top of your planning board. Criteria that exist only in a document nobody opens become decoration. The matrix needs to be in the room when decisions are made.
Require the proposer to fill in the evidence before the meeting, not during it. When someone wants to promote an item, they should prepare a brief summary showing each criterion is met, with links to evidence. This shifts the conversation from "I think this is ready" to "Here is the evidence," and it saves meeting time because the group is reviewing evidence rather than generating it on the spot.
Treat failed gate reviews as discovery tasks, not rejections. When an item does not meet criteria, the output should be a clear list of what evidence is needed, assigned to someone, with a target date. This reframes the gate as a planning tool that generates useful work, rather than a bureaucratic blocker that discourages teams from proposing ideas.
Involve engineering leads in defining feasibility thresholds. Product managers tend to underestimate what constitutes sufficient technical validation. Engineers who have been burned by underscoped Now items will provide more realistic thresholds and will trust the criteria because they helped create them.
Common Mistakes
Setting identical criteria for every type of initiative regardless of size or risk
Correction
A minor copy change and a platform migration have vastly different risk profiles. Applying the same rigorous gate to both creates bottlenecks for small items and insufficient scrutiny for large bets. Create two tiers of criteria, one for standard initiatives and one for high-stakes initiatives, with the threshold for what counts as high-stakes defined clearly (such as more than four weeks of engineering effort or impact on a revenue-critical metric). Review which tier applies during the initial categorization step.
Using subjective confidence scores without defining what each score level means
Correction
Teams that rate confidence on a 1-5 scale without anchored definitions end up with everyone rating everything a 3 or 4. The scores feel objective but are actually uncalibrated gut feelings. Instead, anchor each level to specific evidence types. " Without these anchors, your graduation criteria look rigorous on paper but produce the same subjective decisions as before.
You can spot this problem when different team members consistently rate the same initiative differently.
Defining criteria once and never revisiting them
Correction
Teams often invest heavily in the initial criteria definition workshop and then treat the output as permanent. Over time, the criteria drift out of alignment with reality as the team's discovery capabilities mature, the product domain shifts, or company strategy evolves. Stale criteria either block good ideas that do not fit the old mold or let through ideas that no longer match company priorities. Schedule a quarterly review of the criteria matrix as a standing agenda item.
Track promotion success rates as the signal that triggers threshold adjustments.
Treating graduation criteria as a rigid approval workflow that requires formal sign-off
Correction
When graduation criteria are implemented as a multi-stakeholder approval chain with sign-off requirements, teams start gaming the system or avoiding it entirely. The criteria should function as a shared checklist that the product manager uses to structure the promotion conversation, not a bureaucratic form that requires signatures. If you notice teams routing around the criteria or complaining about process overhead, simplify the mechanism while keeping the dimensions and thresholds. The goal is shared understanding of readiness, not compliance documentation.
Ignoring resource readiness as a graduation criterion for the Next to Now gate
Correction
Even when an initiative meets every evidence threshold for desirability, feasibility, and viability, promoting it to Now without available engineering capacity creates a false promise. The Now column fills up with work that cannot start, which erodes stakeholder trust in the roadmap and creates pressure to expand the team or cut corners. Add a resource readiness checkpoint at the Next to Now gate that confirms a team has capacity within the next one to two sprint cycles. This simple addition prevents the most common source of Now column bloat.
Other Skills in This Method
Comparing Now-Next-Later to Quarterly and Timeline Roadmaps
When to choose a Now-Next-Later approach over traditional date-based or quarterly roadmaps, and how to transition between them.
Categorizing Items into Now, Next, and Later Horizons
How to evaluate and sort initiatives into the three time horizons based on certainty, urgency, and strategic alignment.
Building Now-Next-Later Roadmap Templates
How to set up visual roadmap templates in tools like Miro, Notion, ProductBoard, or spreadsheets to represent the three horizons effectively.
Reprioritizing and Moving Items Across Horizons
How to run regular reviews that promote, demote, or remove items between Now, Next, and Later as new information and priorities emerge.
Applying Now-Next-Later Roadmaps to SaaS Products
How to adapt the Now-Next-Later framework for SaaS environments, including continuous delivery cycles, feature requests, and customer-driven prioritization.
Communicating Now-Next-Later Roadmaps to Stakeholders
How to present a timeline-free, horizon-based roadmap to executives, customers, and cross-functional teams without creating false deadline expectations.
Frequently Asked Questions
How many dimensions should I include in my graduation criteria?
Three to five dimensions work for most teams. Fewer than three misses important angles like resource readiness or strategic alignment. More than five creates assessment fatigue, and teams start skipping criteria or rating everything identically. Start with four (desirability, feasibility, viability, resource readiness) and add or remove after your first quarterly review based on which dimensions actually influenced decisions.
Should I define graduation criteria before or after categorizing items into horizons?
Define criteria after you have an initial categorization. You need items in each horizon to calibrate your thresholds realistically. If you define criteria in the abstract, they tend to be either too strict (nothing graduates) or too loose (everything graduates). Categorize first using the [categorizing items skill](/skills/categorizing-items-into-now-next-later-horizons), then build criteria, then test the criteria against your existing categorization to validate them.
How do graduation criteria interact with reprioritization across horizons?
Graduation criteria govern forward movement (Later to Next, Next to Now), while [reprioritization](/skills/reprioritizing-across-horizons) can also move items backward (Now to Next, Next to Later). Backward movement does not need the same gate process. If strategic priorities shift or new information invalidates an assumption, items can move back immediately. Graduation criteria primarily prevent premature forward promotion, which is the more costly direction because it commits resources.
What if an initiative meets all criteria except one? Should I still block it?
It depends on which criterion is unmet and how close it is to the threshold. Resource readiness is non-negotiable at the Next to Now gate because promoting without capacity guarantees stalling. For evidence-based criteria like desirability, a near-miss might warrant a time-boxed exception: promote to Now with a condition that the missing evidence is gathered within the first sprint. Document the exception and review whether the item would have benefited from waiting. Frequent exceptions signal your thresholds need adjustment.
How do I create now next later roadmap graduation criteria for a team that resists process?
Start with the lightest possible version: three binary checkpoints per gate, printed on a single card or slide. Frame it as a tool that saves meeting time, not a process that adds overhead. Demonstrate the value by using the criteria in one planning meeting to resolve a disagreement that would normally take 30 minutes of debate. Teams that resist process usually resist bureaucracy, not clarity. If the criteria genuinely make decisions faster and better, adoption follows.
Do graduation criteria apply differently when I create now next later roadmap for platform teams versus product teams?
Yes. Platform and infrastructure teams often lack direct user-facing desirability evidence. Replace desirability with "impact evidence" showing measurable degradation or risk, such as latency metrics, error rates, developer velocity trends, or security vulnerability counts. Keep feasibility and resource readiness the same. Viability for platform work might focus on cost reduction or risk mitigation rather than revenue impact. Creating a separate criteria track for platform work ensures stability initiatives are not perpetually deprioritized against feature requests.
How long should it take to evaluate an item against graduation criteria?
If the proposer has prepared the evidence in advance, evaluation should take 5-10 minutes per item during a planning meeting. The matrix is a checklist scan, not a deep analysis session. If evaluations regularly take longer than 15 minutes, either the criteria are too complex, the evidence is being gathered live instead of prepared beforehand, or the team is debating the criteria themselves rather than applying them. The preparation is the work. The meeting should be the verification.