What is a product roadmap and how detailed should it be?

What it's for

Not scheduling. A roadmap exists so that people outside the team — sales, support, leadership, sometimes customers — can make their own decisions with an accurate picture of yours. That framing settles most format arguments: include what those people need to act on, exclude what they don't.

Detail should decay with distance

The current quarter can be specific because you've done the discovery. Two quarters out you know the problem but not the solution. Four quarters out you have a theme and a hypothesis.

A roadmap that shows the same fidelity across all four is lying about at least three of them. Now/Next/Later formalises this, which is most of why it spread — it makes uncertainty visible rather than papering over it with equally-sized boxes.

Outcomes over features

"Reduce time-to-first-invoice from 3 days to 1 hour" survives being wrong about the solution. "Ship invoice wizard v2" does not. When discovery reveals the wizard was the wrong answer, the outcome roadmap absorbs it and the feature roadmap turns into a credibility problem.

This matters even more when a competitor moves. A roadmap built on outcomes can respond to a rival shipping your Q3 plan on a Tuesday by rerouting to the same outcome. A roadmap built on features has to either abandon a public commitment or ship something that no longer differentiates.

The uncomfortable part

Someone will always ask for dates, and often for legitimate reasons — a contract, a conference, a hiring plan. Give dates where you have real confidence, refuse them where you don't, and be explicit about which is which. The team that dates everything and misses half is trusted less than the team that dates three things and hits them.