Five errors that turn discovery into a report dressed as research
Published on
Five reasoning errors that turn discovery into a report dressed as research: bias, skipped validation, dirty data, no prioritization and an abandoned PRD.
In my book about user research in product design I named five reasoning errors that turn discovery into a report dressed up as research. I committed almost all of them before I could name them.
The scene is always similar: there are interviews done, transcripts organized, insights on paper. And then nothing happens.
Reasoning errors, not execution errors
Technical execution mistakes are the easiest to fix. I am talking about the others: the ones that settle in silence and produce results that look valid until reality disproves them.
The difference between a successful discovery and a failed one is not the absence of errors, but the speed at which they are identified and corrected. I wrote about this in the closing section of the book, and each of the five errors came from a real project, not from a manual.
Anyone who works with product knows the pattern: the research exists, it is well documented, it becomes a polished PDF that gets shared. And it dies right there. The report dressed as research has every external mark of serious work and no effect on the decisions that came after. The problem is almost never the team's intention: it is one of these five reasoning habits installed right at the start of the process.
1. Researching with bias
The first error, and the most frequent. The team enters the field with a predefined hypothesis, a solution already on the roadmap. The questions carry the direction of the hypothesis, and the researcher hears confirmations more than refutations.
The symptom is the appearance of legitimacy: there are interviews, transcripts, insights. But what comes back is not a discovery, it is confirmation in disguise.
The correction takes discipline: use genuinely open questions, include in the analysis the data that contradicts the hypothesis and, when possible, have a colleague review the insights with fresh eyes.
In practice the test is quick: reread the interview guide and ask whether someone who disagrees with your solution would also feel invited to answer those questions. If the script only fits your hypothesis, the bias is already set up before the first interview.
2. Not validating with stakeholders before writing the PRD
The team produces a solutions document without involving whoever decides. The result is a technically flawless PRD that never gets prioritized, because it ignored a budget constraint or a political interest.
The fix is simple to state and hard to skip: validate the menu of solutions with the stakeholders before moving into specification. Documenting well does not replace the people who need to say yes.
The error carries a hidden cost: when the flawless PRD dies in a drawer, the team concludes that research is useless. It was not the research that failed. It was the validation moment that never happened.
3. Skipping data cleaning
Analysis done directly on raw transcripts produces misguided conclusions, built on loose quotes out of context. The insight is born from noise and survives by inertia.
Cleaning is not a luxury, it is a prerequisite. It is the stage that guarantees the analysis rests on clean data, traceable back to its source. Without it, everything else is a castle on sand.
The isolated quote is the classic symptom. One strong sentence, said in passing, becomes the headline of a slide and steers the whole roadmap. Cleaning means returning each phrase to the context that produced it before deciding what it means.
4. Not prioritizing
When everything looks important, nothing is. Discovery generates more opportunities than any team can execute, and a report that treats every pain as equivalent decides nothing.
The fix is to apply the Pareto principle: 20% of the pains cause 80% of the problems. Finding that 20% takes judgment, not just analysis. Prioritizing is choosing what not to do, and documenting why the rest stayed out.
A report that does not prioritize pushes the decision onto whoever receives the document, usually without the context the research produced. That is how discovery becomes an archive: complete, organized and without consequence.
5. Not iterating
The PRD is born and abandoned, with no validation cycle. A closed document is an invitation to obsolescence.
Living document or obsolescence, there is no middle ground. The fix is to treat it as a baseline: a consolidation of decisions at a point in time, which evolves with new evidence instead of dying at the first meeting that contradicts it.
Every development round reveals something the research did not foresee: an edge case, a technical dependency, a real usage behavior. If the document absorbs none of that, it ages faster than the product it was supposed to guide.
What separates knowledge from reports
Acknowledging that the research was biased or that the data was dirty is admitting the work has to be redone. Uncomfortable, costly, slow. But that willingness to redo is exactly what separates those who produce knowledge from those who produce reports.
Taken together, the five errors form a pattern: each one cuts the link between what the research found and what the product decided. The interview happens, the data is collected, the document is written. What is missing is the circuit closing: validate, clean, prioritize, iterate. A report is what is left when the circuit stays open.
The whole method is in the book
Each of these errors has its symptom, its remedy and its documented case in Discovery em Product Design, ISBN 978-65-02-29969-2. The book compiles a method built project by project, error by error, refinement by refinement: from preparing the kickoff to delivering a requirements document, through interviews, contextual observation, data cleaning and artifact extraction.
Discovery is not a phase that ends in a report. It is the discipline of staying connected to what reality answers.