Product Roadmap
A product roadmap is not a list of nice-to-haves: it is the ordered list of what a startup will build over the next months, and why in that order. Here is how I build a product roadmap for an early-stage startup, what sets it apart from a wishlist, and how prioritization actually works.
Why a roadmap is not a wishlist
A wishlist collects everything that would be nice to have: features a customer asked for, ideas from the founder, things spotted in a competitor's product. A roadmap selects, out of all of that, what to actually build and in what order, with a stated reason for every item. The difference is not the length of the list, it is the criteria used to decide what goes in and what stays out.
Where it comes from: data, not wishes
A solid roadmap starts from real input: user discovery, usage signals, known technical constraints, not just the founder's intuition. It is the same principle behind the product management service I offer: product roadmap, prioritization, user discovery, deciding what ships and what doesn't, with the product in the hands of the people building it, not just the people imagining it.
Prioritization: what goes in and what stays out
Every item on a roadmap should answer a simple question: what happens if we do not build it? If the answer is "nothing measurable", that item can wait. The criteria I use are few and concrete: impact on the question the product still needs to validate, the real cost of implementation, and urgency tied to an external constraint (a deadline, a customer, a round). Everything else is debatable, and should be discussed openly, not decided on a gut feeling.
90 days, not 12 months
In an early-stage startup, a 12-month roadmap is almost always fiction: too many variables shift before month ten arrives. I prefer a 90-day horizon, with clear priorities revisited at every milestone: enough time to build something substantial, short enough to stay true. Beyond 90 days, the roadmap becomes a rough direction, not a commitment.
Who writes it and who decides
The roadmap gets written together, listening to the founder, the team, and signal from users, but someone needs the final call when priorities conflict. In a fractional CTO engagement, that role is often mine for the technical side: not to centralize decisions, but because on a small team someone has to be responsible for saying no.
The most common mistake: the roadmap nobody looks at anymore
A roadmap written once and never updated is worse than not having one: it gives false confidence while the reality of the product moves elsewhere. It needs revisiting at every milestone, not once a year, and it is normal for it to change: a roadmap that never gets updated is probably not being read by anyone anymore.
Frequently asked questions
What is a product roadmap for an early-stage startup?
It is the ordered, reasoned list of what to build over the next months, based on user discovery and real constraints, not a list of desired features without a selection criteria.
What is the difference between a roadmap and a wishlist?
A wishlist collects everything that would be nice to have; a roadmap selects what to actually build and in what order, with a stated reason for every item.
How often should a product roadmap be updated?
At every milestone, typically between 30 and 90 days at the early stage: a roadmap written once and never revisited stops being true fairly quickly.
Who should write the roadmap if the founder is not technical?
It should be written together with whoever leads the technical side, a fractional CTO or a product manager, so priorities also account for real constraints and implementation cost, not just market desire.
Is a 90-day roadmap better than a 12-month one?
At the early stage, yes: 90 days is enough to build something substantial, short enough for priorities to stay true instead of turning into fiction.