Product

Product Roadmap Template

A roadmap is a promise about priorities, not a schedule. This template ties every initiative to a goal, says how confident you are in each date, keeps a visible list of what you are not doing, and logs every change with its reason. Copy it as-is, or start from the roadmap example closest to your audience.

Updated 2026-10-27

Copy and adapt

The template

Product roadmapTemplate

[Product] roadmap, [horizon], updated {{date}}

Owner: [one name] Audience: [leadership / product teams / customers] Review cadence: [monthly / every sprint review] Related: [[Product strategy]]

Goals for this horizon

[Goal with a number and a baseline: from X to Y by date]
[Goal]
[Goal, three at most]

Now (committed, in progress)

[Initiative]: [outcome for the user, not the feature list]. Serves: [goal #]. Owner: [name]. Target: [month]. Confidence: [high / medium / low]
[Initiative]: ...

Next (planned, not yet dated)

[Initiative]: [why it is next]. Serves: [goal #]. Starts when: [condition]

Later (exploring, no commitment)

[Idea]: [what we need to learn before it moves up]

Release plan

[Release name], target [YYYY-MM-DD]

In scope: [items]
Out of scope: [items moved to a later release]
Go/no-go criteria: [measurable checks]
Milestones: [code freeze, beta, submission, rollout dates]
Rollback: [how to undo it]

Not doing (and why)

[Request]: [who asked, why not now, what would change our mind]

Risks and dependencies

[Risk or dependency] (watch: [name]) [what happens if it bites]

Change log

{{date}}: [what moved, from where to where, why, who decided]

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Quarterly product roadmap for leadership

When it fits: Use this when the exec team and sales read the roadmap every month, a large deal is pulling priorities one way and your activation goal pulls them another, and the trade-off has to be written down.

Quarterly product roadmap for leadershipExample 1

Ledgerline roadmap, Q1 2027, updated 2026-10-27

Owner: Priya Raman (Head of Product) Audience: exec team, sales leads Review cadence: first Monday of each month Related: [[Ledgerline strategy 2027]]

Goals for this horizon

Trial-to-paid conversion from 9 percent to 12 percent by March 31.
Close three enterprise deals above $40k ARR.
QuickBooks sync support tickets from 140 a month to 70.

Now (committed, in progress)

Guided setup: new agencies send their first invoice in one session instead of three. Serves: 1. Owner: Marta. Target: February. Confidence: high
SAML single sign-on: enterprise IT can enforce their identity provider. Serves: 2. Owner: Dev. Target: March 15. Confidence: medium (Dev is out Feb 9 to 20)
Sync retry and error messages: failed QuickBooks syncs retry and tell the user which invoice failed. Serves: 3. Owner: Hugo. Target: January. Confidence: high

Next (planned, not yet dated)

Multi-currency invoices: four of the eight enterprise prospects bill in EUR. Starts when: SSO ships.
Client portal redesign: starts when guided setup is measured for a full month.

Later (exploring, no commitment)

Expense categorization suggestions: need to know whether agencies trust automatic categories before building anything. Five customer interviews in Q1.

Not doing (and why)

Custom report builder: requested by two customers, roughly four months of work, serves none of the three goals. Revisit if it blocks an enterprise deal.
Xero integration: not until QuickBooks sync stops generating 140 tickets a month.

Risks and dependencies

SSO has one engineer and a two-week absence in the middle (watch: Priya). If it slips past March 15, the Halvorsen deal slips with it.

Change log

2026-10-20: SSO moved from Next to Now after Halvorsen & Co ($62k ARR) made it a contract condition. Client portal moved from Now to Next to free Dev. Decided by Priya and Tom (CEO). Ines (sales) disagreed on deferring the portal; her concern is noted for the February review.

2.Release plan for a mobile app version

When it fits: Use this when the roadmap item is now a dated release, the date is squeezed by app store review and a holiday campaign, and everyone needs the same go/no-go criteria before the build is submitted.

Release plan for a mobile app versionExample 2

Pantry 3.0 release plan, target 2026-12-08, updated 2026-10-27

Owner: Kofi Mensah (release manager) Audience: mobile team, marketing, support Review cadence: every Tuesday until launch Related: [[Pantry roadmap]]

Goal for this release

Households that share a shopping list keep using the app: week-4 retention for shared lists from 31 percent to 40 percent.

In scope

Shared shopping lists with live updates (Lucía)
Offline mode for lists and recipes (Arjun)
New three-screen onboarding (Beth)

Out of scope

Apple Watch app: moved to 3.1 in January. Not enough testing time before the freeze.

Milestones

Code freeze: 2026-11-24
Beta to 300 TestFlight and Play testers: 2026-11-25
Store submission: 2026-12-01
Phased rollout: 1 percent on Dec 8, 10 percent on Dec 10, 50 percent on Dec 12, everyone on Dec 15

Go/no-go criteria (checked on Nov 30)

Crash-free sessions in beta above 99.5 percent
No open P1 bugs; P2 bugs each have an owner
Sync conflict test suite passes on both platforms
Support macro for shared lists published

Rollback

Offline mode and shared lists sit behind flags. Turning a flag off does not need a new build.

Risks and dependencies

Marketing's holiday campaign starts Dec 8. If review takes longer than a week, the campaign runs with the 2.9 screenshots (watch: Nadia).

Change log

2026-10-22: Watch app cut from 3.0. Kofi and Lucía agreed; Nadia (marketing) asked for it back if beta finishes early. It will not come back; the freeze date is fixed.

3.Internal platform team roadmap

When it fits: Use this when your customers are other engineering teams, they keep asking for things you cannot staff, and the roadmap has to explain what they will and will not get from you this half.

Internal platform team roadmapExample 3

Platform team roadmap, H1 2027, updated 2026-10-27

Owner: Grace Liu (platform lead) Audience: six product engineering teams Review cadence: monthly, in the engineering all-hands Related: [[Platform charter]]

Goals for this horizon

Median CI time on the main repo from 22 minutes to 10.
Every service deploys without downtime by June 30.
No production database on an unsupported Postgres version.

Now (committed, in progress)

Postgres upgrade for the last three databases: billing, search and notifications move off Postgres 14, which reaches end of community support on November 12, 2026. Serves: 3. Owner: Ravi. Target: January 15. Confidence: high
CI dependency caching and test splitting: Serves: 1. Owner: Ewa. Target: February. Confidence: medium (test splitting depends on teams fixing order-dependent tests)

Next (planned, not yet dated)

Blue-green deploys for the remaining 9 services: Serves: 2. Starts when: the Postgres work is done and Ravi is free.

Later (exploring, no commitment)

Preview environment per pull request: two teams want it. We need a cost estimate first; a rough number is $3k a month in compute.

Not doing (and why)

Service mesh: asked for by the payments and search teams. It is a full engineer-quarter, and the pain they described is slow CI, not network policy. Revisit in H2.
Owning other teams' flaky tests: we will build the tooling that finds them; the owning team fixes them.

Risks and dependencies

Test splitting needs each team to fix order-dependent tests, about 40 across the repo (watch: Ewa). Without that, CI drops to roughly 15 minutes, not 10.

Change log

2026-10-14: Preview environments moved from Next to Later after the H1 headcount request was declined. Decided by Grace and Omar (VP Eng).

4.Pre-seed startup 12-month roadmap

When it fits: Use this when you are two founders, the roadmap goes into an investor update or a pitch, and most of it is assumptions you have not tested yet.

Pre-seed startup 12-month roadmapExample 4

Tidewell roadmap, Dec 2026 to Nov 2027, updated 2026-10-27

Owner: Ana Duarte (CEO) Audience: co-founder, angel investors, first hire Review cadence: every month, in the investor update Related: [[Tidewell fundraising]]

Goals for this horizon

40 paying physical therapy clinics by September 2027.
$8k monthly recurring revenue by the seed raise in October 2027.
Prove the core claim: reminder texts cut no-shows by at least 20 percent.

Now (Dec 2026 to Feb 2027, committed)

Two-way SMS reminders and no-show tracking: Serves: 3. Owner: Sam (CTO). Target: live in 10 Austin pilot clinics by January 12. Confidence: high
Pilot measurement: no-show rate before and after for each clinic. Owner: Ana. Target: first readout March 1. Confidence: high

Next (Mar to Jun 2027, planned)

Self-serve onboarding: clinics sign up without a call. Starts when: pilot shows the 20 percent drop.
Calendar sync with the two scheduling systems the pilot clinics use: starts when: six or more pilot clinics ask for it.

Later (Jul to Nov 2027, exploring)

Waitlist backfill: offer a canceled slot to the next patient automatically. Only if clinics say empty slots cost more than no-shows.

Not doing (and why)

Insurance billing: different buyer, regulated, and a year of work for two people.
A patient-facing app: patients already have SMS. An app adds a download step and nothing else.

Kill criteria

If no-shows drop by less than 10 percent across the pilot by March 1, we stop and re-interview clinics before building anything in Next.

Change log

2026-10-26: Calendar sync moved from Now to Next. Sam argued it was required for the pilot; Ana argued manual entry is fine for 10 clinics. Agreed: manual for the pilot, revisit at six requests.

5.Public roadmap for customers

When it fits: Use this when customers will read the roadmap directly, you cannot promise dates in public, and the most requested feature is one you have decided not to build.

Public roadmap for customersExample 5

Castwell public roadmap, updated 2026-10-27

Owner: Jonah Price (product) Audience: Castwell customers and anyone evaluating us Review cadence: updated on the last Friday of each month Related: [[Castwell changelog]]

We do not publish dates. Items in Now are being built; items in Next are next in line; items in Later are ideas we are still testing. Things move, and when they do, the change log below says why.

Recently shipped

Transcripts for every episode, searchable from your public podcast page (October)
Dynamic ad insertion for shows on the Pro plan (September)

Now

Private feeds for paid subscribers: listeners get their own feed URL you can revoke.
Episode analytics by app and country: the most requested analytics change this year.

Guest booking links: guests pick a recording slot and sign the release form in one step.
Import from three more hosts, so switching to Castwell takes minutes.

Later

Chapters with images: we are checking how many listening apps display them.

Not planned

Video podcast hosting: our most requested feature. Storing and serving video would cost roughly ten times what audio costs, and we would have to raise prices for every customer, including the 80 percent who publish audio only. We would rather keep the price. Video podcasters are better served by a dedicated video host today.

How to ask for something

Reply to any Castwell email or post in the community forum. We read every request and tag it to an item above.

Change log

2026-10-27: Episode analytics moved from Next to Now. Two reasons: 212 requests, and the new transcript pipeline made it cheaper to build than we estimated.

What a roadmap template needs to answer

Most roadmap templates are a timeline with colored bars. That shows when things happen. It does not show why, and the why is what gets lost first. Three months later, nobody remembers why the client portal was pushed back, and it gets relitigated in every planning meeting.

A roadmap that holds up answers four questions for anyone who opens it:

What are we trying to change? Two or three goals, each with a number and a baseline.
What are we doing about it, in what order? Initiatives in Now, Next and Later, each tied to a goal.
How sure are we? A confidence level on every committed item, and conditions instead of dates for the rest.
What are we not doing? The requests you declined, with the reason and what would change your mind.

Everything else, from owners to risks to the change log, exists to keep those four answers trustworthy as plans move.

Now, Next, Later or a timeline

A timeline roadmap puts every item on a calendar. It suits release plans and work with fixed external dates, like a regulatory deadline or a launch event. For everything else, it invents precision. An item drawn in May looks committed to May, whatever the footnote says.

Now, Next, Later trades precision for honesty. Now is staffed and in progress, so it gets a target month and a confidence. Next is the queue, and it gets a condition ("starts when SSO ships"). Later is a list of ideas you are still learning about. Most product teams are better served by this format, with a dated release plan underneath for the work that is close to shipping. The template above does both.

The not-doing list

The section most roadmap templates leave out is the one that saves the most meetings. Every roadmap is a set of trade-offs, and when the trade-offs are invisible, everyone whose request is missing assumes it was forgotten.

Write each declined request with who asked, why not now, and what would change the decision. "Custom report builder: two customers, four months of work, serves none of our goals, revisit if it blocks an enterprise deal" is a complete answer. It turns a recurring argument into a condition someone can check.

Keeping the roadmap current

A roadmap goes stale the week after it is presented. Three habits keep it alive:

One owner. One person updates it. Others propose changes to that person.
A change log. Every move gets a dated line: what moved, from where, why, and who decided. This is the part people read most once the roadmap is a few months old, and it is the part no slide keeps.
A fixed review. Monthly is enough for most teams. Put it on the calendar, and at each review ask whether each Now item still serves its goal.

Roadmap, release plan or project plan

A roadmap sets priorities across many pieces of work. A release plan schedules one shipment. A project plan breaks a single initiative into tasks and dates. When an initiative in Now needs requirements, write a PRD. When the team plans its next two weeks, the sprint planning template pulls from the top of Now. And if your goals come from company OKRs, link the roadmap to the OKR template so each initiative traces back to a key result.

Common mistakes

Feature lists without goals. If an item cannot name the goal it serves, it is a request, not a plan.
Dates on everything. Items past Now with dates become broken promises.
No owner per item. "Engineering" is not an owner.
Silent changes. An item that moves without a log entry teaches readers the roadmap is fiction.
One roadmap for every audience. Customers, executives and engineers need different levels of detail. Keep one source and derive the views.

Customization tips

Write outcomes, not features
"Guided setup" is a feature. "Agencies send their first invoice in one session instead of three" is an outcome you can check. When an initiative is written as an outcome, people can argue about whether it is the right one, which is the point of a roadmap.
Drop the dates for anything past Now
Dates on Next and Later items become commitments in readers' heads, even with a disclaimer. Use a condition instead ("starts when SSO ships") and give a date only when the work is staffed and in progress.
Say how confident you are
A one-word confidence (high, medium, low) on each Now item, with the reason when it is not high, saves the conversation where someone discovers in week ten that the date was always a guess.
Make one version per audience from one source
Keep a single internal roadmap with owners, risks and the full change log. Derive the customer version from it by removing owners, dates and internal risks, as the public roadmap example does. Two roadmaps maintained separately drift apart within a month.
Add kill criteria when the roadmap is a bet
For a startup or a new product line, the most useful line on the page is what would make you stop. Write it before the results come in, while it is still easy to be honest.
Turn the release plan into a checklist
When a release gets close, turn milestones and go/no-go criteria into checkboxes with owners and dates. The roadmap stays strategic; the release section becomes the working document for the last three weeks.

In the app

How to do this in Scribelet

Open Desk Settings, then Templates, tap Add Template, paste the roadmap template and set the category to Planning. Keep {{date}} in the title so the updated date fills in each time you start a new version.
Give each initiative its own note and link it from the roadmap with [[SAML single sign-on]]. The initiative's backlinks panel then lists every meeting, PRD and customer call that mentioned it, which is the evidence you need when someone asks why it is in Now.
Write release milestones as - [ ] Code freeze (@Kofi) @due(2026-11-24). They appear in the Tasks view and on your daily note until ticked, and @remind(2026-11-30 09:00) sends a push reminder before the go/no-go check.
Ask the AI chat "why did SSO move to Now?" It answers from your roadmap change log and meeting notes with citations to the notes it used.
On Pro, the stale checker flags notes that need review, so a roadmap nobody has touched in two months gets noticed before the next exec meeting rather than during it.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

How do you create a roadmap?

Start with two or three goals that have a number in them. List the initiatives that serve each goal, sort them into Now, Next and Later, and put an owner and a confidence level on everything in Now. Then write what you are not doing and why. The not-doing list is what makes the roadmap credible to the people whose requests are on it.

What is the difference between a product roadmap and a release plan?

A product roadmap says which problems you will work on and in what order, usually over a quarter or more. A release plan covers one shipment: exact scope, milestone dates, go/no-go criteria and rollback. The template above keeps a release section inside the roadmap so the two stay connected; the release notes template covers what you tell users after it ships.

Does Excel or PowerPoint have a roadmap template?

Both have timeline and Gantt layouts, and most roadmap template galleries are slides or spreadsheets. They are good for presenting. They are weak at holding the reasoning: why an item moved, who decided, what you said no to. Write the roadmap as text first, then build the slide from it when you need one.

What is the best tool to create a roadmap?

For a team of under 20, a shared document you update monthly is usually enough, as long as it has a change log. Dedicated roadmap tools pay off when several product lines share dependencies or when the roadmap has to sync with an issue tracker. The tool matters less than the review habit.

Can ChatGPT create a roadmap?

It can draft the structure and suggest initiatives for a generic product. It cannot know your goals, your capacity, or which customer threatened to churn last week, and those decide the order. Give an AI assistant your own notes and goals and ask it to propose an order with reasons, then edit the reasons you disagree with.

How often should a product roadmap be updated?

Review it monthly and update it whenever something moves, logging the change with a date and a reason. A roadmap that is only updated quarterly is wrong for most of the quarter, and readers learn to stop trusting it.

A roadmap that remembers why it changed

Keep your roadmap in Scribelet, link each initiative to the notes that justify it, and track release milestones as tasks with due dates. When leadership asks why something slipped, ask your notes. Free to start.

Start your roadmap

or get the app

Download on theApp Store

Free plan, no credit card. See pricing

Product

Sprint Planning Template

Sprint planning goes wrong in two places: the team commits to last sprint's velocity with this sprint's people, and unfinished work rolls over without anyone deciding it should. This template does the capacity math in the open, makes a decision on every carried-over item, and ends with a sprint goal someone could check on demo day.

Product

PRD Template (Product Requirements Document)

A PRD (product requirements document) says what problem a release solves, for whom, how you will know it worked, and what it deliberately will not do. This template keeps it short enough to be read, and adds what most PRD templates leave out: a status, a decision log, and open questions with owners and dates.

Work

OKR Examples and Template

An OKR is one qualitative objective and three to five key results with a baseline and a target. Most examples stop at the first day of the quarter. These five go further: weekly check-ins, a personal OKR, and a quarter scored honestly at the end. The template keeps all of it in one note.

Product

Competitor Analysis Template

A competitor analysis is only useful if it changes a decision. This template starts from the question you need answered, compares three or four competitors with a source and date on every claim, and ends with decisions, owners and a review date. Copy it, or start from the example closest to your market.

Engineering

Release Notes Template (and Changelog Template)

Release notes tell users what changed and whether they need to do anything. A changelog records every change, version by version. This template gives you both from the same facts, written once: the changelog as the record, the release note as the version people read.

Projects

Project Plan Template

A project plan says what will be true when the project is done, what is in and out of scope, which milestones get you there by when, who owns each one, and what could go wrong. This template adds the part most plans skip: a dated record of every change.