What the scientific paper can teach us about building business cases that actually work
Pull up any scientific journal article and any corporate business case side by side, and something odd happens. They look like relatives.
Both open with a summary of the whole argument. Both frame a problem and explain why it matters. Both survey existing evidence. Both propose a course of action and spend some time on what could go wrong. Both end with a call for something: further research in one case, a budget approval in the other.
This isn’t a coincidence. It’s convergence. Academic science and corporate finance are, underneath all the surface differences, trying to solve the same problem: how do you convince a skeptical, intelligent audience to accept a conclusion based on evidence and reasoning?
I find that parallel interesting. But what I find more interesting is the question it raises.
If the structures are so similar, why is the quality gap between them usually so wide?
* * *
The Format Without the Method
Here’s my answer: business cases borrowed the format of the scientific paper and left the methodology behind.
The scientific paper isn’t just a structure. It’s a set of practices built up over centuries, refined through failure, and enforced through peer review. State your hypothesis before examining results. Separate what you observed from what you concluded. Acknowledge the evidence that complicates your argument. Show your working. Take your limitations seriously.
These practices aren’t about being cautious. They’re about being right in a way that holds up under scrutiny, which is exactly what a good business case needs to do.
Business cases have inherited the skeleton. What most of them lack is the method that gives the skeleton its integrity.
* * *
What This Looks Like in Practice
This is where “apply scientific thinking to business” arguments usually go woolly, so I want to stay concrete.
Hypothesis before analysis. Scientists commit to their prediction before running the experiment. There’s a name for what happens when you don’t: HARKing, or Hypothesizing After Results are Known. It’s the practice of fitting an explanation to data you’ve already seen, and in research, it’s considered a serious methodological failure.
Business cases do this almost by default. The recommendation comes first, and the analysis gets built around it. Someone has a preferred solution, the spreadsheet gets constructed to support it, and the business case is the packaging.
The fix is straightforward: before any modeling starts, write one paragraph outlining your proposal, the outcomes you expect, and the timeframe in which you expect to see them. Write it down. Share it with the team working on the case. That becomes the hypothesis the rest of the document tests, and it creates a baseline you can return to when someone asks, two years later, whether it worked.
Separating results from discussion. Scientific papers keep these in separate sections on purpose. The results are what happened. The discussion is what you think it means. Conflating the two is one of the most common sources of analytical error, so the convention keeps them apart.
Business cases routinely blend them. Projections get presented as facts. Assumptions disappear inside models. Market-sizing figures appear without any explanation of where they came from or how confident you should be in them.
Label the layers. Here is what we actually observed. Here is what the model predicts, given these specific assumptions. Here is what we conclude from both. A decision-maker who can see those layers separately can engage with your thinking rather than just accepting or rejecting your conclusion. They can challenge an assumption without tearing down the whole case. That’s what it looks like when analysis actually supports a decision, rather than replacing one.
An honest literature review. Before proposing a new study, researchers have to demonstrate they know what’s already out there, including work that’s inconvenient for their hypothesis. The literature review is supposed to be an audit, not a highlight reel.
Business case market analysis tends toward the opposite. Benchmarks get cited when they support the proposal. Competitor examples appear when they went well, and disappear when they didn’t. Industry data gets selected for the framing it provides.
There’s a practical problem with this. Senior decision-makers who approve budgets have usually seen enough business cases to recognize a curated argument when they encounter one. Citing the evidence that complicates your case is counterintuitively effective. It reads as serious work. A CFO who has reviewed a thousand documents optimized for approval will notice the one that actually grapples with the complications.
Transparent methodology. A scientific Methods section is specific enough that another competent researcher could, in principle, replicate the study. Business case models almost never work this way. The outputs are visible; the machinery that produced them is not.
In practice: make a list of the ten assumptions your financial model depends on most heavily. For each one, be explicit about what kind of claim it is. Is it a documented fact? A verified industry benchmark? An inference from an analogous case? A judgment call? Put that list in the document. The transparency is the credibility. Showing your working signals something about the quality of the work that the outputs alone can’t convey.
A genuine risk discussion. Scientific papers end with a limitations section. Not a checklist, not a set of reassurances. A real account of what the study didn’t establish and under what conditions the findings might not hold.
Business case risk sections mostly function as reassurance. A brief acknowledgment that things could go wrong. A column of mitigations. Checked. Filed.
A more useful approach is to run a pre-mortem before the document is finalized. Imagine you’re 18 months out and the initiative has failed. What happened? Write down the three most plausible versions of that story. Those become your actual risk section, and they’re worth far more than any forward-looking checklist because they start from the failure and reason backward.
Then go one step further and define, in the document itself, what you’d expect to observe at specific points in time if the initiative is working, and what would tell you it isn’t. That turns the business case into something you can actually use for ongoing decision-making, rather than a document you file after the approval meeting.
* * *
The Objection Worth Taking Seriously
The most common pushback on all of this: business cases are advocacy documents. The person writing one already knows what they want to do. Applying scientific neutrality to them misunderstands what they’re for.
This is a reasonable objection. It’s also, I think, the wrong conclusion to draw from it.
Yes, the author usually has a preferred outcome. But the decision-makers with real authority are trained to spot motivated reasoning. An advocacy document that reads like advocacy gets treated accordingly: reviewed with skepticism, approved with conditions attached, or sent back for more work.
A business case that reads like rigorous analysis does something more useful. It earns trust before asking for a decision. It gives skeptics nothing to work with. It produces real endorsement rather than reluctant sign-off.
Scientists worked this out a long time ago. The scientific paper is a persuasive document. It’s just persuasive in a way that works on skeptical audiences, because it earns credibility before making its ask and because it shows the author understands where their own argument is weakest.
The business cases that sail through approval, that attract real organizational commitment, that still look defensible two years later, tend to be the ones built on honest analysis rather than motivated rationalization. Calling it scientific rigor is just putting a name to what those practitioners are already doing.
* * *
A Last Thought
The structural resemblance between the scientific paper and the business case points to something real. Both documents exist to help someone with decision-making authority act on incomplete information under uncertainty when the stakes of being wrong are significant.
Science’s response to that problem was to build an epistemology around it: practices for knowing things carefully, for being wrong in ways that are detectable and correctable. That took a long time to develop and a lot of bad science to work out.
Business hasn’t faced the same institutional pressure to develop that kind of rigor. But the practices exist, and they’re not difficult to apply. The structure is already there. The gap is just a matter of deciding whether to close it.
* * *
If you found this useful, consider passing it on to someone who writes or reviews business cases. And if you disagree with the core argument, particularly the claim that rigorous analysis is more persuasive than advocacy, I’d genuinely like to hear it in the comments.
This article was first published on Substack on April 1, 2026.