Product roadmap: Now, Next, Later, and no dates you can't keep

What a product team is building now, next and later, by theme, for customers and colleagues.

Live example

The example: Liftbay's roadmap for independent auto repair shops

Four themes, three columns, a list of noes

Liftbay's roadmap for independent auto repair shops

Open the exampleThe names and numbers are made up.

What to notice

  • Every item's second line is a problem in a shop owner's words, such as "Replies to your reminders land on a number nobody watches."
  • None of the eleven items in Now, Next and Later has a date. The two features that do, under "Shipped since October", are already in customers' hands.
  • "What moved, and why" admits that online booking went from Next to Later, and gives the reason: two-way texting has to ship first.

The prompt that starts one like it

Make a product roadmap for [product] as a single HTML page that reads well on a phone, for customers and colleagues. Here's the work: [paste items, each with its theme and progress]. Sort it into Now, Next and Later, grouped by theme. Give each item a name, one line on the customer problem it solves, and a status. No dates on anything unshipped. Add what shipped recently, what moved since last time and why, what we won't build, and buttons to filter by theme. Then publish it on sharable.link.

Customers read a roadmap with dates as a list of promises. Here is another way to lay one out: sorted into Now, Next and Later, grouped by theme, with a status on every item and no date on anything unshipped. The product is made up. Take the structure and bring your own plans.

Who it's for

Product managers and founders who get asked "when is that coming?" by customers, sales and support, and want to answer once. Customers read it to decide whether to wait for a feature. Sales reads it and stops promising quarters.

This is the version for people outside the team. Sprints, estimates and owners stay in whatever tool your engineers use. A page can't take votes or comments, so tell readers how to send requests. The example says to reply to the email the link came in.

What a good one contains

  • Three horizons, defined. Now is being built or tested today. Next is scoped or designed, and starts when a Now item ships. Later is a problem you mean to solve. The example prints them above the columns.
  • Themes named for what the customer gets. "Talking to customers" and "Knowing your numbers" are two of the four. Buttons filter the page to one of them.
  • A problem under every name. "Core charges go unclaimed when nobody remembers which box went back" tells an owner whether the item is for them. A feature name alone doesn't.
  • A status in plain words. In testing with 12 shops, Building, Designed, Scoping, Exploring. One item says "Waiting on two-way texting", which explains its place better than a quarter would.
  • An empty cell left empty. Nothing is in build under "Knowing your numbers", and the cell says so.
  • What shipped, with its date. Past releases can carry dates safely, and two recent ones prove the Now column does empty.
  • What moved, and what you won't build. Built-in bookkeeping sits under "Not planned", with its reason. Written down once, a no stops being asked every month.

Why not a calendar

Inside a team, a date is an estimate and everyone knows it. Outside, it becomes a commitment: a customer plans a hire around it, and a salesperson writes it into a deal. When it slips, you lose the trust you earned by sharing the roadmap. Order is something you can stand behind: you do know what you're building today and what comes next.

Put the dates on the page itself. The example says when it was last updated and that it's revised every two months. Keep to that, replace the page under the same link, and say what moved each time.

How to send it

As an open link. Customers forward it to the colleague who asked for a feature, and sales sends it to prospects. Write it knowing a competitor will read it too.

Every page you publish gets one link that opens in any browser. You choose who can open it: anyone with the link, anyone with the password, or only the people and company domains you name, who sign in with Google or Microsoft. Change the page later and the link stays the same.

Make yours in Claude

Add the connector once, then publish from any Claude conversation and get a link to send.

Add Claude Connector

Already have the file? Upload it here.

More in product and engineering

  • KPI dashboard: A few numbers with their changes and the reasons behind them, sent to the same readers on a schedule.
  • Data visualization: One dataset drawn as a few interactive charts, each with a sentence that says what to see.
  • Flowchart: A process or user flow drawn as steps, questions and outcomes, for the people who have to follow it.
  • Product requirements document: The problem, the requirements and what's left out for one feature, for the people who will build it.
  • App prototype: A clickable phone app in one page, sent to a few people to try before anyone writes real code.
  • Release notes: What's new, better and fixed in this version of your product, written for the people who use it.
  • All use cases