Product discovery and roadmapping

What this actually solves

There are four developers, and there is no shortage of work for them. Sales keeps bringing new feature requests, because every prospect asked for something. The chief executive has a list. Support says the real problem is neither of those and has said so for months. Priorities change every week, and at the end of the quarter several things are half-built and nothing is finished. Nobody in the company is behaving unreasonably — each of them is right about their own evidence, and there is no shared way to weigh one against another.

Which is why the thing being bought here is not clarity. It is the end of an argument. A company reaching for outside help on prioritisation usually already contains someone who knows the answer and cannot say it, because saying it means telling a colleague their quarter of work is not going to happen. An outsider can hold that conversation in the open, score it against criteria everyone agreed to in advance, and leave behind a document that carries the decision after they have gone.

What we do, and in what order

1. Kickoff and stakeholder map. One hour on the goal, who we need and when, and the access list — analytics, support inbox, the last six months of usage or sales data. Access always takes a few days and that wait is planned for rather than discovered. One day, plus two to three days of waiting.
2. Eight to twelve user interviews. Your users, individually, thirty to forty-five minutes each. Every question is about what actually happened last week, not about what people would like — walk me through the last time you did this beats what would you want. Recorded and transcribed. One to two weeks.
3. The evidence that already exists. Analytics, support tickets grouped by type, the complaint emails nobody has read as a set, and us using the product as a customer - signing up, buying, trying to undo something, emailing support. That last day usually produces the most uncomfortable page in the report. Three to five days.
4. Synthesis. Every struggle written on its own line, clustered by underlying cause rather than by the feature that would fix it, and each cause given a cost in money, time or lost customers. A cause that cannot be priced does not go first on the list. This is two days of sitting alone, and it is where the work is either done or not. Two to three days.
5. Prioritisation workshop. Your whole team in one room, scoring against RICE or MoSCoW with the weights agreed before anything is scored, and the disagreement facilitated rather than avoided. One day.
6. Roadmap, draft round, readout. Three to five themes across two quarters. Each theme gets a problem statement, who it is for, the measurable outcome that would prove it worked, what is explicitly not included, and the biggest assumption that would sink it. The draft goes to you for objections first, then a forty-five minute walkthrough. One week.

Tools — Miro or FigJam for the workshop, a Google Sheets scoring model that is deliberately plain because your team has to keep using it after we leave, Notion or Linear for the roadmap itself, and a recording plus transcript of every interview. Dovetail is worth it once research volume justifies it; for a first round a spreadsheet genuinely does.

What moves the price

The range is $2,000–$20,000 over 3–8 weeks, and three things decide where an engagement sits in it.

The number of stakeholders. It is written into the contract for a reason. Each additional stakeholder is another interview, another set of priorities to reconcile, and another person whose objection has to be answered before the roadmap can hold.

Whether we facilitate or only report. Delivering findings is one price. Standing in a room and running the argument to a conclusion your team signs off on is another, and it is usually the half that gets the work commissioned.

Whether your users are reachable. A consumer product with an engaged base is straightforward. Enterprise software where every conversation needs an account manager's permission and three weeks of scheduling adds real time before any research starts.

What usually goes wrong

The roadmap is a list of features and dates. March, reports. April, mobile app. The first date slips — it is a guess about work nobody has started — and after that nobody trusts any line on the page, including the ones that were right. Written as an outcome it survives, and the shape is this: by the end of Q2 a new customer sends their first invoice on the day they sign up, rather than days later. That sentence stays true while the plan underneath it changes, and it settles arguments without anyone having to reopen the document.

Only your own team gets interviewed. It is faster, cheaper and everyone is available, and it produces a beautifully evidenced summary of what you already believed. Internal staff describe the users they remember and the complaints that reached them. The gap between that and what eight real users say is usually the entire value of the engagement.

The notes get tidied up and handed back. Fifteen findings arranged into neat categories is not synthesis — it is your own words read back to you at cost. Synthesis means naming the three underlying causes and putting a number against each. Orders go out wrong is a symptom. The person taking the order has no way to see current stock is a cause, and only one of those two can be prioritised against anything.