Building a Now Next Later Roadmap Template
This skill teaches you how to design and set up a reusable visual roadmap template that represents the Now, Next, and Later horizons with the right level of detail, making it easy to populate, share, and maintain across tools like Miro, Notion, ProductBoard, or spreadsheets.
Start with three columns or swim lanes labeled Now, Next, and Later. Each column gets a distinct visual weight: Now is dense with detail (owners, status, effort), Next is moderately detailed (problem statement, confidence level), and Later is deliberately sparse (strategic theme, hypothesis). Add a confidence indicator to every item, a legend explaining what each horizon means, and a last-updated timestamp. Choose the tool your team already lives in so adoption friction is zero.
Outcome: You produce a ready-to-use, shareable roadmap template that visually distinguishes the three horizons, enforces appropriate detail levels per horizon, and can be populated and updated by your team in under five minutes per review cycle.
Prerequisites
- Basic understanding of the Now-Next-Later Framework and what each horizon represents
- Access to at least one collaborative tool (Miro, Notion, Google Sheets, ProductBoard, or similar)
- A preliminary list of initiatives or features to populate the template with real data
Overview
A now next later roadmap template is the physical artifact that turns the Now-Next-Later Framework from an abstract prioritization concept into a living, working document. Without a well-structured template, teams default to flat backlogs or Gantt charts, and the entire point of the framework, sequencing by confidence rather than dates, gets lost. The template is what makes the framework stick.
The core challenge in building this template is not choosing the right tool. It is encoding the right information density gradient across the three horizons. Now items need enough detail that an engineer can pick one up and start work today: owner, status, scope boundary, effort estimate, and acceptance criteria or a link to them. Next items need enough shape that stakeholders understand what problem is being solved and how confident the team is, but they should not have sprint-level detail because that detail will change. Later items should be deliberately vague, capturing a strategic theme or hypothesis without locking in a solution. If every column looks the same, the template is failing. The visual contrast between horizons is the single most important design decision you will make.
The artifact you produce is a reusable template, either a board, a database, or a spreadsheet, with three clearly labeled sections, a defined card or row schema for each horizon, a confidence indicator on every item, a legend that explains the horizons to newcomers, and a last-updated timestamp. Once built, this template becomes the canonical view your team updates weekly and the view you share with stakeholders. It replaces the question "when will feature X ship?" with the more productive question "is feature X in Now, Next, or Later, and what would move it forward?" Related skills like categorizing items into horizons and communicating roadmaps to stakeholders depend on having a solid template in place first.
How It Works
The template works by exploiting a visual information density gradient that mirrors the confidence gradient at the heart of the Now-Next-Later Framework. Humans process spatial layout and visual weight faster than they read text. When a stakeholder glances at the roadmap and sees a dense, detailed Now column, a moderately populated Next column, and a sparse Later column, they intuitively understand three things without reading a word: what is certain, what is probable, and what is speculative. This is the mechanism that prevents the most common roadmap dysfunction, treating every item as an equally firm commitment.
The gradient works at two levels. First, the number of metadata fields decreases as you move right. A Now card might carry seven fields (title, owner, status, effort, confidence, link to spec, target iteration). A Next card carries four (title, problem statement, confidence, open questions). A Later card carries two or three (title, strategic theme, hypothesis). Second, the visual styling reinforces the gradient. Now cards are fully opaque with solid borders. Next cards might use a lighter background or a dashed border. Later cards are the lightest, sometimes just text with a tag. This dual encoding, data density plus visual styling, is what makes the template self-documenting. A new team member or a VP who opens the board for the first time can orient themselves in seconds.
The confidence indicator deserves special attention because it is the single field that appears on every item across all three horizons, and it is the field that drives movement between horizons. Confidence is not a binary; it is a spectrum. A simple three-level system works well: high (we have evidence and alignment), medium (we have a hypothesis but open questions), low (this is a bet based on intuition or early signals). The indicator can be a color dot, an emoji, a dropdown, or a numerical score. What matters is that it is visible without clicking into the card, because the first thing a reviewer scans for is "has anything changed confidence since last time?" If confidence is buried inside a card detail, it will not get updated.
Finally, the template needs an anchor element: a legend and a timestamp. The legend is a small block, usually in the top-left corner, that defines what Now, Next, and Later mean in your team's specific context (e.g., Now = committed for this quarter, Next = targeted for next quarter, Later = 6+ months out). The timestamp ("Last reviewed: June 12, 2025") signals freshness. A roadmap without a date is a roadmap nobody trusts. Together, the legend and timestamp turn a board of sticky notes into a credible communication tool that can be shared outside the product team without a live walkthrough.
Step-by-Step
Step 1: Choose Your Tool Based on Team Habits
Select the tool your team already uses for daily work. If your engineers live in Notion, build the template in Notion. If your stakeholders are most comfortable with Google Sheets, use Google Sheets. If your design and product team already collaborates in Miro, use Miro.
The goal is zero adoption friction. Do not introduce a new tool just for the roadmap unless you have executive sponsorship to migrate workflows. Evaluate the tool against three requirements: can it represent three distinct visual sections (columns, swim lanes, or tabs), does it support card-level or row-level metadata fields, and can you share a read-only or comment-only view with stakeholders? If the tool fails any of these, pick a different one.
Tip: If your team is split across tools (e.g., engineering in Jira, product in Notion), build the canonical template in the product team's tool and create a lightweight mirror or embed for engineering. Do not try to maintain two full templates.
Step 2: Create the Three-Column Layout
Set up three clearly labeled sections: Now, Next, and Later. In a whiteboard tool like Miro, these are three vertical swim lanes or framed sections arranged left to right. In Notion, they are three columns in a Board view or three filtered views of a single database. In a spreadsheet, they can be three column groups separated by a blank spacer column, or three tabs.
Label each section with a clear heading and a one-sentence definition. " Make the Now section visually wider or more prominent than Later. This spatial weighting reinforces the confidence gradient.
Tip: Use a horizontal left-to-right layout rather than top-to-bottom. Left-to-right maps naturally to a timeline metaphor (present on the left, future on the right) and is the convention stakeholders expect.
Step 3: Define the Card Schema for Each Horizon
Design the fields each card or row will carry, and vary the schema by horizon. For Now, include: title, owner (the single person accountable), status (not started, in progress, blocked, done), effort estimate (t-shirt size or story points), confidence level (high/medium/low), and a link to the detailed spec or ticket. For Next, include: title, problem statement (one sentence describing the customer or business problem), confidence level, and open questions (the top 1-3 unknowns to resolve before this moves to Now). ").
Write out a sample card for each horizon so you have a reference. The decreasing field count is intentional; it signals that Later items are not yet defined enough to have owners or effort estimates.
Tip: Resist the urge to add fields to Later cards. If someone asks for an effort estimate on a Later item, that is a signal the item might belong in Next, not that your template needs more fields.
Step 4: Add Confidence Indicators Visible at Glance
Implement a confidence indicator on every item in every horizon. The indicator must be visible without opening or expanding the card. In Miro, use colored dots (green = high, yellow = medium, red = low) on the card surface. In Notion, use a Select property with colored tags that render on the board view.
In a spreadsheet, use conditional formatting on a Confidence column so cells turn green, yellow, or red automatically. Choose a three-level scale rather than five. Five levels create false precision and slow down review meetings because people debate between a 3 and a 4. Three levels force a clear call: we are confident, we have open questions, or we are speculating.
Document the definitions for each level in the legend.
Tip: If your tool supports emoji, a simple traffic light emoji (🟢🟡🔴) in the card title works as a quick-scan confidence indicator without relying on color alone, which helps with accessibility.
Step 5: Apply Visual Styling to Reinforce the Gradient
Add visual differentiation beyond just the column labels. In Miro, give Now cards a solid border and full-opacity background, Next cards a lighter background or dashed border, and Later cards the lightest background or a simple text-on-frame appearance. In Notion, use different card cover colors or icon conventions per horizon. In a spreadsheet, use bolder font and background shading for Now rows, medium for Next, and plain for Later.
The goal is that someone seeing the board for the first time can tell which horizon is which without reading the headers, purely from the visual weight. Test this by blurring your eyes or zooming out to 25%. Can you still tell the three sections apart? If not, increase the contrast.
Tip: Avoid using only color to differentiate. Combine color with another visual dimension like border style, icon, or font weight. This ensures the template works for colorblind team members and in grayscale prints.
Step 6: Build the Legend and Metadata Block
Add a legend block to the top or top-left of the template. The legend should contain: the team or product name, the definition of each horizon (Now, Next, Later) in one sentence each, the confidence level definitions, and a "Last reviewed" date field. In Miro, this is a sticky note group or a framed text box. In Notion, it can be a callout block above the database view.
In a spreadsheet, dedicate the first three rows to this metadata. The legend serves two audiences: your own team (to keep definitions consistent over time) and stakeholders (to orient themselves without asking questions). Update the "Last reviewed" date every time the roadmap is reviewed in a team meeting. A stale date is a trust killer.
Tip: Include a link to your graduation criteria in the legend. This connects the template to the process of moving items between horizons and prevents ad-hoc promotions. See [defining graduation criteria](/skills/defining-graduation-criteria-between-horizons) for details.
Step 7: Populate with Real Data and Validate
Fill the template with your actual initiatives, not hypothetical examples. Start with Now, because those items are the most defined and will stress-test whether your card schema captures enough detail. Then populate Next and Later. As you fill cards, watch for friction: are you struggling to fit information into the schema?
Are you skipping fields because they feel irrelevant? Are Later items accidentally getting Now-level detail? Each friction point reveals a template design issue to fix now, before the team adopts it. Aim for 5-10 items in Now, 5-8 in Next, and 3-6 in Later for an initial population.
If your Now column has 20+ items, your team is overcommitted. If Later has 20+ items, you need a separate parking lot or strategic backlog.
Tip: Populate the template yourself first, then have one other team member populate independently without guidance. Where they get confused or deviate from your intent, the template is ambiguous and needs clearer labeling or constraints.
Step 8: Set Up Access Permissions and Sharing
Configure two levels of access. The product team gets edit access and will update the roadmap weekly. Stakeholders, leadership, and cross-functional partners get view-only or comment-only access. This prevents well-intentioned edits from corrupting the single source of truth.
In Notion, create a shared link with "Can comment" permissions. In Miro, use viewer-only sharing with a "request edit" flow. In Google Sheets, use "Can comment" or publish a view-only link. Add the sharing link to your team's wiki, Slack channel topic, or wherever stakeholders go for product information.
The best template in the world is useless if people cannot find it.
Tip: Pin the roadmap link in your main product Slack channel and reference it by name in every stakeholder update. The roadmap should have a nickname (e.g., "the product board" or "the horizon map") so people can refer to it verbally.
Step 9: Schedule the First Review and Iterate on the Template
Book a 30-minute review meeting within one week of launching the template. Use this meeting to walk through each horizon, update confidence levels, and move items that have changed. " Capture the answers and adjust the template schema accordingly. Common first-iteration changes include adding a "blocked by" field to Now items, adding a "target customer segment" field to Next items, or removing a field nobody fills in.
Plan to iterate on the template for three weekly cycles before considering it stable. After three cycles, the template structure should be locked and changes should be rare.
Tip: Record the decisions made during the review meeting directly on the roadmap (e.g., as a "Review Notes" sticky or a changelog section). This creates an audit trail that is invaluable when someone asks "why did we move X to Later?"
Examples
Example: Early-Stage SaaS Startup (4-Person Team, Google Sheets)
A pre-Series A SaaS startup with one product manager, two engineers, and one designer needs a roadmap they can share with their three angel investors and early customers. Budget for tooling is zero. The team uses Google Workspace for everything. They have about 15 initiatives across all horizons.
The PM creates a Google Sheet with three column groups separated by gray spacer columns: Now (columns A-G), Next (columns I-L), and Later (columns N-P). " Row 2 contains one-sentence horizon definitions. Row 3 is the header row. Now columns are: Title, Owner, Status (dropdown: Not Started, In Progress, Blocked, Done), Effort (S/M/L), Confidence (🟢🟡🔴 via dropdown), Link to Spec.
Next columns are: Title, Problem Statement, Confidence, Open Questions. Later columns are: Title, Strategic Theme, Hypothesis. Conditional formatting turns the Confidence column green, yellow, or red. The PM populates 6 items in Now, 5 in Next, and 4 in Later.
She shares a view-only link with investors and pins it in the team Slack. The first review meeting surfaces that engineers want a "Blocked By" column in Now, so she adds it in week two. By week three, the template is stable and the team reviews it every Monday in 20 minutes.
Example: Mid-Size B2B Product Team (12 People, Notion)
A B2B product team with two squads, a group PM, and regular stakeholder reviews with sales and customer success. The company uses Notion as its internal wiki. They have about 22 initiatives and need both a team view (detailed) and a stakeholder view (simplified).
The group PM creates a single Notion database called "Product Roadmap" with properties: Title, Horizon (Select: Now, Next, Later), Squad (Select: Growth, Platform), Confidence (Select: High, Medium, Low with green/yellow/red colors), Owner (Person), Status (Select: Not Started, In Progress, Blocked, Shipped), Problem Statement (Text), Effort (Select: S, M, L, XL), Open Questions (Text), Strategic Theme (Select from company OKRs), and Spec Link (URL). She creates two Board views: "Team View" grouped by Horizon, showing all fields, and "Stakeholder View" grouped by Horizon, showing only Title, Confidence, and Squad. The Stakeholder View uses a filter to hide items with Status = Shipped. A callout block above both views contains the legend: horizon definitions, confidence definitions, and the last-reviewed date.
She shares the Stakeholder View link with sales and CS leads with comment-only permissions. During the first review, the team realizes they need a "Customer Segment" property on Next items so sales can see which prospects benefit. She adds it in week two. The template stabilizes by week three and becomes the single artifact referenced in all cross-functional meetings.
Example: Enterprise Product Org (3 Product Lines, Miro)
An enterprise company with three product lines, each with its own PM, needs a unified roadmap view for the CPO's quarterly board presentation. The company uses Miro for cross-team workshops. Total initiative count across all lines is about 40, and the board wants a single visual they can absorb in 90 seconds.
" Inside the frame, three horizontal swim lanes represent the three product lines (Payments, Analytics, Compliance). Each swim lane is divided into three vertical sections: Now, Next, Later. Now cards are blue with solid borders and carry Title, Owner, Status, Confidence dot, and Effort. Next cards are light blue with dashed borders and carry Title, Problem Statement, and Confidence dot.
Later cards are white with gray text and carry only Title and Strategic Theme. A legend frame in the top-left defines horizons and confidence levels, plus the last-reviewed date. The total card count is 38 items, within the 25-per-product-line guideline since no single line exceeds 14. For the board presentation, the PM duplicates the frame, removes the Owner and Status fields from Now cards to simplify, and exports it as a single-page PDF.
The board can scan all three product lines and all three horizons in one view. After the board meeting, the CPO requests a "Revenue Impact" tag on Now items, which gets added in the next iteration. The working Miro board is updated weekly by each PM; the board PDF is regenerated quarterly.
Example: Solo Product Manager Using ProductBoard
A solo PM at a 30-person company uses ProductBoard for feature tracking and wants to create a now next later roadmap template within the tool rather than maintaining a separate artifact. The company has about 18 features in various stages.
The PM creates a custom Roadmap view in ProductBoard using the timeline-free "Column" layout. She defines three columns mapped to a custom Status field: Now, Next, Later. Each feature card in ProductBoard already carries a title, description, and user impact score. She adds a custom field called "Confidence" with three options (High, Medium, Low) and color-codes them green, yellow, red.
For Now features, she ensures the Owner and Effort fields are filled. For Next features, she writes a one-line problem statement in the description and leaves Effort blank. For Later features, she tags each with a strategic objective from the company's OKR list and writes a hypothesis in the description. She creates two views: "Internal Roadmap" showing all fields, and "Customer-Facing Roadmap" showing only Title, Confidence, and the column position, with internal-only features filtered out.
The customer-facing view is published via ProductBoard's portal feature. She adds a text widget at the top of each view serving as the legend. During her first solo review, she realizes three Later items have enough customer evidence to move to Next, which validates that the confidence indicators are working. The template stabilizes after two cycles and she reviews it every Friday in a 15-minute solo session.
Best Practices
Enforce the information density gradient ruthlessly. Every time someone adds a detailed effort estimate or owner to a Later item, redirect them. The gradient is not aesthetic preference; it is a communication mechanism that signals confidence. When Later items carry the same detail as Now items, stakeholders lose the ability to distinguish commitments from speculation, and the most common roadmap failure, treating everything as a promise, returns.
Keep the total item count under 25 across all three horizons. A roadmap with 50 items is a backlog wearing a roadmap costume. Cognitive overload sets in around 20-25 items, and reviewers start skimming rather than engaging. If you have more initiatives than this, group related items under a single theme card and link to a separate detail view. The roadmap should be scannable in under 60 seconds.
Update the template in a ritual, not ad hoc. Designate a weekly or biweekly review cadence and batch all updates to that moment. Ad hoc updates create notification fatigue and make it impossible for stakeholders to know which version they last saw. The review meeting is also when confidence levels get reassessed, which is the engine that drives items between horizons.
Use one canonical template, not multiple copies. Every fork creates drift. If different teams need different views, use filtered views of the same underlying data (in Notion or ProductBoard) or separate frames pointing to the same source (in Miro). If you catch someone maintaining a "shadow roadmap" in a slide deck, that is a signal your template is not meeting their needs, not that they need a copy.
Include a parking lot or icebox section below or beside the Later column. Not every idea belongs on the roadmap. Items that are interesting but have no strategic alignment, no customer signal, or no sponsor should go to the parking lot rather than inflating the Later column. Review the parking lot monthly and archive anything older than 90 days.
Design for the stakeholder's 10-second scan, not the product manager's 10-minute deep dive. The primary consumer of this template is someone who opens it for 10 seconds to answer one question: "Is my thing on the roadmap, and where is it?" If they cannot answer that question at a glance, the template is too complex. Use clear titles, visible confidence indicators, and enough whitespace that the eye can find items quickly.
Version the template schema, not the content. When you change the card fields (e.g., adding a new property), note the change and date it in the legend. This prevents confusion when someone remembers a field that no longer exists or does not recognize a new one. Schema changes should be rare after the first three review cycles.
Common Mistakes
Making all three columns look identical with the same fields and visual styling
Correction
This is the most common template failure and it happens because it feels tidier to have uniform cards. When every column carries the same fields, stakeholders cannot distinguish confidence levels at a glance, and the roadmap reads like a flat prioritized backlog. " because the visual uniformity implied equal certainty. Fix it by removing fields from Next and Later cards until the visual contrast is unmistakable at a glance.
If your Later cards look as detailed as your Now cards, delete fields until they do not.
Building the template in a tool nobody on the team uses regularly
Correction
This happens when the product manager falls in love with a specialized roadmapping tool and mandates adoption. The template looks beautiful on day one and is abandoned by week three because nobody opens the tool as part of their daily workflow. Watch for the signal: if the PM is the only person updating the roadmap, the tool choice is wrong. Rebuild the template in whatever tool the team already has open eight hours a day, even if it is less visually polished.
A Google Sheet that gets updated beats a ProductBoard instance that collects dust.
Overloading the Now column with 15-20+ items
Correction
" An overloaded Now column signals overcommitment, not ambition. Stakeholders see 20 Now items and either panic about capacity or dismiss the roadmap as unrealistic. The diagnostic is simple: count the items and divide by team capacity. If your team can realistically ship 5-7 items in a cycle, Now should contain 5-7 items.
Move the overflow to Next with a note about what would need to be true to pull them into Now. See reprioritizing across horizons for the process.
Omitting the confidence indicator or burying it inside card details
Correction
Teams skip the confidence indicator because it feels like extra overhead, or they add it as an internal field that is only visible when you click into the card. Without a visible confidence signal, the roadmap cannot serve its primary function: communicating what is certain versus speculative. The symptom is review meetings where the team spends 10 minutes discussing whether a Next item is "really a Next" or "more of a Later." A visible confidence dot resolves this in seconds. Add the indicator to the card surface, make it the first thing visible after the title, and update it every review cycle.
Creating the template but never adding a legend or last-reviewed date
Correction
Without a legend, every new viewer needs a live explanation of what Now, Next, and Later mean in your context. Without a date, nobody knows if the roadmap reflects this week's reality or last quarter's wishful thinking. " in Slack. This question is a trust erosion event.
Add the legend in the first session and update the date at every review. It takes 15 seconds and prevents hours of follow-up questions.
Treating the template as a finished product after the first build
Correction
The first version of any template is a hypothesis. Teams that skip the iteration phase end up with fields nobody uses, missing fields that force workarounds, or a layout that does not match how the review meeting actually flows. The signal is team members maintaining side notes or Slack messages to supplement what the template does not capture. Plan three weekly iterations where you explicitly ask "what is the template missing?" and "what field did nobody fill in?" After three cycles, lock the schema.
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.
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.
Related Skills from Other Methods
Frequently Asked Questions
How do I build a now next later roadmap template in a tool that does not support columns or swim lanes?
If your tool only supports linear lists (like a basic Trello board or a flat document), use headings as section dividers. Create three headings, Now, Next, Later, and list items under each. Apply visual differentiation through formatting: bold for Now items, regular weight for Next, and italic or gray text for Later. Add the confidence indicator as a prefix emoji (🟢🟡🔴) on each line. This is less elegant than a columnar layout but still communicates the gradient. If even headings are not available, use three separate documents or pages and link them from a master index page.
How many items should each horizon contain?
A practical ceiling is 5-10 items in Now, 5-8 in Next, and 3-6 in Later, for a total under 25. Now should never exceed what your team can realistically execute in the current cycle. If Now has 15 items and your team ships 5 per cycle, 10 of those are not really Now. Next can be slightly larger because it is a staging area. Later should be the smallest because it represents bets, not plans. If your Later column is the largest, you are using it as a backlog instead of a strategic horizon.
Should I build one template per team or one template for the entire product organization?
Build one template per team for weekly operational reviews and one aggregated template for leadership or cross-team visibility. The team-level template is detailed and updated weekly. The aggregated template is simplified (fewer fields, higher-level items) and updated biweekly or monthly. Do not try to serve both audiences with a single template. The detail level that helps engineers is noise for executives, and the summary that satisfies executives leaves engineers without actionable information.
How often should I update the now next later roadmap template structure versus the content?
Content (items, confidence levels, status) should be updated every review cycle, typically weekly. Template structure (fields, layout, visual styling) should be iterated for the first three cycles and then locked. After the lock, structural changes should happen at most once per quarter, triggered by a clear gap rather than a preference. Frequent structural changes confuse the team and break muscle memory. If you find yourself redesigning the template monthly, the root issue is likely unclear horizon definitions, not template design.
Why does my roadmap template keep drifting into a timeline or Gantt chart?
This drift happens because stakeholders (and sometimes PMs) instinctively want dates, and the easiest way to add dates is to stretch horizons along a timeline axis. The fix is structural: remove any date fields from the template except the "Last reviewed" timestamp. ", redirect to confidence levels and graduation criteria. "This is in Next with medium confidence. " If your tool defaults to a timeline view (like Jira's roadmap), switch to a board or kanban view explicitly. The template's layout must resist the gravitational pull toward dates.
Should I build the now next later roadmap template before or after categorizing items into horizons?
Build the template first, then populate it. The template defines the information schema for each horizon, and that schema shapes how you categorize. ) or is wishfully placed there. Building the template with a handful of real items is part of the validation process described in Step 7. See [categorizing items into horizons](/skills/categorizing-items-into-now-next-later-horizons) for the categorization process itself.
Can I use a now next later roadmap template for non-product work like marketing or engineering platform initiatives?
Yes, the template structure is domain-agnostic. The three-horizon confidence gradient applies to any work where you need to communicate what is committed, what is planned, and what is speculative. For marketing, Now might be campaigns in execution, Next might be campaigns in creative development, and Later might be channel experiments under consideration. For platform engineering, Now might be infrastructure migrations underway, Next might be approved RFCs awaiting scheduling, and Later might be architectural bets tied to future product needs. , replace "Owner" with "Campaign Lead" or "Tech Lead") but keep the gradient structure intact.