Now Next Later Framework: How to Build Roadmaps Without False Deadlines
The Now Next Later framework is a product roadmap format that organizes work into three priority horizons instead of fixed dates. "Now" holds committed, high-certainty work. "Next" contains validated problems awaiting capacity. "Later" captures strategic ideas still being explored. Created by Janna Bastow in 2012, it replaces timeline-based roadmaps with a sequence-driven approach that communicates intent without false precision.
Overview
Product teams have a trust problem with roadmaps. Traditional timeline roadmaps promise delivery dates that sound precise but aren't. A feature slated for "Q3" becomes a commitment the moment a stakeholder sees it on a slide, even if the team scoped it on a napkin over lunch. When that date slips, credibility erodes. The Now Next Later framework was designed to solve exactly this pattern. Instead of plotting work on a calendar, it sorts initiatives into three columns based on how well understood they are and how soon the team intends to act on them.
Janna Bastow, co-founder of ProdPad, introduced the Now Next Later roadmap in 2012 after years of watching product managers struggle under the weight of date-driven commitments. Bastow's core observation was simple: most teams don't actually lack a sense of priority. They lack a format that lets them communicate priority without implying a deadline. The three-horizon model gave PMs a way to say "this is what matters most, this is what comes after, and this is where we're thinking long-term" without anyone pulling out a calendar. The framework gained traction quickly in the lean and agile product communities, partly because it required no new tooling and partly because it mapped naturally onto how product discovery actually works.
The mental model underneath the framework is a confidence gradient. Items in "Now" are high-confidence. The problem is validated, the solution is scoped, the team has capacity, and the work is underway or about to start. "Next" items sit in the middle of the gradient. The problem is real and probably validated, but the solution still needs discovery work, dependencies need to be resolved, or capacity isn't available yet. "Later" items are low-confidence by design. They represent strategic bets, customer requests worth tracking, or ideas the team believes in but hasn't validated. The further right on the board an item sits, the less detail it should have, and that's the point. Forcing detailed specs on a "Later" item is wasted effort because the world will change before the team gets there.
Compared to quarterly roadmaps, the Now Next Later framework avoids the fiction of precise scheduling while still offering directionality. Compared to kanban boards, it adds a strategic layer that goes beyond "to-do, doing, done" by explicitly including future thinking. It sits somewhere between the two, borrowing kanban's visual simplicity and the quarterly roadmap's forward-looking scope. Some teams layer it on top of frameworks like RICE or MoSCoW. RICE helps score individual items, and Now Next Later provides the container for sequencing them once scored.
The framework has evolved since its introduction. Early adopters used it as a literal three-column board. Over time, teams began adding sub-horizons, tagging items by theme or objective, and connecting horizons to OKRs or strategic pillars. Some organizations run separate Now Next Later boards per team or product area, then roll them up into a portfolio view. The format has also become a communication tool as much as a planning tool. PMs present it to executives to show strategic direction, to engineers to clarify what's coming, and to customers to set expectations without making promises.
The framework works best for teams that operate in environments where customer needs shift, technical constraints evolve, and business priorities change faster than a quarterly plan can absorb. SaaS product teams, early-stage startups iterating on product-market fit, and platform teams juggling competing stakeholder requests all tend to benefit. It's less suited for teams with hard regulatory deadlines or fixed-scope contract work, where dates genuinely matter and aren't arbitrary. The key question is whether your team's biggest roadmap problem is "we don't know what to build" or "we don't know when it'll ship." If it's the latter, and the dates are real, a timeline roadmap may serve you better. If it's the former, Now Next Later gives you a structure that matches your actual level of certainty.
How It Works
Step 1: Audit your existing backlog and incoming requests
Before building the board, gather everything: feature requests, bug reports, strategic initiatives, tech debt items, customer feedback, internal stakeholder asks. Pull from whatever sources your team uses, whether that's a product management tool, a spreadsheet, a Slack channel full of requests, or a pile of sticky notes from the last offsite. The goal is a single, comprehensive list with no duplicates. Resist the urge to prioritize during this step. You're collecting, not deciding. A common mistake is skipping this audit and only putting "the things we already planned" on the board, which defeats the purpose because it excludes the competing priorities that make the framework necessary in the first place.
Step 2: Define what each horizon means for your team
"Now," "Next," and "Later" need concrete definitions that your specific team agrees on. For some teams, "Now" means "in the current sprint." For others, it means "actively being worked on this month." "Next" might mean "validated and ready to start when capacity opens" or "in active discovery." "Later" might mean "strategic direction for the next 6 months" or "interesting ideas we haven't validated." Write these definitions down and share them. Without shared definitions, two people looking at the same board will interpret it differently, and that misalignment will surface as conflict later. One variation: some teams add a fourth column, "Not Doing" or "Parked," for items they've explicitly decided against, which prevents those items from being re-raised every planning session.
Step 3: Establish graduation criteria for each transition
Define what needs to be true for an item to move from Later to Next, and from Next to Now. ). Write these criteria as a checklist that anyone can reference. The criteria don't need to be rigid, they can include judgment calls, but they need to exist so that "moving something to Now" is a conscious decision with documented reasoning rather than a reaction to whoever asked most recently. Teams that skip this step find their "Now" column overflowing within weeks.
Step 4: Sort your backlog into the three horizons
Take the comprehensive list from Step 1 and place each item into Now, Next, or Later based on the definitions and graduation criteria you established. Start with "Now" because it's the most constrained. Limit it to what the team is genuinely working on or will start within the current cycle, typically 3-5 initiatives for a single product team. Then populate "Next" with items that meet most but not all graduation criteria for "Now," usually 5-10 items. Everything else goes into "Later" or gets discarded. This step should involve the cross-functional team, not just the PM, because engineers and designers often have context about technical readiness and design feasibility that changes where items land. " If your "Now" column has more than 5-7 items, you're not prioritizing, you're listing.
Step 5: Add context and appropriate detail to each item
Apply the detail gradient. For "Now" items, ensure each has a clear problem statement, defined scope, an owner, and acceptance criteria or a definition of done. " For "Later" items, a brief problem statement or strategic hypothesis is sufficient, often just one or two sentences. Resist the urge to write detailed specs for "Later" items. It feels productive but it's waste. If an item in "Later" has a three-page spec, either it belongs in "Next" or the spec will be outdated by the time the team gets to it. Some teams tag items by theme, objective, or customer segment at this stage, which helps with filtering and stakeholder presentations.
Step 6: Establish a review cadence
Set a regular rhythm for reviewing and updating the board. Weekly or biweekly reviews work for most teams. During each review, ask: Has anything in "Now" been completed or blocked? Has new information changed the priority of anything in "Next"? Have any "Later" items been validated enough to graduate? Has anything been added that needs to be sorted? The review should involve the core product team and optionally key stakeholders. Keep it short, 15-30 minutes, and focused on changes rather than re-debating settled decisions. A common failure mode is treating the review as a status meeting rather than a prioritization conversation. The goal isn't to report progress on "Now" items. That's what standups and sprint reviews are for. The goal is to keep the horizons accurately reflecting the team's current understanding.
Step 7: Communicate the roadmap to different audiences
Present the board to stakeholders with framing appropriate to each audience. For executives, emphasize the strategic themes across horizons and how they connect to business objectives. For engineering teams, focus on what's in "Now" and what's coming in "Next" so they can anticipate upcoming work. For customers or external stakeholders, share a curated view that shows direction without overcommitting. " Always pair the board with a brief explanation of what each horizon means, especially for audiences seeing this format for the first time. Stakeholders accustomed to date-based roadmaps will initially push back.
When to Use
- When your team has 20 or more competing feature requests from customers, internal stakeholders, and strategic goals, and every conversation about roadmaps devolves into timeline debates rather than priority discussions. The framework gives you a shared vocabulary for "this matters but we're not ready to commit" that a timeline roadmap can't express.
- When you're building a SaaS product and your roadmap needs to serve multiple audiences, including an engineering team that wants clarity on what's next, executives who want strategic direction, and customers who want to know their request was heard. The three-horizon format lets you present the same board to each audience with different emphasis without maintaining three separate documents.
- When your product discovery process regularly invalidates assumptions, making date-based commitments unreliable. If your team runs experiments, prototypes, or beta tests before committing to full builds, the Now Next Later framework maps directly onto your discovery workflow: "Later" items are hypotheses, "Next" items are validated problems, and "Now" items are solutions ready for delivery.
- When you're an early-stage startup iterating toward product-market fit and your priorities shift every few weeks based on customer conversations, churn data, or competitive moves. Quarterly roadmaps break down in this context because the world changes faster than the planning cycle. The framework absorbs change without requiring a formal replan.
- When cross-functional teams need alignment without rigid scheduling. If design, engineering, data science, and marketing all have different cycle times and planning rhythms, the framework provides a shared view of priority without forcing everyone onto the same sprint cadence or quarterly calendar.
When Not to Use
- When you're working against hard external deadlines that cannot move, such as regulatory compliance dates, contractual delivery obligations, or coordinated launches with hardware partners. The framework's core assumption is that sequence matters more than dates, and that assumption breaks when missing a date has legal, financial, or partnership consequences. In these cases, a timeline or Gantt-based roadmap gives stakeholders the date-specific accountability they actually need.
- When your organization's culture demands date commitments and you don't have the political capital to change that expectation. Introducing Now Next Later into an organization that evaluates PM performance based on hitting quarterly delivery targets will create friction without solving the underlying cultural problem. The framework requires leadership buy-in that "we'll ship the right things in the right order" is more valuable than "we'll ship what we promised by the date we promised."
- When you're managing a small, well-understood backlog with fewer than 10 items and a single team. The overhead of maintaining three horizons doesn't add value when the team can simply look at a prioritized list and know what to do next. The framework solves a communication and prioritization problem at scale. For a two-person team with a clear mission, a simple ordered backlog is faster and clearer.
- When detailed project planning and resource allocation across multiple teams is the primary need. The framework intentionally avoids granularity around timelines and dependencies, which makes it a poor fit for program management scenarios where you need to coordinate handoffs between teams, manage shared resources, or sequence work across a critical path. Tools like Gantt charts or dependency-mapped project plans serve that need better.
- When the team's primary challenge is execution speed rather than prioritization. If you already know exactly what to build and the bottleneck is shipping velocity, adopting a new roadmap format won't help. The framework is a prioritization and communication tool, not a delivery acceleration tool.
Examples
Example: Early-stage B2B SaaS finding product-market fit
A 6-person startup building an invoicing tool for freelancers had a backlog of 40+ feature requests from early customers, investor suggestions, and founder ideas. Every planning meeting became a debate about what to build next, with no shared framework for deciding. They adopted Now Next Later with strict limits: 3 items in Now, 8 in Next, everything else in Later. Their Now column held the three features most frequently requested by their 50 paying customers. Next held items where they'd done customer interviews but hadn't designed solutions yet. Later captured everything else, including the CEO's "big vision" features. Within two months, they found that the discipline of limiting Now forced honest conversations about capacity. They also discovered that 12 items in Later hadn't been mentioned by a single customer in 6 months and archived them. The one thing they'd do differently: they initially didn't define graduation criteria, so items moved to Next based on whoever argued loudest in the Monday meeting. Adding explicit criteria in month two solved that.
Example: Mid-size SaaS platform managing multiple customer segments
A project management SaaS with 2,000 customers and three product teams was struggling with a quarterly roadmap that became outdated within weeks of publication. Enterprise customers wanted audit logs and SSO. SMB customers wanted simpler onboarding. The platform team needed to address technical debt. They switched to Now Next Later with each team maintaining its own board, rolled up into a company-level view grouped by strategic theme. The enterprise team placed SSO in Now because a $200K deal depended on it, audit logs in Next because it was validated but needed architectural decisions first, and advanced permissions in Later. The key insight was that the rolled-up view gave the CPO a portfolio perspective without requiring all three teams to plan on the same cadence. Engineering leads appreciated that "Next" gave them a 4-6 week preview of upcoming work for staffing conversations. " They learned to present a curated version that showed direction without the internal prioritization labels.
Example: Product team transitioning from waterfall to agile
A 15-person product and engineering team at a fintech company had been running 6-month waterfall cycles with detailed project plans. Leadership wanted to move to agile but the organization wasn't ready for a full transformation. The PM introduced Now Next Later as an intermediate step. Instead of jumping from Gantt charts to sprints, they kept their existing execution process but replaced the 6-month roadmap with a Now Next Later board. "Now" mapped to their current 6-week build cycle. "Next" held the items they'd begin discovery on during the current cycle. "Later" replaced the second half of their old 6-month plan. This gave leadership the strategic visibility they were used to while removing the false precision of dates 4-5 months out. Over the next two quarters, as the team grew comfortable with shorter planning horizons, they naturally shortened their cycles from 6 weeks to 2-week sprints. The framework served as a bridge. What they'd change: they should have involved engineering leads in defining graduation criteria from the start rather than having the PM set them unilaterally, which created early resistance.
Example: Marketing team coordinating campaigns and content
A 4-person marketing team at a developer tools company was juggling SEO content, product launches, conference sponsorships, and experimental channels like podcasting. Their shared spreadsheet had 60 line items with no clear priority, and the CMO's weekly "what should we focus on" question never had a satisfying answer. " They limited Now to 5 active projects across the team. The immediate benefit was that saying no became easier. When the CEO suggested sponsoring a conference next month, instead of adding it to an already overwhelmed Now column, they placed it in Next and identified what would need to move out of Now to accommodate it. The framework also revealed that their Later column was dominated by experimental channel ideas that never graduated because no one had defined what "validated" meant for a marketing experiment. They added graduation criteria: a channel moved from Later to Next only after a small test showed a cost-per-lead below $50. This eliminated speculative projects that had been consuming mental energy without producing results.
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.
Defining Graduation Criteria Between Horizons
How to establish clear criteria and confidence thresholds that determine when an initiative is ready to move from Later to Next, or from Next to Now.
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.