What would have happened anyway? The missing line in case studies
A polished launch story shows what happened, not whether the product choice mattered. Use a counterfactual to make the decision, evidence, and trade-off legible.
On this page 4 sections
A case study can show a thoughtful process and still leave the reader unsure whether the product decision mattered. The missing piece is often a counterfactual: what would likely have happened if the team had chosen the next-best option instead?
Make the alternative explicit#
A launch narrative tends to move in one direction: problem, solution, result. That structure hides the choice. If the case study never names a credible alternative, the selected path can look inevitable rather than reasoned.
Write one sentence before describing the solution: “We could have _, but chose _ because ____.” The alternative should be something a competent team might actually do, not a straw man.
For example, imagine a workflow where users repeatedly submit incomplete requests. The options might be to add more required fields up front, or let people submit quickly and route missing details to a follow-up queue. Neither is universally right. The trade-off is between preventing incomplete work at entry and preserving a low-friction start while accepting operational follow-up.
State what the alternative predicts#
A counterfactual is useful when it makes a prediction. “The longer form would reduce missing information” is testable; “the longer form would be worse” is not.
Use a compact comparison:
| Choice | Expected benefit | Cost or risk | Evidence to watch |
|---|---|---|---|
| Require more fields | Fewer incomplete requests | More abandonment before submission | Completion rate and missing-field rate |
| Accept, then follow up | Lower entry friction | More manual queue work | Submission rate and follow-up volume |
The table does not need invented results. If the work was not measured, label the evidence as a hypothesis or an instrumentation gap. Clear uncertainty is more credible than a precise-looking number without a trustworthy source.
Show why the decision changed#
The strongest case studies show how evidence moved the team from one option to another. Say what you knew at the decision point, what remained unknown, and what observation would have caused you to reverse the choice.
A useful template:
We chose A over B because [evidence or constraint]. We accepted [specific cost]. If [observable signal] crosses [threshold or condition], we will revisit the choice.
If no threshold existed, say what review point or qualitative trigger the team used. Do not retrofit certainty after the outcome is known. Separate the original reasoning from what you learned later.
Keep the claim proportional#
A case study should not claim that a decision caused an outcome when several changes happened together. It can still be useful: describe the decision, the evidence available, the observed result, and the limits on attribution.
Before publishing, ask: What was the real alternative? What did each option predict? What cost did the chosen path accept? What evidence could have changed my mind? If those answers fit in a few sentences, the reader can evaluate your judgment—not just admire the screenshots.