How to run continuous product discovery and keep a roadmap that helps.

Validation does not stop when the build starts. Product discovery is the ongoing habit of learning what users need, testing ideas cheaply and deciding what to build next. The roadmap is where those decisions are made visible.

Why it matters

Without discovery, the roadmap fills with the loudest customer’s requests, investor suggestions and the team’s favourite ideas. With it, you spend scarce development time on the changes most likely to improve activation, retention and revenue.

Step by step: discovery

1. Talk to users every week. As a rule of thumb, aim for at least two or three short user conversations a week once you have users. Rotate who joins so designers and developers hear users directly.
2. Start from opportunities, not features. Capture each insight as a problem or need (“practice managers cannot tell which reminders were opened”), not as a solution.
3. Generate more than one solution. For each important opportunity, sketch two or three ways to address it before picking one.
4. Test before building. Use clickable prototypes, a manual version or a small feature behind a switch with a few users. Ask them to complete a task, not to give an opinion.
5. Decide with evidence. Move an idea into the build only when you have seen users struggle without it or succeed with the prototype.

Step by step: the roadmap

1. Use three horizons. Now (this month, committed), next (the following one to three months, likely) and later (ideas, not promised). Only “now” has detail.
2. Frame items as outcomes. “Increase first-week completion from 40 to 60 per cent” rather than “build onboarding checklist”. The team can then choose the best way to hit the outcome.
3. Prioritise simply. For each item, estimate impact on your key measure, confidence in that estimate and effort. Favour high impact, high confidence and low effort. Keep the scoring rough; the conversation matters more than the number.
4. Review monthly. Update the roadmap based on what you shipped, what you learned and what changed in the business.
5. Share it carefully. Customers and investors can see the outcomes you are pursuing, but avoid promising dates for “next” and “later” items.

Worked example

SiteSafe’s backlog had 60 feature requests after three months. Discovery calls with eight site managers showed that most requests traced back to two needs: completing inspections with no signal on site, and showing clients proof of inspections. The roadmap became: now, offline inspections (outcome: inspections completed on site rise from 70 to 95 per cent); next, a client-facing inspection report; later, everything else. A paper prototype of the client report, tested with four clients, cut its planned scope by half before any code was written.

Common mistakes

• Roadmaps as delivery promises, with dates for features you have not tested.
• Building whatever the biggest customer asks for, turning the product into custom software for one client.
• Discovery done only by the founder, so the team builds without context.
• Opinion-based testing, asking “do you like this?” instead of watching people use it.
• Never removing anything from the backlog.

A simple discovery note

For each opportunity worth pursuing, keep a short note: the need in the user’s words, how many users and which segments raised it, the evidence (quotes, usage data, support requests), the solution options considered, what was tested and the result, and the decision. Linking each roadmap item to a note like this makes priorities easy to explain to the team, and easy to revisit when circumstances change.

What to measure

• User conversations per week.
• Share of roadmap items framed as outcomes.
• Ideas tested with prototypes before being built.
• Outcomes achieved per quarter against those planned.
• Age and size of the backlog.