How to write a product roadmap as a non-technical founder

A product roadmap as a non-technical founder is a one-page document that lists the themes you're betting on this quarter, the next, and later. Not features. Not dates. Themes like "make signup convert at 30%" or "reduce churn to under 4%". You add features underneath each theme only when you start work on them, and you re-rank the whole list every two weeks.

That's the answer. The rest of this post explains why themes beat features, why "no dates" is a hard rule before product-market fit, and how to write the roadmap in roughly one hour using a format engineering teams actually respect.

Why roadmaps fail before PMF

Most founder roadmaps fail the same way. You list 40 features in a Notion page, color-code them red/yellow/green, and assign each one a quarter. Three weeks later customer interviews kill half the features, your contractor ships something that wasn't on the list, and the document rots in a tab nobody opens.

The failure isn't laziness. Pre-PMF startups don't have a roadmap problem; they have a prioritization rhythm problem. A feature list dated by quarter assumes the world holds still long enough for the dates to mean anything. It doesn't.

The roadmap that survives contact with reality is structurally different from the Gantt chart you've seen in PM courses. It's shorter, less specific about what, and more specific about why.

Themes beat features (the "always-bet-on-themes" rule)

Themes are outcomes. Features are guesses about how to hit the outcome. When you write the roadmap at the theme level, you reserve the right to change the feature underneath without rewriting the document.

Compare:

• Feature roadmap entry: "Q3: build referral program with double-sided $10 credit"
• Theme roadmap entry: "Q3: increase paid acquisition efficiency by 30%"

The theme entry survives if the referral program flops and the actual win comes from a Google Ads creative test. The feature entry forces you to either keep building a thing that isn't working or publicly abandon the roadmap.

Basecamp, Linear, and early Figma have been writing theme-level roadmaps for a decade. The pattern got formalized as "always bet on themes" by Marty Cagan's SVPG team. The reason it works for non-technical founders: you don't have to commit to engineering specifics you can't evaluate. You commit to the outcome and let the engineer propose the feature.

This pairs naturally with a short PRD per feature, which is where the implementation detail actually lives.

The "no dates, only quarters" rule

Pre-PMF, the worst thing you can put on a roadmap is a calendar date. "Feature X ships May 14" implies you know how long it takes, which you don't, and that priorities won't change, which they will.

The rule: before PMF, the smallest time unit on your roadmap is a quarter. After PMF, you can tighten to a month. Only after you have a real engineering team with sprint velocity history do you write dates.

When you tell an engineer "this ships May 14," one of two things happens: they sandbag the estimate to protect the date (doubling the real cost), or they hit the date by cutting quality (and you eat the technical debt for six months). Quarters give engineers room to ship the simplest thing that hits the theme.

The Now / Next / Later format (your default)

Now / Next / Later is three columns. Each column holds 2 to 5 themes. That's the whole document.

• Now: what the team is actively working on this two-week cycle. High confidence on what and why.
• Next: themes you intend to start within the next quarter. Medium confidence; the order can shuffle.
• Later: themes worth tracking but not committed to. Low confidence; you reserve the right to delete any of them.

The discipline comes from the rules around the columns:

1. The Now column has a fixed slot count (usually 2 or 3). Nothing enters Now until something leaves.
2. Items move from Later to Next to Now in one direction. They can fall back, but they can't skip.
3. You re-rank Next and Later every two weeks. You don't touch Now mid-cycle.

That's it. A Now / Next / Later roadmap is the easiest thing to maintain because there's nothing to maintain except the ordering. No Gantt bars to redraw. No dates to slip. No status colors to update.

Comparison: Now / Next / Later vs Gantt vs OKR-aligned

The three formats founders typically pick between:

Format	What it is	Best for	Worst for	Founder time per week
Now / Next / Later	3 columns of themes, no dates	Pre-PMF, weekly iteration, small teams	Coordinating with a big sales team that needs delivery dates	15-30 min
Gantt / timeline	Feature bars stacked against calendar weeks	Post-PMF teams with stable velocity, hardware launches, regulated industries	Anything where priorities shift monthly	2-4 hours
OKR-aligned	Objectives + key results, with feature lists below each KR	Series A and later, multiple squads needing alignment	Solo founders or 1-3 person teams (too much overhead)	1-2 hours

For non-technical founders pre-PMF, Now / Next / Later wins on almost every axis. Gantt charts look impressive in pitch decks and lie in execution. OKRs are great when you have three engineering pods to align. With one or two engineers, the overhead exceeds the benefit by 5x.

The one exception: you're shipping a hardware product, working with a regulator, or supporting enterprise sales where deals depend on contract delivery dates. If that's you, this post is the wrong post.

What goes on the roadmap (and what doesn't)

The single most common founder mistake is dumping the entire backlog onto the roadmap. The roadmap and the backlog are different artifacts.

On the roadmap: themes you'd be willing to defend to an investor as the most important thing you're working on this quarter. Maximum 10 items across all three columns.

In the backlog: every feature request, bug, customer ask, half-formed idea, and "we should probably do this someday." Hundreds of items. Lives in Linear, Notion, or a spreadsheet. Almost no one looks at it on a normal week.

Items graduate from the backlog into the roadmap when you decide a cluster of them serves a theme worth prioritizing. They don't appear on the roadmap because someone asked.

Specifically, do NOT put these on a roadmap:

• Bugs (those go in the backlog or directly into the current sprint)
• Customer-specific requests (those go to a CSM, not the roadmap)
• Infrastructure work that doesn't tie to a customer outcome (engineers handle that as part of normal hygiene)
• "Refactor X" tickets (same as above)

If your roadmap has more than 10 items, it's not a roadmap. It's a wish list, and engineers will treat it accordingly.

When (and how) to share your roadmap with customers

There's a real tension here. Sharing a roadmap helps customers feel heard and reduces churn. Sharing the wrong version of a roadmap creates commitments you can't keep and burns trust when dates slip.

The rule we use: share themes, never dates, never the full Now/Next/Later board.

A safe customer-facing roadmap looks like this:

"Over the next quarter, we're focused on three things: faster onboarding, better mobile experience, and richer reporting. We'll share specifics as we lock the work."

That's it. Three themes, no dates, no feature names. Customers get the strategic direction. You retain the right to change the specifics.

Linear, Cron, and early Notion published a public Now/Next/Later board with theme-level entries and explicit "no dates" framing. This works if you're disciplined; it fails if you list features instead of themes, because customers hold you to every feature you name.

If a customer pushes for a date, the honest answer is: "We don't commit to dates because we re-prioritize every two weeks based on what we learn from users like you. The trade-off is we ship the right thing instead of the thing we promised six months ago." The customers who can't accept that aren't your design partners yet.

How to write your roadmap in one hour

You can build a workable Now / Next / Later roadmap in about an hour. The steps:

1. List every theme you've considered in the last 90 days. Dump 15-25 themes into a doc. Don't filter. Examples: "improve signup conversion", "reduce time-to-first-value", "add team accounts", "fix the mobile flow", "ship a referral loop".
2. Cluster duplicates. Most lists collapse to 8-12 distinct themes once you merge similar ones.
3. Pick 2-3 themes for Now. These should be the themes most directly tied to your next funding milestone or PMF signal. If you're hunting PMF, pick themes that test retention or conversion. If you're scaling, pick themes that grow the funnel.
4. Pick 3-5 themes for Next. These are the themes you'd start within 90 days if Now ships cleanly.
5. Dump everything else into Later. Don't delete; just deprioritize.
6. Write one sentence per theme explaining the outcome you're betting on, not the feature you'd build. "Lift trial-to-paid conversion from 12% to 20%" beats "build a better onboarding email sequence."
7. Set a recurring 30-minute meeting every two weeks to re-rank Next and Later. This is the only ceremony the roadmap needs.

If you're booking an engineer on Cadence for the first build, this one-page roadmap is what you hand them along with the booking spec. It tells them the direction without micromanaging the implementation. Cadence's median time-to-first-commit is 27 hours after booking, but only when the founder has a clear theme; without one, even an AI-native engineer (and every Cadence engineer is AI-native by default, vetted on Cursor / Claude / Copilot fluency before they unlock bookings) spends the first day asking clarifying questions.

Before you book the engineer, write the one-page roadmap and one short PRD for the Now theme. If you want help structuring the spec, the PRD-for-non-technical-founders guide covers the format that pairs naturally with this roadmap. Then book a mid or senior engineer for a week on the trial to ship the first slice.

Common founder mistakes when writing a roadmap

The five mistakes that come up over and over when founders show us roadmaps:

• Listing 30+ features instead of 5-10 themes. A 30-item list is a backlog, not a roadmap. Engineers ignore it because they can't tell what matters.
• Putting dates in the Now column. Now means "the team is working on this." It doesn't mean "this ships on the 14th." Even a 2-week sprint date creates fake urgency.
• Mixing themes and bug fixes. "Improve activation rate" and "fix the Stripe webhook timeout" are not the same kind of work. The bug goes to the sprint. The theme goes to the roadmap.
• Sharing the internal roadmap with customers verbatim. Customers see "Feature X in Next" and assume it's coming in 6 weeks. When it slips, they churn citing trust.
• Never re-prioritizing. A roadmap that hasn't changed in 8 weeks is a roadmap nobody is using. Either the world hasn't changed (unlikely for a pre-PMF startup) or you've stopped looking.

Tied to the last one: if you're spending more than 30 minutes per two-week cycle maintaining the roadmap, the format is wrong. Strip back to fewer themes. The roadmap should be cheap to maintain or you won't.

What to do this week

If you don't have a roadmap, write one tonight using the one-hour process above. Three columns, themes only, no dates.

If you have a roadmap that's a feature list with quarters, convert it. Group your features into themes. Move themes (not features) into Now / Next / Later. Throw the spreadsheet away.

If you have a roadmap and an engineer but you're not shipping fast enough, the bottleneck is usually one of three things: the theme is too vague (rewrite as an outcome), the engineer's tier doesn't match the scope (a $500/week junior can't own a brand-new system; a $2,000/week lead is overkill for a CSS pass), or the founder isn't reviewing demos weekly. Managing a remote developer when you can't code covers the demo cadence in detail.

If you're still pre-engineer and don't know which tier you need for the Now theme, the rough heuristic: cleanup and integrations are junior work, end-to-end features are mid, anything touching architecture is senior, and "you're hiring a fractional CTO" is lead. The full breakdown is on the hiring-vs-contract decision page.

For founders who want to skip the recruiting loop entirely, Cadence shortlists 4 vetted engineers in 2 minutes against your one-page roadmap, and the 48-hour free trial lets you confirm the engineer can actually ship the Now theme before you pay anything.

FAQ

How is a product roadmap different from a PRD?

A roadmap lists the themes you're betting on this quarter and beyond. A PRD describes one specific feature in enough detail that an engineer can build it. The roadmap lives at the strategy level (5-10 items, themes only). The PRD lives at the implementation level (one per feature, written when work starts). You hand both to your engineer: the roadmap so they understand the direction, the PRD so they know what to ship this week.

Should I show my roadmap to customers?

Share themes, never dates, never the full internal board. A safe customer-facing roadmap names 3 themes for the quarter ("faster onboarding", "better mobile", "richer reporting") without listing the specific features or timelines. This gives customers strategic direction without locking you into commitments you'll change.

How often should I update my roadmap?

Re-rank Next and Later every two weeks in a 30-minute session. Don't touch Now mid-cycle (the team needs stable priorities to ship). Promote items from Later to Next as you learn from customers. If you find yourself updating Now mid-cycle more than once a quarter, your themes are too broad or your sprint length is too long.

What tool should I use for the roadmap?

For a pre-PMF startup, a single Notion page with three columns is enough. Linear and Height have built-in roadmap views that work well once you have 2+ engineers. Avoid full PM tools like Productboard or Aha until you have a product manager; the setup cost exceeds the benefit. The format matters more than the tool.

Do I need a technical co-founder to write the roadmap?

No. Themes are outcomes ("lift conversion to 20%"), not technical specs. A non-technical founder is actually better positioned to write a theme-level roadmap because you naturally think in customer outcomes rather than implementation details. The technical work happens in the PRD and in the engineer's hands. If you find yourself trying to specify the how on the roadmap, you're writing features instead of themes; stop and rewrite.