Before the PRD: Find Out What People Actually Need

Before writing a product requirements document, it is important to learn how people handle the problem today and what would make that work better. You need something concrete to build from. Interviews and user journeys give you that starting point. That is always where I start before committing to a build.

What should happen before you write a PRD?

It depends on what you already know. If the problem is complex and uncertain, start with interviews and observation. If the problem is established, check the proposed solution against actual work. For a narrow, understood change, existing evidence is usually enough. The aim is to resolve as much uncertainty as possible, before writing the PRD.

Writing a PRD can feel like progress. Features get names. The project starts looking like something you can build. But first, I want to understand why those features belong there.

Take a hypothetical request for an AI proposal writer. The team wants to send proposals sooner. Fair enough. But is writing the slow part? Or does each proposal sit waiting for approval? That changes what we should build.

How do you find the problem behind the feature request?

I start with a recent proposal. Show me the request that came in. What did you need before you could respond? Then I follow it through to the answer the customer received.

The questions can be simple. What did you open? Where did the information come from? Who checked it? What happened while you waited? The detail is in the answers.

With permission, I look at the documents too. A process can sound straightforward until you see the copying between files. If the account and the records differ, I keep that difference in the notes and investigate it.

NN/g distinguishes interviews from usability tests. Interviews collect reported experience; usability tests let you observe someone using a design. An account of what happened deserves checking against behaviour where the decision depends on it.

I also ask what works already. What would they keep? People build workarounds for a reason. Understanding that reason helps us preserve something useful when we change the process.

Who should be in the conversation?

Speak with the people doing the work and those who receive it. A proposal author and an approver can describe different problems in the same process.

Stakeholder interviews add the business constraints. We need to understand who controls the budget and what outcome matters to them. We also need the operating limits, including access to information.

A sponsor may want more proposals. The reviewer may want complete proposals. I keep both views visible. We need to resolve that difference before it turns into competing requirements during development.

Recruit people whose circumstances could change the answer. Include someone handling difficult cases or using an alternative. Convenient access to enthusiastic users can leave important gaps.

The sampling problem deserves its own treatment in Five Users Is Not a Discovery Plan.

How do you turn conversations into a product decision?

Here is how I turn that material into a decision:

1. Write the decision we need to make. Describe the affected person and the result they need.
2. Gather recent examples. Record what people reported separately from what you observed.
3. Compare the accounts. Keep supporting material beside each finding and preserve contradictory cases.
4. Map the current experience. Show their actions and handoffs, including where they wait.
5. Compare plausible changes. Test the assumption most likely to alter the choice before committing to development.

Back to the hypothetical proposal. Suppose the author is waiting for a delivery date. Generating the text faster leaves them waiting. I compare better intake with giving someone responsibility for supplying that date.

That is the next thing to test. We still need to check it with the people handling proposals and the records they use.

What does the evidence say about building the wrong thing?

As of October 2026, CB Insights reports poor product-market fit in 43% of 385 coded startup failures.

These were VC-backed shutdowns with identifiable failure reasons. The analysis is retrospective and reasons overlap. The sample excludes surviving businesses. It cannot tell you the failure probability of your idea.

It also cannot prove interviews would have saved those companies. I use it to ask a more immediate question: how will we check demand before committing to this product?

Write down what would convince you to proceed. Someone liking an idea is encouraging. Someone committing to change how they work gives you different evidence. Keep that distinction clear.

Rob Fitzpatrick's teaching material for The Mom Test explicitly covers biased questions and using commitment to validate early interest. Apply that distinction when deciding what the conversations support.

What belongs in the PRD after discovery?

When I write the PRD, I start with the person and what they need to accomplish. I link the requirement to the evidence. A developer should be able to follow why it exists.

For our example, the outcome might be less time from receiving a complete request to sending an approved proposal. Establish the current performance before setting a target. Keep incomplete requests visible separately.

Then describe the chosen change and its boundaries. State what someone must be able to do and how the team will check it. Record the alternatives we considered and why we set them aside.

The comparison between AI and a better form shows why those alternatives deserve space before development.

If AI is part of the solution, specify which output needs review. Name the person responsible and what happens when information is missing. Give the team representative examples for evaluation.

We can then connect Discovery to Requirements, including the PRD and success metrics. The written scope and fixed price follow that agreed work. Iterative development tests it against the intended outcome.

That sequence is explained in how we work. AI enablement and support follow where they fit the product and its users.

When can development begin?

I am ready to build when we can explain the scope and manage what remains uncertain. I write those open questions down, with a plan for answering them during development.

Research continues as people try the product. Teresa Torres describes discovery around a desired outcome and ongoing customer contact. The initial findings give that work a starting point.

You can compare the ways to work with me once the decision is clear. If you are still choosing the problem, book a call and bring the feature request you are considering.

The PRD should explain a choice we can defend. That starts with understanding the work.

What else should you know before starting discovery?

Can I write a PRD before interviewing users?

You can draft assumptions and constraints first. Keep them provisional until research supports the problem and the proposed outcome.

Should I interview stakeholders or users?

Speak with both. Stakeholders explain business constraints. Users explain the work and its consequences. Keep their perspectives distinct when they disagree.

Do interviews prove people will buy?

Interviews help explain needs and current behaviour. Check demand through meaningful commitments or an appropriate market experiment before making a commercial forecast.

What should discovery hand over to development?

Hand over the evidence, current user experience, chosen outcome, and reasons for the solution. Include acceptance criteria and unresolved assumptions.