The Four Questions Every Research Readout Must Answer

A research readout that does not answer "so what do we build" is a document, not a decision.

The Room After the Readout

Picture this: twelve interviews, two weeks of synthesis, a slide deck with seventeen findings. The readout session ends. Someone says "this is really useful." The team moves to the next agenda item. Nothing changes.

The research was real. The insights were real. The problem was structural - the readout answered the wrong questions in the wrong order. It told people what users said. It did not tell them what to do about it.

This is not a communication problem. It is a judgment problem - and most readout formats quietly let the PM skip the judgment.

Why Most Readout Formats Fail

Everyone says research should inform decisions. Most teams actually produce one of two things instead: a data dump or a narrative.

A data dump is a list of findings ordered by frequency or theme. It is comprehensive and useless in a meeting. A narrative is a story about user pain that is compelling but non-committal. It generates empathy. It does not generate a decision.

The four-part structure is different because it forces the PM to complete the chain - from raw signal to recommendation - before anyone else in the room has a chance to fill in the gaps themselves.

The Comparison

The difference in the last column is not subtle. When a room debates what the data means, the PM has handed over their job. When a room debates the recommendation, the PM is doing their job - and the conversation is actually productive.

The Four-Part Structure

Part One: What We Heard

This section carries verbatim quotes and direct observations. Not paraphrases. Not themes. The actual words users said and the behaviors you watched.

Three to five quotes maximum. Each one should make a stakeholder feel slightly uncomfortable - not because the research was inflammatory, but because real user language is almost always more raw than internal language. If you are cleaning up the language to make it more professional, you are softening the signal.

The purpose of this section is to ground every subsequent claim in observable reality. You will refer back to these quotes when you reach the recommendation. The room needs to have heard the users' words before they can evaluate your interpretation of them.

Part Two: Why It Matters

This section translates the signal into business stakes. Not "users are frustrated" - but "if this friction persists, the users most likely to churn are the ones who completed fewer than three trips in their first week."

Stakes have to be specific enough that someone could argue with them. "This matters because users struggle" is not a stake. "This matters because we are losing users at the moment they first try to schedule a recurring ride, and that cohort has three times the lifetime value of one-time users" - that is a stake. Someone can now ask whether the lifetime value number is right. That argument is worth having.

This section is also where you earn the right to interpret. You cannot tell a room what the data means until you have shown them what is at risk if they ignore it.

Part Three: What It Means

This is the interpretation layer - the translation from observed behavior to underlying cause. It is the hardest section to write well and the most frequently skipped.

What users do in an interview is not the same as what they need from your product. A user who asks for a "simpler interface" is almost never asking for fewer features. They are asking for less cognitive load at a specific moment. The interpretation section names that moment and explains why the surface request is pointing at a deeper problem.

This section is not a list of possible interpretations. It is your read of the situation. If you are not willing to commit to an interpretation, the recommendation section will collapse - because recommendations that are grounded in hedged interpretations are not recommendations.

Part Four: What We Recommend

This is where most product managers hedge. They offer two or three options and present them as equally valid. They say "based on the research, we could go in any of these directions" and then look at the room for someone to choose.

That is not humility. That is the abdication of the one thing the PM is uniquely positioned to do - synthesize twelve hours of user interviews, cross-reference them against business context, and arrive at a position.

The room has not done that work. You have. Presenting options is not giving the room more information; it is giving them your uncertainty to manage.

How to Write the Recommendation When You Are Not Certain

Certainty is not the bar. Specificity is the bar.

"We recommend building the recurring-ride scheduler as a standalone flow, separate from the one-time booking interface, with the goal of reducing drop-off at the scheduling step by at least forty percent in the first cohort."

That recommendation is specific. It can be measured. It can be wrong. That is exactly what makes it a recommendation rather than a suggestion.

If you are not certain, you say so inside the recommendation - not instead of it. "We recommend this direction. The assumption we are most uncertain about is whether users will return to a separate scheduling flow or expect it embedded in the confirmation screen. We suggest testing that assumption before we build the full experience."

That is specific. That is honest. That names the uncertainty without using the uncertainty as an excuse to avoid committing.

The Non-Recommendation: What Strong PM Teams Get Right

Consider a product team operating in an environment where research findings frequently point in multiple directions at once - signals from two different user sides that do not always align, layered on top of regulatory constraints that vary by market. This is a common situation for any platform product with supply and demand sides.

One pattern that separates stronger PM readouts in these contexts: the recommendation section includes an explicit non-recommendation. Not a second option. A call-out of something the data suggested that the team is consciously setting aside - and the specific reason why.

It might read like this: "The interviews also surfaced demand for in-app tipping. We are not recommending we pursue this now. The signal was present in four of twelve interviews, it skewed toward a user segment that already has above-average retention, and the driver-side implications require a separate research track before we can evaluate it responsibly."

That section does something the rest of the readout cannot do on its own. It proves the recommendation is a judgment call. It shows the room that the PM saw the data that pointed elsewhere and made a deliberate choice not to follow it - not because they missed it, but because they weighed it against context the data alone could not provide.

Without the non-recommendation, a room will always wonder: did the PM choose this direction because the evidence was overwhelming, or because it was the path of least resistance? The non-recommendation answers that question before it is asked.

The Judgment Turn

Here is the uncomfortable position: the "What we recommend" section is the only section in the readout that actually matters to the business.

Everything before it is setup. The quotes establish credibility. The stakes establish urgency. The interpretation establishes coherence. But the recommendation is the only part that requires the PM to do something no one else in the room can do - commit to a direction based on context only the PM holds.

When you offer options instead, you are not being collaborative. You are making the research feel rigorous while quietly preserving the option to not be wrong. That is the move that kills research credibility over time. After two or three readouts where the team leaves without a clear direction, the research program stops being taken seriously - not because the research was bad, but because it never felt decisive.

The four-part structure does not guarantee the right call. It guarantees that a call was made, that it is traceable back to specific observations, and that the PM has named what they are choosing not to do and why.

That is what earns the next research budget.

Key Takeaways

1. A readout that presents options instead of a recommendation transfers the judgment to people with less context than the researcher - that is the wrong direction for information to flow.
2. The four-part structure (What we heard → Why it matters → What it means → What we recommend) forces each section to earn the next, rather than letting the room fill in the gaps.
3. Specificity is the bar for a recommendation, not certainty - a specific recommendation that turns out to be wrong is more valuable than a vague one that was technically right.
4. An explicit non-recommendation (what the data suggested but the team is consciously setting aside) is what separates a recommendation from a cherry-pick.
5. Research credibility is not built by producing comprehensive findings - it is built by producing decisions the team can act on and trace back to evidence.

Related Articles

• How to Run Research as a Team Without It Dying in a Handoff
• How to Turn Messy Interview Transcripts Into Product Decisions
• The PRD Engineers Actually Read