A product roadmap often looks like this: customer requests escalated by sales, bugs prioritised by engineering, a few strategic initiatives carried by the CEO, and a "to qualify" column that grows every week without anyone really touching it.
The Head of Product arbitrates, prioritises, ships. At launch, adoption does not follow.
This is not an execution problem. The feature was delivered on time, within spec, with the planned resources. The problem was upstream, in the question nobody asked before starting to build.
What the product roadmap does not see
A roadmap captures requests. It does not capture problems. These are not the same thing.
When a customer asks for a feature, they are describing a solution they imagine to a problem they feel. But the felt problem is not always the real problem. And the imagined solution is almost never the best answer to the real problem. Yasmeen Turayhi, in her analysis of product prioritisation mistakes, puts it plainly: the problem is almost never execution, it is the hypothesis.
Why are the majority of features launched by startups rarely or never used after launch? Because the hypothesis about the problem was never challenged before development started. The customer request was taken at face value, put into specs, and shipped. The underlying problem was never examined.
A Pendo study on SaaS feature usage in Europe shows that 80% of features developed are rarely or never used after launch. This number does not say that product teams execute poorly. It says they often build the wrong things, for apparently good reasons.
Qualify before you build
Qualifying a request is not a bureaucratic process. It is a twenty-minute conversation that prevents three months of unnecessary development.
How do you qualify a customer request before putting it on the roadmap? Two criteria are more useful than all the others: urgency and frequency. An urgent but rare problem does not justify a major product investment, it justifies a workaround. A frequent but moderate problem can justify a structural feature, because it is part of the user's daily routine and a solid solution durably changes their behaviour.
The question Turayhi considers the most important of all is this: if you solved this problem perfectly, what value does it create for the user? A user who answers "convenient" behaves very differently from a user who answers "indispensable." The difference between the two is not in the feature design. It was already in the problem, before you started.
The product teams with the best post-launch adoption rates do not build faster. They spend more time qualifying before they start, and less time fixing after they ship.
The brief before the spec
This is where the product roadmap meets the way of working. A spec describes what you are going to build. A brief describes why it is worth building, for whom, and how you will know if it worked. The two documents are not interchangeable, and one does not replace the other.
At Nightborn, the first conversation with a client is not about the feature. It is about the outcome: what needs to change in your users' behaviour if this project succeeds? That question forces a clarity that the spec alone never produces. It aligns product, engineering and business on the same definition of success before a single line of code is written.
This is the rigour upstream that separates a build that changes something from a build that ends up in the backlog six months after launch. Not because the execution was better, but because the problem was understood before it was solved.
A well-filled product roadmap is not a guarantee that you are building the right things. It is a guarantee that you have captured a lot of requests. The difference between the two plays out before development starts, in the questions you ask or do not ask.
If you want to bring this qualification rigour into your next project from the start, that is where every Nightborn brief begins.
.webp)