Applying the Now Next Later SaaS Roadmap to Your Product
This skill teaches you how to reshape the Now-Next-Later roadmap for the specific demands of SaaS, including continuous deployment, recurring customer feedback loops, and subscription-revenue pressures that make traditional timeline roadmaps brittle.
Map your SaaS backlog into Now (current sprint or cycle work), Next (validated items in discovery or design), and Later (strategic bets and exploratory ideas). Feed customer requests, usage data, and business goals into a scoring rubric, then use graduation criteria to move items between horizons as confidence grows. Review the roadmap every two weeks aligned to your release cadence.
Outcome: You produce a living Now-Next-Later roadmap tuned to your SaaS release cadence, fed by customer signals and usage data, that your team reviews and updates every cycle without the brittleness of date-based commitments.
Prerequisites
- Familiarity with the Now-Next-Later Framework and its three horizons
- A working product backlog or feature request list with at least 15-20 items
- Access to customer feedback channels such as support tickets, NPS data, or feature request tracking
- Basic understanding of continuous delivery or sprint-based release workflows
Overview
SaaS products operate under constraints that make traditional timeline roadmaps unreliable. Continuous delivery means features ship in days, not quarters. Customer feedback arrives constantly through support tickets, in-app surveys, churn interviews, and usage analytics. Subscription revenue creates pressure to show progress to existing customers, not just chase new ones. The Now-Next-Later Framework was built for exactly this kind of environment, but applying it to SaaS requires deliberate adaptation of its horizons, inputs, and review cadence.
The core challenge is translating the framework's sequence-over-dates philosophy into the reality of a SaaS team that ships weekly (or daily). "Now" can't just mean "important" because in SaaS, everything feels urgent when a paying customer is asking for it. You need clear rules for what earns a spot in each horizon, how customer requests feed into the roadmap without hijacking it, and how items graduate from Later to Next to Now as confidence increases. This skill gives you those rules. The artifact you produce is a fully populated now next later SaaS roadmap with explicit intake criteria, a scoring rubric for incoming requests, and a review rhythm tied to your release cycle.
Without SaaS-specific adaptation, teams fall into two traps. The first is a "Now-only" roadmap where everything is urgent and the Next and Later columns stay empty, which destroys strategic thinking. The second is a "Later graveyard" where customer requests pile up in Later and never move forward, which erodes trust with customers and internal stakeholders. This skill teaches you to avoid both traps by building intake, scoring, and graduation mechanisms that keep all three horizons active and honest. By the end, you will have a roadmap that balances customer-driven work with product-led strategy and gives your team a clear sequence of what to build without locking anyone to a date they cannot keep.
How It Works
The Now-Next-Later framework works because it replaces false precision ("Q3 Week 6") with honest confidence levels ("we are doing this now, planning this next, exploring this later"). In SaaS, this maps naturally to how software actually gets built. Your Now horizon contains work that is specced, designed, and in active development or about to enter development. Your Next horizon holds items where the problem is validated but the solution is still being shaped through discovery, prototyping, or customer conversations. Your Later horizon captures strategic bets, emerging customer patterns, and exploratory ideas where the problem itself may still need validation.
What makes SaaS adaptation different from a generic application of the framework is the volume and velocity of inputs. A B2B SaaS product might receive 50 feature requests per week from customers, prospects, support, sales, and internal stakeholders. Without a structured intake process, these requests either flood the Now column or get lost entirely. The skill works by inserting a scoring and triage step between "request received" and "placed on roadmap." Each incoming request gets evaluated against a small set of criteria: customer impact (how many accounts, what segment, what revenue), strategic alignment (does this support a current product theme or bet), effort estimate (t-shirt size), and confidence (how well do we understand the problem and solution). The scores determine initial horizon placement, not priority within a horizon.
The second mechanism that makes SaaS adaptation work is a cadenced review loop. In a SaaS environment with continuous delivery, the roadmap is not a quarterly artifact. It is a living document reviewed every one to two weeks. During each review, the team asks three questions: what in Now is shipping or blocked, what in Next has gained enough confidence to graduate to Now, and what signals from Later suggest an item should move into active discovery in Next. This cadence prevents the common failure mode where the roadmap is set once per quarter and becomes stale within weeks.
The framework's power in SaaS comes from separating the "what" from the "when." Customers and stakeholders care about sequence and relative priority. They want to know that their request is acknowledged, where it sits, and what needs to happen for it to move forward. The Now-Next-Later Framework gives you a language for that conversation without committing to dates you will miss. When a customer asks "when will this ship," you can answer with "this is in our Next horizon, which means we are actively designing it and it will move to Now once we have validated the approach with three beta customers." That answer is more honest and more useful than "Q4" because it tells the customer what conditions trigger progress, not just a calendar slot.
Step-by-Step
Audit your existing backlog and request sources
Before building the roadmap, gather every source of product input into one view. Pull your current backlog items, open feature requests from customers, sales team asks, support ticket themes, and internal stakeholder requests. The goal is a single flat list of candidate items, each with a short description (one to two sentences), the source (customer, internal, strategic), and any available data about demand such as how many customers requested it or how often the related support ticket appears. Do not worry about categorization yet.
You need volume and visibility first. If your list has fewer than 15 items, you likely have items hiding in Slack threads, email inboxes, or sales call notes that have not been formally captured. If your list exceeds 100 items, group obvious duplicates before proceeding.
Tip: Export feature requests from your support tool (Intercom, Zendesk, Productboard) and deduplicate by theme rather than by exact wording. Customers describe the same problem in many different ways.
Define your SaaS-specific horizon boundaries
Write explicit definitions for what Now, Next, and Later mean for your product and team. " The key is tying boundaries to your actual delivery cadence. If you deploy daily, your Now horizon is tighter. If you ship in two-week sprints, Now covers the current and upcoming sprint.
Write these definitions in a shared document your whole team can reference.
Tip: Avoid defining horizons by calendar dates. Instead, define them by confidence level and work state: designed vs. in discovery vs. exploratory. This keeps the framework flexible as your velocity changes.
Build your intake scoring rubric
Create a lightweight scoring system for evaluating incoming requests. Use four dimensions: customer impact (number of requesting accounts, segment weight, revenue at risk), strategic alignment (does it support a current product theme or company OKR), effort (t-shirt size estimate from engineering), and confidence (how well do you understand the problem and proposed solution). Score each dimension on a 1-5 scale. Customer impact and strategic alignment together determine the "should we do this" question.
Effort and confidence together determine the "can we do this now" question. A high-impact, high-confidence, low-effort item goes straight to Now. A high-impact, low-confidence item goes to Next for discovery. A low-impact or low-alignment item goes to Later or gets declined.
Document the rubric so anyone on the team can apply it consistently to new requests.
Tip: Score confidence based on evidence, not gut feeling. Confidence of 5 means you have customer interviews, usage data, and a validated prototype. Confidence of 1 means you have a single Slack message from a sales rep.
Score and place every backlog item into a horizon
Apply your scoring rubric to every item on your flat list from Step 1. Work through the list systematically. For each item, fill in the four scores and note the initial horizon placement based on your rules from Step 3. This step will take the most time during initial setup, often 60-90 minutes for a list of 40-60 items.
Do not agonize over borderline cases. Place them in the lower-confidence horizon (Next rather than Now, Later rather than Next) and flag them for discussion during your first review. The output of this step is a categorized roadmap with items distributed across Now, Next, and Later, each with its scores visible. Aim for roughly 5-8 items in Now, 10-15 in Next, and an uncapped number in Later.
If Now has more than 10 items, your horizon definition is too loose.
Tip: If everything scores as "high impact," your scoring rubric lacks discrimination. Revisit the customer impact dimension and add segment weighting: enterprise accounts might carry 3x the weight of free-tier users.
Define graduation criteria between horizons
For each transition (Later to Next, Next to Now), write down the specific conditions that must be true before an item moves. For Later to Next: the problem must be validated by at least three customer interviews or a clear data pattern in usage analytics, and it must align with a current product theme. For Next to Now: design must be complete, engineering must have estimated the work within the current sprint capacity, and any dependencies must be resolved. These criteria prevent the most common SaaS roadmap failure, which is items jumping from Later straight to Now because an important customer escalated.
With graduation criteria, you can respond to escalations by saying "here is what needs to happen for this to move forward" rather than reflexively reprioritizing. Document these criteria alongside your horizon definitions from Step 2.
Tip: Include a "fast track" rule for critical bugs and security issues that bypass normal graduation. Define what qualifies as critical so the exception does not swallow the rule.
Set your review cadence and assign ownership
Decide how often you will review the roadmap and who participates. For most SaaS teams, a biweekly review aligned to sprint boundaries works well. The review should take 30-45 minutes and cover three questions: what shipped or is blocked in Now, what in Next has met graduation criteria for Now, and what new signals from customers or data suggest moving a Later item into Next. Assign a roadmap owner, typically the product manager, who is responsible for updating the roadmap between reviews based on incoming requests scored through the rubric.
The owner does not make unilateral prioritization decisions but does handle triage and initial scoring so the review meeting stays focused on decisions, not data entry. Share the review notes with the broader team and key stakeholders after each session.
Tip: Keep the review meeting separate from sprint planning. The roadmap review is about strategic sequence across horizons. Sprint planning is about execution within the Now horizon.
Connect customer feedback loops to the roadmap
Set up a systematic connection between your customer feedback channels and the roadmap intake process. This means configuring your support tool to tag feature requests with a roadmap intake tag, creating a shared intake form for sales reps to submit customer asks with context (account name, ARR, segment, exact quote), and scheduling a monthly review of usage analytics to identify patterns that suggest unspoken needs. Each new request goes through the scoring rubric and gets placed in a horizon or declined with a documented reason. The critical behavior change here is that customer requests no longer go directly to engineering.
They go to the roadmap intake process, get scored, and enter a horizon. This protects your Now column from being hijacked by the loudest customer while ensuring legitimate requests are captured and tracked.
Tip: Track declined requests and their reasons. If you start seeing the same declined request from 10 different customers, it is time to reassess the scoring.
Communicate the roadmap to stakeholders using horizon language
Share the roadmap with customers, sales, support, and leadership using the horizon framework. For each horizon, explain what the items are, why they are in that horizon, and what would cause them to move. Avoid date commitments. " Create a lightweight summary view that shows 3-5 items per horizon with one-sentence descriptions.
Detailed scoring and internal notes stay internal. The external-facing view should help stakeholders understand the direction and feel confident that their input is being heard and processed. Link out to communicating roadmaps to stakeholders for more detailed guidance on tailoring the message to different audiences.
Tip: When a customer asks about a specific item in Later, respond with the graduation criteria rather than a timeline. "We will move this into active planning once we see demand from five more accounts in your segment" is a more honest and more actionable answer than "maybe Q4."
Examples
Example: Early-stage B2B SaaS with 50 customers
A 10-person startup building a project management tool for agencies has 50 paying customers, a single product manager, and a 4-person engineering team shipping weekly. They receive about 20 feature requests per week through Intercom and direct sales calls. The founder has been personally prioritizing requests based on whoever asked most recently, leading to context-switching and half-finished features.
The PM audits all sources and assembles a flat list of 38 items from Intercom tags, a Notion backlog, and the founder's email. She defines horizons: Now is "in development this week or next, fully specced" (capacity for 3-4 items), Next is "validated by 3+ customer conversations, design in progress" (8-12 items), and Later is "interesting signal, needs more evidence" (uncapped). She builds a simple scoring rubric in a spreadsheet with four columns: customer impact (weighted by MRR of requesting accounts), strategic alignment with their current focus on collaboration features, effort (S/M/L from the lead engineer), and confidence (evidence level 1-5). After scoring all 38 items, she places 4 in Now, 11 in Next, and 18 in Later, declining 5 that do not align with the product direction.
The biweekly review immediately reveals that 3 items in Next have enough evidence to graduate, which gives the team a clear pipeline for the following sprint. The founder stops ad-hoc reprioritizing because the rubric provides a shared language for why items are where they are.
Example: Growth-stage B2B SaaS with 500 accounts
A 40-person company selling an analytics platform to e-commerce brands has 500 accounts across three segments: self-serve ($49/mo), mid-market ($499/mo), and enterprise ($5,000/mo). They have two product managers, 15 engineers in three squads, and deploy continuously. Feature requests come from Zendesk (support), Salesforce (sales), Productboard (PM research), and quarterly customer advisory board meetings. The roadmap has historically been a quarterly Gantt chart that is outdated by week 3.
The PMs consolidate requests from all four sources into Productboard, tagging each with segment and estimated ARR impact. They define horizons: Now covers the current two-week cycle per squad (3-5 items per squad, 9-15 total), Next covers items in discovery or design with engineering estimates complete (15-25 items), and Later captures themes from the advisory board and emerging usage patterns (30-40 items). 5x versus self-serve. During the first scoring pass, they discover that 60% of self-serve requests cluster around a single theme (better onboarding), which, aggregated, rivals enterprise request impact.
This insight promotes the onboarding theme from Later to Next as a single initiative rather than 12 individual requests. Each squad runs its own biweekly review for its Now column, while the PMs run a cross-squad review monthly to manage Next and Later. After two months, the team reports that sprint commitments feel more realistic because Now is explicitly scoped to capacity, and sales reps stop escalating because they can see their customer's request in Next with clear graduation criteria.
Example: PLG SaaS with 10,000 free users and 800 paid
A product-led growth SaaS offering a design tool has 10,000 free-tier users and 800 paid users at $19/mo. The team is 6 engineers and 1 PM. Feature requests come overwhelmingly from free users through an in-app feedback widget, creating a volume problem: 200+ requests per month. The paid users rarely submit requests but churn at 8% monthly, and exit surveys cite missing features. The PM cannot figure out what to build because the signal-to-noise ratio in the feedback is terrible.
The PM starts by separating signal sources. She pulls churn survey data from the last 6 months, in-app feedback from paid users only, and usage analytics showing feature adoption rates. Free-tier feedback goes into a separate "signal watch" queue reviewed monthly for patterns, not into the main roadmap intake. She defines horizons tied to the biweekly sprint cadence: Now (3-4 items in active development), Next (5-8 items in discovery), Later (themes from churn data and strategic bets).
The scoring rubric heavily weights churn correlation: if a missing feature appears in 10%+ of churn exit surveys, it gets a customer impact score of 5 regardless of request volume. After scoring, she finds three features that appear in 25%, 18%, and 12% of churn surveys respectively. All three enter Now or Next immediately. Meanwhile, the most-requested free-tier feature (dark mode, 300+ votes) goes to Later because it has zero correlation with paid conversion or churn.
5% within 6 weeks, validating the scoring approach.
Example: Horizontal SaaS selling to multiple verticals
A 25-person company sells a CRM to three verticals: real estate, insurance, and financial advisors. Each vertical has a dedicated sales team that lobbies for vertical-specific features. The single product team cannot build three roadmaps, and the current approach of alternating between verticals each quarter leaves every vertical feeling underserved.
The PM creates one unified now next later SaaS roadmap but tags every item with its vertical applicability: single-vertical, two-vertical, or cross-vertical. The scoring rubric adds a "breadth" multiplier: cross-vertical items get a 2x multiplier on customer impact because they serve the entire customer base. Single-vertical items need to demonstrate outsized impact within their vertical to overcome the multiplier disadvantage. " After scoring, the roadmap naturally balances: Now contains 2 cross-vertical items and 1 item for each vertical.
Next contains a mix driven by evidence strength. The vertical sales teams stop lobbying because they can see their items on the roadmap with clear graduation criteria, and the breadth multiplier gives them an incentive to frame requests in cross-vertical terms when possible. The PM reviews the vertical distribution quarterly to ensure no vertical goes two full quarters without a Now item.
Best Practices
Limit your Now horizon to what your team can actually ship in one to two cycles. If Now has more than 8-10 items for a team of 5-8 engineers, it is overloaded. An overloaded Now column creates the illusion of progress while everything moves slowly. Trim ruthlessly and push items to Next if they cannot start within the current cycle.
Weight customer impact by segment and revenue, not just request count. Five enterprise accounts requesting a feature represent different urgency than fifty free-tier users requesting the same thing. Build segment weights into your scoring rubric so the roadmap reflects business value, not just popularity. Without this weighting, free-tier noise can drown out high-value signals.
Score confidence independently from impact. A feature might be high-impact but low-confidence if you do not yet understand the problem well enough to build the right solution. Low confidence means the item belongs in Next for discovery, not in Now for development. Conflating impact with confidence leads to expensive rework when you build the wrong thing.
Review the Later horizon monthly, not just the Now and Next. Later is where strategic thinking lives. If you only review Now and Next, your team becomes purely reactive to incoming requests. A monthly Later review surfaces emerging patterns, retires stale ideas, and ensures your long-term product direction stays connected to your short-term execution.
Maintain a "declined" list with documented reasons. Not every request belongs on the roadmap. Declining requests explicitly, with a reason, prevents zombie ideas from resurfacing repeatedly. It also builds trust with stakeholders who can see that their request was considered even if it was not accepted.
Use the same scoring rubric for internal requests and customer requests. Product teams sometimes give internal stakeholder requests a free pass into Now without scoring them. This creates two classes of roadmap citizens and erodes trust in the process. Every item earns its horizon placement through the same criteria.
Keep horizon definitions stable for at least two quarters. Changing what Now, Next, and Later mean every few weeks destroys the team's ability to internalize the system. Lock the definitions, refine the scoring rubric if needed, but do not redefine the horizons until you have enough data to know what is not working.
Tie each Now item to a measurable outcome, not just a feature description. "Build CSV export" is a feature. "Reduce data-export support tickets by 40%" is an outcome. Outcome framing helps the team make better design decisions and gives you a way to validate whether the shipped feature actually delivered value.
Common Mistakes
Treating the Now column as a priority-ordered backlog instead of a commitment horizon
Correction
Now is not a ranked list. It is a set of items the team is actively building or about to build within the current cycle. If you start ranking items within Now, you recreate the problems of a traditional backlog with implicit date promises. Keep Now as an unordered set of committed work.
Prioritization within Now happens in sprint planning, not on the roadmap. Watch for this when stakeholders ask "what is the top item in Now" because that question signals they are reading Now as a ranked list.
Letting a single high-value customer dictate the Now column
Correction
When a large customer escalates a request, the pressure to jump it straight to Now is intense. This bypasses your scoring rubric and graduation criteria, training the team to treat the roadmap as negotiable under pressure. Instead, run the request through the rubric. If it scores high and meets graduation criteria, it belongs in Now.
If it does not, place it in the appropriate horizon and communicate the graduation path to the customer. The fast-track exception should only apply to critical bugs and security issues, not feature requests from important accounts.
Never moving items out of Later, turning it into a graveyard
Correction
Later should contain 20-40 items at most for a mid-stage SaaS product. If it grows past 50-60 items, you have stopped curating it. A quarterly Later cleanup should archive items that have not gained any customer signal in 90 days, decline items that no longer align with product strategy, and promote items that have accumulated enough evidence to enter Next. Watch for a Later column that only grows and never shrinks.
That signals the team is using Later as a polite way to say no without actually saying no.
Scoring all items before gathering sufficient customer evidence
Correction
Teams sometimes score every item in one sitting using gut estimates for customer impact and confidence. This produces a roadmap that feels data-driven but is actually opinion-driven. For items where you have fewer than three data points (customer interviews, support tickets, usage metrics), mark the confidence score as 1-2 and place the item in Later regardless of estimated impact. The solution is to gather evidence before scoring, not to guess and then treat the guess as fact.
You can spot this mistake when your Later column is nearly empty after initial scoring.
Running the roadmap review and sprint planning as a single meeting
Correction
The roadmap review operates at the horizon level: what moves between Now, Next, and Later. Sprint planning operates within Now: what specific tasks get assigned to this sprint. Combining them creates a meeting that is too long, mixes strategic and tactical decisions, and usually results in the tactical winning because it feels more urgent. Run the roadmap review first (biweekly, 30-45 minutes), then sprint planning separately.
The roadmap review feeds sprint planning by updating what is in Now, but they are distinct decisions made by partially different groups.
Publishing the internal roadmap with scores and internal notes to customers
Correction
Customers should see a simplified view: 3-5 items per horizon with plain-language descriptions and no internal scoring data. Showing confidence scores of 2 out of 5 to a customer communicates uncertainty in a way that erodes trust rather than building it. Create two views of the roadmap: an internal view with full scoring data and notes, and an external view with curated descriptions and horizon context. The external view answers "what are you working on and what is coming" without exposing the sausage-making.
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.
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.
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 often should I review my Now-Next-Later SaaS roadmap?
Review the full roadmap biweekly, aligned to your sprint or release cycle. The Now column may need more frequent checks (weekly standup-level glances), but formal horizon reviews where items graduate between columns should happen every two weeks. Additionally, run a deeper Later-horizon review monthly to surface emerging themes and archive stale items. If you review less frequently than biweekly, the roadmap drifts from reality and loses team trust.
How do I handle urgent customer escalations without blowing up my Now column?
Define a fast-track policy before the first escalation arrives. Critical bugs and security vulnerabilities bypass normal graduation and enter Now immediately. Feature requests from important customers do not qualify for fast-track. Instead, run them through your scoring rubric. If the item scores high and meets graduation criteria, it moves to Now. If not, place it in the correct horizon and share the graduation criteria with the account team so they can set expectations. This prevents a pattern where every escalation becomes urgent by default.
Should I build my now next later SaaS roadmap before or after sprint planning?
The roadmap review happens before sprint planning because it determines what is in the Now horizon, which feeds sprint planning. Think of the roadmap as the strategic layer (what and why) and sprint planning as the execution layer (how and who). Run the roadmap review at the start of each cycle, then sprint-plan within the Now items. Combining both into one meeting creates a bloated session that favors tactical decisions over strategic ones.
How many items should be in each horizon for a typical SaaS team?
For a team of 5-8 engineers, aim for 4-8 items in Now, 10-20 in Next, and 20-40 in Later. If Now exceeds 10 items, your horizon is too loose and you are overcommitting. If Later exceeds 50, you have stopped curating and it has become a dumping ground. These numbers scale linearly with team size, but the ratios should hold: Now should always be the smallest column because it represents active commitment.
How do I prevent the Later column from becoming a feature graveyard?
Run a monthly Later cleanup. Archive any item that has received zero new customer signals in 90 days. Decline items that no longer align with your product strategy, and communicate the decline with a one-sentence reason. Promote items that have accumulated new evidence since their last review. If an item sits in Later for two consecutive quarterly cleanups without movement, it should be archived. A healthy Later column is 20-40 items that are actively being watched, not 200 items collecting dust.
Can I use the Now-Next-Later framework alongside OKRs or a theme-based roadmap?
Yes, and it works best when you do. OKRs or product themes define the strategic direction (what outcomes you are pursuing this quarter). The Now-Next-Later roadmap organizes the work that supports those outcomes into confidence-based horizons. Each item on the roadmap should link to an OKR or theme. Items that do not link to any current objective are candidates for Later or decline. This pairing gives you strategic clarity from OKRs and execution flexibility from Now-Next-Later.
Why does my roadmap keep drifting back to a date-based format?
This usually happens because stakeholders, especially sales and leadership, keep asking "when will this ship." The fix is not to ban dates entirely but to reframe the question. Train stakeholders to ask "what needs to happen for this to move to Now" instead of "what date will this be done." Share graduation criteria publicly. When you answer with conditions instead of dates, you shift the conversation from false precision to honest progress tracking. If drift persists, check whether your review cadence is frequent enough, because infrequent reviews force people to ask for dates as a proxy for progress.