From Research to Recommendation: Writing Findings Leadership Acts On

There is a quiet failure that happens in almost every organization that does research. A team spends weeks on interviews, surveys, market data and competitor analysis. The work is careful and the findings are genuinely interesting. A report is produced, it is presented once, people say it is useful, and nothing changes. Six months later someone commissions a very similar study.

The research was not wrong. It was never turned into a decision. The gap between a finding and an action is where most research value is lost, and closing it is a skill separate from doing the research well.

I learned this over several years of delivering more than 100 market, competitor and customer studies to a COO and leadership team at a NYSE-listed company. The standard we held ourselves to was “recommendations, not reports”. A report tells people what you found. A recommendation tells them what to do, why, what it will cost, how sure you are, and what would change your mind. Some of those recommendations were adopted: a unified product-experience redesign that replaced a fragmented multi-product setup, an international-expansion choice that led to new hiring and office space, a narrower focus in a new market in place of a partnership. This post is the method behind turning evidence into that kind of decision.

It is the connecting piece between the research playbooks on this site, such as consumer research methods, win-loss analysis and competitive intelligence that moves decisions, and the strategy work in how to write a product strategy that actually gets implemented.

Why good research does not get used

Before the method, the causes. I see five repeatedly.

It answers a question nobody asked. The research began from the researcher’s curiosity, not from a decision someone has to make. Interesting is not the same as useful.

It arrives too late. A decision has already been made, or the window has closed, by the time the findings are ready.

It buries the answer. The conclusion sits on slide thirty-one, after the methodology, the sample description and every finding in the order it was discovered.

It avoids a position. The report lists considerations on both sides and declines to recommend, because recommending creates risk for the author.

It ignores the audience. The reader is a senior executive with a few minutes and a dozen other priorities, and the document is written for a peer reviewer.

Every part of the method below is a response to one of these.

Step 1: Start from the decision, not the data

Before gathering anything, I write down the decision the research is meant to inform, in a single sentence, together with who will make it and by when.

“Should we enter Canada through a partner or on our own, and what do we need to decide before the end of the quarter?” is a decision. “Understand the Canadian market” is a topic.

This one habit fixes the first two failure modes. It scopes the work to what the decision needs and sets a deadline the research has to meet. It also tells you what kind of evidence will matter. If the choice is between two options, you need evidence that discriminates between them, not a general picture.

Add two more lines: what you would do under each plausible answer, and what would change the decision. If the research cannot change what anyone does, do not do it.

Step 2: Form a hypothesis early and let evidence correct it

A technique I borrow from strategy consulting is to start from an answer. After a few days of orientation I write my best current guess at the recommendation, then spend the remaining time trying to prove it wrong. This is faster than collecting facts until a conclusion appears, because it tells you which evidence to look for.

It also forces honesty. If your hypothesis is “narrow the focus rather than partner”, you know exactly which evidence would overturn it: partner economics that beat your own, a market structure that rewards scale you lack, competitors that a partner would help you beat. You go and look for those first. When the hypothesis survives a serious attempt to break it, you can recommend it with real confidence. When it does not, you have saved yourself from a confident wrong answer.

Step 3: Triangulate

No single method is reliable alone. The findings I trust come from several independent sources pointing the same way.

• Customers and users: interviews, surveys, focus groups and behavior data.
• Market and competitors: sizing, benchmarking and positioning.
• Internal data: funnels, cohorts, sales records and support history.
• Experts and analogues: conversations with people who have faced the problem, and the experience of comparable companies.

Each source has a blind spot. Surveys capture stated preferences, which differ from behavior. Interviews are rich but small. Internal data describes the customers you already have, not those you have lost or never won. When sources disagree, the disagreement is often the most interesting finding, and it is a reason to dig deeper before recommending anything.

I also keep a running log of confidence for each claim: well evidenced, reasonably supported or still a judgment. It makes the final write-up much easier, because the confidence levels are already there.

Step 4: Find the insight, then the “so what”

Data is not insight. An insight explains why something is happening in a way that changes what you would do. There is a simple test: does the statement contain a “because”, and does it point to an action?

Here is an illustrative pair. “Forty percent of surveyed customers rated the experience as inconsistent” is a data point. “Customers treat our products as separate companies because the experience changes at each handover, and that is the main reason they do not move between them” is an insight, and it points toward a design response.

For each finding, I ask “so what?” until I reach something a decision-maker can use. Then I check that every recommendation I plan to make is supported by at least one insight, and every insight I include supports a recommendation. Findings that connect to nothing go to the appendix.

Step 5: Structure the argument with the answer first

Here is the single most useful structural idea I know. Barbara Minto’s pyramid principle says to lead with the conclusion, then support it with a small number of grouped arguments, each of which is in turn supported by evidence. The reader gets the answer immediately and can drill down as far as they need.

In practice, a recommendation document looks like this:

1. The recommendation. One or two sentences. What should we do?
2. Why. Three reasons, at most, each stated as a claim, not a topic.
3. The evidence. Under each reason, the strongest supporting data, in order of strength.
4. The alternatives. What else we considered and why it ranks lower.
5. The risks and what would change the answer.
6. What happens next. The decision needed, the owner and the timing.

Minto also offers a framing for the opening that I use often, usually called SCQA: the situation everyone agrees on, the complication that creates a need for a decision, the question that raises, and the answer you recommend. It gets a busy reader oriented in four sentences.

Write each section heading as a conclusion, not a label. “Partnering would cost more than it saves in year one” tells the reader something. “Partner economics” does not. A reader who only skims the headings should still be able to follow the argument.

Step 6: Present options, a recommendation and a confidence level

Executives rarely want a single option dropped on them, and they rarely want a menu with no guidance. The format that works is a small set of real options, a clear recommendation, and an honest statement of confidence.

Two to four options. Include the status quo as one of them whenever it is realistic. Describe each in a sentence and then compare them on the same few criteria: cost, speed, risk, strategic fit and reversibility.

A clear recommendation. Say which one you would choose and why. The decision-maker may disagree, but they should never be unsure what you think.

An explicit confidence level. Separate what you know from what you believe. Some findings are solid: the retention numbers are what they are. Others are judgment built on incomplete information, and a good recommendation says so. I would rather say “I am highly confident the current approach is not working and moderately confident that the alternative will work, for these reasons” than offer a verdict that pretends to certainty. People trust a recommendation more when it shows its uncertainty, and it protects the decision-maker, who can then price the risk. This is the same principle I use when concluding a commercial due diligence.

What would change the answer. Name two or three conditions that, if they turned out differently, would reverse the recommendation. It makes the recommendation falsifiable and it tells the organization where to keep watching after the decision.

Step 7: Make the numbers decision-grade

If the recommendation involves money, a rough business case turns the argument from opinion into assumptions that can be examined. I describe how to build one in how to build a business case for a product bet, and a simple calculator to try it is the product business case calculator.

A few rules of thumb for numbers in a recommendation:

• Show the range, not a single figure. A base case with an optimistic and a pessimistic scenario is more credible and more useful.
• Make the three assumptions that matter most visible. Everything else is detail.
• Source every key figure. The reader should be able to see where each number came from.
• Compare to something. A figure with no benchmark has no meaning. Compare to last year, to a competitor, or to the cost of the alternative.

For sizing, a bottom-up build is far more defensible than a borrowed top-down number. The method is in market sizing for expansion.

Step 8: Write for the reader who has five minutes

The reader is senior, busy and skeptical. Write accordingly.

Put the answer on the first page. If the reader stops there, they should know what you recommend and why.

Use plain words. A short sentence beats a long one. Define every acronym once or avoid it. If a sentence can be read two ways, rewrite it.

One idea per paragraph, one message per slide. A slide whose title states its conclusion and whose body proves it is worth three slides of topic labels.

Prefer a simple chart to a table of numbers. And label the insight on the chart: a title that says what to notice.

Move methodology to the appendix. The reader needs one line on how solid the work is, not a page. Keep the detail for those who ask.

Cut. For each section, ask whether the decision would change if it were removed. If not, remove it. Short documents get read.

Step 9: Pre-wire the decision

The meeting where a recommendation is decided is the worst place to present it for the first time. By then, positions are fixed and nobody wants to be seen changing their mind in public.

Talk to the key people beforehand, one at a time. Share the headline recommendation and listen. Ask what concerns them, what would worry the others, and what evidence they would need. Where they are right, adjust the recommendation. Where they are wrong, you now know which objection to answer, and with what. People who have contributed to a recommendation and seen their input reflected tend to support it in the room.

Pre-wiring is also how you find out who is losing something. A recommendation that quietly cancels someone’s project will meet resistance, and you want to know that before the meeting, not during it. I come back to this in the adoption step of writing a product strategy.

Step 10: Close the loop

A recommendation is not finished when the meeting ends. Three things keep it alive.

A decision record. A short written note of what was decided, by whom, on what evidence and with what assumptions. Months later, when circumstances change, you can see which parts of the logic still hold.

A clear owner and next step. Decisions without owners drift. Before the meeting ends, the action, the person and the date should be agreed.

A follow-up. Return after the agreed interval to report what happened, against the assumptions you set out. When the recommendation worked, you build credibility. When it did not, you show the intellectual honesty that makes the next one trusted. Both are valuable.

Common mistakes

Reporting everything you found. A recommendation is selective. The discipline is in what you leave out.

Hiding the answer. If the conclusion needs the reader to wade through methodology first, many will never reach it.

Recommending nothing. “It depends” is sometimes true and rarely helpful. State what you would do and the conditions under which you would change.

Overstating confidence. One caught overreach damages every later recommendation.

Surprising people in the room. Surprises produce defensiveness. Pre-wire.

Skipping the alternatives. Without them, the recommendation looks like advocacy.

Letting the document be the end. Without an owner and a follow-up, it is a report again.

The short version

• Research that does not become a decision is wasted. The gap between finding and action is a skill of its own.
• Start from the decision, who makes it and by when, and add what you would do under each plausible answer.
• Form a hypothesis early and try to break it. Triangulate across customers, market, internal data and experts.
• Turn findings into insights that explain why, and check that each leads to a “so what”.
• Structure the argument with the answer first, supported by no more than three claims, and use headings that state conclusions.
• Show a few real options, a clear recommendation, an honest confidence level and what would change your answer.
• Make numbers decision-grade with ranges, visible assumptions and comparisons.
• Write for a reader with five minutes, pre-wire the people who will decide, and close the loop with a decision record, an owner and a follow-up.

Where to go next

The natural next read is build, buy, or partner, which applies this method to one of the most common recommendations leadership is asked to make. To make the financial argument concrete, read how to build a business case for a product bet. And if you want the broader frame that these recommendations feed into, how to write a product strategy that actually gets implemented is the companion piece.

This post is part of the product strategy guide, a reading path through all seven guides and the free tools that go with them.

---

I am Deepanshu Grover, a Senior Product Strategy Consultant in Paris. I take ambiguous, high-stakes product and business questions, run the analysis, and see the recommendation implemented. If you are turning research into a decision, connect on LinkedIn or get in touch.