Who you think will pay is the loudest; who actually pays has the hardest deadline.
Research Before Building: Stress-Testing Inherited Assumptions
Why arriving at a problem statement independently is verification, not redundancy, and where inherited assumptions quietly hide.
A research document lands in the shared folder. It has a problem statement and three user archetypes. It is well-written, the framing is credible, everyone has read it. And within a day, a team is about to spend a week building against it without ever checking whether the archetypes are right or the problem statement can survive contact with independent data.
That is the failure I have watched repeat the most. Not bad research. Unexamined research. A document circulates, earns a few comments, and accumulates gravity simply by existing. The framing was never challenged. The archetypes were never stress-tested. The research was inherited, not earned, and inherited research becomes the foundation for a product nobody has actually validated.
Inherited Versus Earned
The distinction sounds academic until you watch the cost. Inherited research is something you accepted because it was already written down and looked reasonable. Earned research is something you arrived at yourself, where any agreement with the original framing actually means something.
On Day 1 of a six-day build, I had exactly this kind of document: a problem statement and three archetypes called Climber, Specialist, and Scanner. The decision I made was to set it aside and rebuild the analysis from scratch.
Not to disprove it. The document was not wrong. The real tradeoff was between speed and confidence. I could refine the existing document and move to solution space fast, or I could arrive at the problem statement independently so that any agreement would be grounded rather than assumed. I chose confidence. If the independent research landed on the same problem statement, that convergence would mean something. If it diverged, the team needed to know before Day 2, not after Day 6. Convergence is what turns a framing into evidence, the same reason an A/B test settles an argument that opinion never could.
Arriving at the problem statement independently is not redundancy. It is verification. The two paths agreeing is the evidence; one path alone is just an opinion that got written down first.
Where the Assumptions Hide
The rebuild did land on the same problem statement, which strengthened confidence in it. But it also surfaced gaps the original had missed, and the gaps are where this gets useful for your own work.
The original document had three archetypes, organized by career level. Mapper was early career, Climber mid-level, Scanner senior. The model was a ladder. That framing was wrong, and the error was invisible until the analysis was rebuilt. Archetypes are goal crossed with urgency, not career level. A senior leader who is interviewing behaves like someone on a four-week deadline, not like a senior leader. A new product manager chasing a promotion behaves like someone on a twelve-month track. Career level sets a default. The actual situation determines behavior. Reading a user through situation rather than label is the same discipline behind the frames every PM uses to see a product clearly.
The design implication is concrete: you cannot assign an archetype from a job title or a profile. You have to ask. An entire category of product decisions changes once you stop treating the org chart as the segmentation.
This is the general lesson. When a research document trims a user population down to three personas, it is making a claim about who the product is not for. That claim is usually a side effect of stopping research early, not a deliberate choice. So whenever you see three or fewer archetypes in an inherited document, the question to ask is not what survived. It is what got cut. The cut is where the assumptions hide, and naming what you deliberately eliminate is exactly how the Double Diamond works as an elimination tool.
The Assumption Almost Always Wrong on First Pass
There is one inherited assumption that deserves its own scrutiny every time: who pays.
My initial belief was that the Climber, the mid-level person chasing promotion, would anchor the paid tier. Promotion anxiety is real, the twelve-month window creates sustained urgency, and it is a large, well-defined market. That belief was reasonable. It was also probably wrong.
The research pushed back. Interview preparation is a proven paid category with demonstrated willingness to pay, shorter decision cycles, and clear success criteria. The person preparing for an interview has a deadline. The person chasing a promotion has a goal. Deadlines convert better than goals. So the paid tier got anchored on the person with the shortest time horizon and the highest stakes. Not because the others do not matter, but because building for the tightest deadline produces a product that serves everyone else too.
The pattern underneath: who you think will pay is usually the person who talks loudest about the problem. Who actually pays is usually the person with the hardest deadline. The discipline that surfaces this is a small change in the question. Do not ask who has the problem. Ask who has the problem and a deadline, and what they have already paid to try to solve it. The buying behavior was always there in the market. The inherited framing just pointed at the wrong person.
Why Parallel Threads Beat a Single Pass
The rebuild was not one research thread. It ran several independent lines at once: how people actually consume content, how quickly knowledge degrades after reading, what the established paid categories already are. Running them in parallel mattered, because the convergences emerged on their own rather than being argued into place.
One example: the data on knowledge degradation lined up with the data on consumption habits. People read a great deal and retain almost none of it, not from laziness but because the format offers no sequencing, no spacing, no retrieval. The problem was structural, not motivational. That convergence would never have appeared by accepting the original framing and going straight to building. The original document described the problem correctly but never explained why it persisted. Independent threads gave the why, and the why is what a product gets built on.
The cost of skipping all this is not visible on Day 1. It is visible in week two of building, when the thing you shipped is precisely engineered against a problem framing nobody ever pressure-tested. The document felt like a head start. It was a commitment you made before you had checked what you were committing to.
Related Articles
A well-written research doc hands you three user archetypes and a problem statement on Day 1. Do you refine it and move to building, or rebuild the analysis from scratch?
Make the call yourself in Reps before you read what happened next.
Make the call