Framing Recommendations

The Gap Between Analysis and Action

A finding is a statement about what is. A recommendation is a statement about what to do. The gap between them is the analyst's highest-value contribution, and it is where most work falls short.

Consider a finding: "Customers who contact support more than 3 times in their first 30 days have a 40% higher churn rate." That is a solid analytical finding. It is also inert. It does not tell the business what to do. Should you reduce support contacts? Improve first-contact resolution? Proactively reach out to at-risk customers? The finding supports multiple recommendations, and choosing among them requires business judgment.

The analyst's job is to make that judgment explicit. You are not just a data producer; you are a decision partner. That means converting findings into recommendations that a stakeholder can approve, reject, or modify.

The Recommendation Formula

Every actionable recommendation has four components: the action, the target, the expected outcome, and the owner. If any of these is missing, the recommendation is incomplete.

• Action: What specifically should be done? "Improve onboarding" is vague. "Implement a 5-step interactive tutorial for new users" is specific.
• Target: Who or what is affected? "All users" is too broad. "New free-tier users in their first 14 days" is targeted.
• Expected outcome: What metric will change and by how much? "Reduce churn" is not measurable. "Reduce 90-day churn by 3 points" is measurable.
• Owner: Who will execute this? "The product team" is ambiguous. "The onboarding product manager, with support from the data team" is clear.

Why Analysts Resist Recommendations

Many analysts hesitate to make recommendations because they fear being wrong. This fear is understandable but misguided. A recommendation is not a prediction; it is a proposed action based on available evidence. If the evidence is sound and the reasoning is transparent, a recommendation that turns out to be wrong is still valuable because it advances organizational learning.

The bigger risk is the opposite: an analyst who presents findings without recommendations forces the stakeholder to do the interpretive work. The stakeholder may lack the analytical context to choose the right action, or they may choose an action that the evidence does not support. By withholding recommendations, the analyst does not avoid responsibility; they abdicate it.

The Effort-Impact Matrix

Not all recommendations are created equal. Some require massive effort for marginal impact. Others deliver significant impact with minimal effort. The effort-impact matrix is a simple framework for prioritizing recommendations and for helping stakeholders understand why you recommend one action over another.

The matrix has four quadrants:

• High impact, low effort: Do these first. These are the quick wins that build credibility and momentum. Example: adding a tooltip to clarify a confusing form field that is causing 15% of support tickets.
• High impact, high effort: Plan these carefully. These are the strategic initiatives that require buy-in, resources, and time. Example: rebuilding the onboarding flow based on a full user research study.
• Low impact, low effort: Do these if time permits. These are the incremental improvements that are easy but not urgent. Example: renaming a confusing metric in the dashboard.
• Low impact, high effort: Avoid these. These are the traps that consume resources without moving the needle. Example: building a custom analytics platform when an off-the-shelf solution exists.

Estimating Effort Honestly

Effort estimation is where analysts often fail. They underestimate because they see the analytical work (which they know how to do) but not the implementation work (which they may not understand). A recommendation to "add a predictive churn model to the dashboard" sounds simple until you consider the data pipeline, the model maintenance, the dashboard integration, and the training for the support team.

Always estimate effort in collaboration with the people who will do the implementation. If you are a data analyst recommending a product change, talk to the product manager and engineering lead before presenting the recommendation. Their effort estimate is the one that matters.

Estimating Impact with Appropriate Confidence

Impact estimates should be grounded in your analysis, but they should also carry confidence intervals. If your A/B test showed a 22% improvement with a 95% confidence interval of 15% to 29%, the impact estimate should reflect that range. "This will improve conversion by 22%" overstates certainty. "This is projected to improve conversion by 15-29%, with a point estimate of 22%" is honest.

Stakeholders respect honest uncertainty. It does not weaken the recommendation; it strengthens it by showing you understand the limits of your evidence. It also sets up a measurement plan: if the actual impact falls outside the predicted range, that is a signal to investigate.

The Stakeholder's Perspective

A recommendation that makes sense to you may not make sense to the stakeholder. The difference is usually perspective. You see the data; they see the business. You see the statistical significance; they see the operational feasibility. You see the projected ROI; they see the risk of disrupting a working process.

Before presenting a recommendation, answer these questions from the stakeholder's perspective: What does this cost in time, money, and attention? What could go wrong? What happens if we do nothing? How does this affect my team's other priorities?

If you cannot answer these questions, you are not ready to present the recommendation. Do the work to understand the stakeholder's context, or present the recommendation as a proposal for discussion rather than a decision request.

The "Do Nothing" Baseline

Every recommendation should be evaluated against the alternative of doing nothing. If churn is 9% and your recommendation reduces it to 6%, the relevant comparison is not "6% is good" but "the 3-point reduction justifies the $200K investment." The do-nothing baseline gives the stakeholder a clear reference point.

Sometimes the do-nothing baseline reveals that the recommendation is not worth the effort. If the projected improvement is 0.5 points and the cost is $100K, the honest recommendation might be "do not invest in this now; revisit if the trend worsens." That is a valuable recommendation because it saves resources for higher-impact work.

Sequencing and Dependencies

Recommendations rarely exist in isolation. They have dependencies: recommendation B requires the infrastructure built by recommendation A. They have sequences: the quick win should come first to build support for the strategic initiative. They have tradeoffs: the high-impact, high-effort recommendation may need to be split into phases.

Present recommendations as a portfolio, not a list. Show how they relate to each other. Identify which ones are prerequisites for others. Propose a sequence that balances quick wins with long-term investments. This sequencing demonstrates strategic thinking and makes it easier for the stakeholder to say yes to the overall plan.

The Five Common Objections

Every recommendation faces objections. The five most common are:

1. "The sample is too small." Address this by reporting confidence intervals and acknowledging the limitation. If the sample is genuinely too small, recommend a larger pilot before full rollout.

2. "Correlation is not causation." This is often valid. If your analysis is observational, acknowledge it and propose a controlled experiment to establish causality. If an experiment is not feasible, frame the recommendation as a bet with defined risk rather than a certainty.

3. "We tried something similar before and it did not work." This is a signal to investigate. What was different about the previous attempt? What has changed since then? If nothing has changed, the objection is valid and the recommendation should be revised.

4. "We do not have the resources." This is a prioritization issue, not a validity issue. If the recommendation is high-impact, propose a phased approach that fits within current resources. If it is low-impact, acknowledge that it should wait.

5. "The data does not match what we see anecdotally." This is a signal to dig deeper. Anecdotes can be wrong, but they can also reveal segments or edge cases your analysis missed. Investigate the discrepancy before defending your recommendation.

Pre-Building the Response

The best time to address an objection is before it is raised. If you know the stakeholder will question the sample size, address it in the recommendation itself: "The pilot included 2,000 users, which provides 95% confidence that the true improvement exceeds 15%. We recommend a larger 10,000-user confirmation study before full rollout."

This approach does three things. It shows you have thought critically about the recommendation's weaknesses. It gives the stakeholder a risk management framework. It makes the objection feel like a planned consideration rather than a fatal flaw.

When to Defend and When to Adapt

Not all objections are equal. Some reveal genuine flaws in the recommendation and should lead to revision. Others reflect stakeholder preferences or constraints and should lead to adaptation. The difference is whether the objection undermines the evidence or the implementation.

If the objection undermines the evidence ("your data is wrong"), defend the analysis or investigate the discrepancy. If the objection undermines the implementation ("we cannot afford this"), adapt the recommendation to fit the constraint. Knowing which type of objection you are facing determines whether you push back or pivot.