Two Documents That Look Like One
In most organizational publishing, success stories and case studies are treated as the same thing. They appear in the same sections of websites, are assigned to the same writers, go through the same approval processes, and are presented to the same audiences under the same heading. The difference between them is rarely made explicit. Most organizations could not produce a written standard that distinguishes the two, and the people producing the documents are rarely asked to.
This conflation has costs. Success stories and case studies are built for different purposes, structured by different logic, and useful to different readers. Treating them as equivalent produces documents that do neither job well — not persuasive enough to serve marketing purposes, not rigorous enough to serve practitioner purposes. More commonly, it produces documents that serve marketing purposes tolerably while failing practitioner purposes entirely. The marketing function gets a usable artifact; the practitioner who needed something to reason with gets a brochure.
The distinction matters because practitioners and general audiences respond to the two forms very differently. A general audience — funders, policymakers, prospective clients, the public — responds to success stories. A practitioner audience — people who face similar problems and are trying to determine whether an approach might work in their context — responds to case studies. When organizations produce success stories and call them case studies, they create a documentation asset that looks like it serves practitioners but does not. The label promises evidence; the document delivers a conclusion.
This is not a small problem. It shapes whether practitioners learn from each other's experience, whether field knowledge advances, and whether organizations that invest in documentation get any return on that investment in terms of field contribution. An organization can spend years producing case studies, build a library of them, point to that library as evidence of its commitment to knowledge sharing — and contribute nothing usable to the field, because every document in the library was structurally a success story.
The Structural Difference
The difference between a success story and a case study is not tone, length, or genre. It is structural — a difference in what the document is trying to do and what information it therefore includes and excludes. Two documents can be identical in length, written in the same voice, and describe the same project, and still belong to different categories, because the selection logic underneath them is different.
A success story is designed to persuade. Its goal is to produce in the reader a positive impression of the organization, the intervention, the approach, or the outcome. Everything in a success story is selected and framed to serve that goal. Information that undermines the impression is excluded. Information that complicates the narrative is smoothed. Uncertainty is resolved in the favorable direction. Failures are either omitted or reframed as temporary obstacles on the path to success. The implicit argument of a success story is: this worked, we did it, you should think positively about us or it.
A case study is designed to inform. Its goal is to give the reader enough information to understand what happened, why it happened, and whether it might happen again under similar or different conditions. A case study includes information that a success story would exclude — what failed, what was uncertain, what about this context was specific and might not generalize. The implicit argument of a case study is: here is what we found, here is how we found it, here is what we think it means, and here is what you would need to know to decide whether it applies to your situation.
These are genuinely different purposes, and the structural differences follow from them. A success story presents a conclusion; a case study presents evidence and lets the reader draw conclusions. A success story resolves uncertainty; a case study names it. A success story tells the reader what to think; a case study gives the reader the information to think with. The mechanism is selection: a success story selects the information that supports a predetermined conclusion, and a case study selects the information a skeptical reader would need to evaluate the conclusion independently. Same project, opposite selection logic.
This is why you cannot convert a success story into a case study by adding a paragraph that admits one minor difficulty. The difficulty in a success story is decorative — it exists to make the eventual success more credible. The difficulty in a case study is load-bearing — it changes what the reader can conclude. The test is whether removing the disclosed failure would change the reader's assessment of whether the approach would work for them. In a success story, it would not. In a case study, it might.
The Case Study vs. Success Story Diagnostic
Any document can be run through a five-question diagnostic to determine which category it actually belongs to, regardless of what it is labeled. The questions are ordered roughly from easiest to hardest to satisfy, and a document does not need to fail all five to be functioning as a success story. A document that fails the first two is already not serving practitioners, whatever its heading says.
Question 1: Does the document describe what failed?
If the answer is no — if the document describes only the final approach and its outcomes, without acknowledging setbacks, approaches that were abandoned, or moments where the intervention did not work as expected — it is a success story. Real implementations have failures. Their absence is a structural marker of curated presentation. The absence is not evidence that the work went smoothly; it is evidence that the document was edited to appear that it did.
If the answer is yes — if the document includes specific description of what was attempted and did not work, with analysis of why it failed and what was learned — it is exhibiting a case study characteristic. The qualifier "specific" matters. A document that says "there were challenges along the way" has not disclosed a failure; it has gestured at the existence of failure while withholding the content that would make it useful. Disclosure means a reader could identify what to do differently.
Question 2: Does the document acknowledge genuine uncertainty about the outcomes?
If the document presents outcomes with precision that the measurement approach does not support, attributes outcomes to the intervention without acknowledging alternative explanations, or states conclusions without qualifying what additional evidence would be needed to confirm them — it is exhibiting a success story characteristic. The most common form of this is attribution without a counterfactual: the outcome improved after the intervention, therefore the intervention caused the improvement, with no acknowledgment that other things changed at the same time.
If the document names its measurement uncertainty, acknowledges that attribution is imperfect, and bounds its conclusions to what the evidence actually supports — it is exhibiting a case study characteristic.
Question 3: Does the document specify the conditions under which the approach is likely to work — including conditions under which it would not?
A success story either omits conditions entirely (treating the approach as universally applicable) or mentions conditions only to show that they were met in this case (conditions as context, not as analytical criteria). The reader is left to assume that the approach is the active ingredient, when often the conditions were doing most of the work.
A case study treats condition specification as essential. It names what needed to be present for the approach to work, identifies what was specific to this context and might not generalize, and — in stronger versions — names the conditions under which a different approach would be more appropriate. This is the single most useful thing a case study can do for a practitioner, and the single thing success stories most reliably omit, because naming the conditions under which an approach fails undermines the impression that the approach is the reason for the success.
Question 4: Are the scope claims proportionate to the evidence?
If the document draws conclusions about large populations or general approaches from evidence about one implementation in one specific context — and does not acknowledge the limits of this generalization — it is a success story. The overstated conclusion is a persuasion tool, not an analytical finding. "This model works" is a larger claim than "this model worked once, here, under these conditions," and the gap between the two is where the persuasion lives.
If the document bounds its conclusions explicitly, distinguishes between what the evidence demonstrates and what the authors believe based on broader experience, and identifies what additional evidence would be needed to support broader claims — it is exhibiting a case study characteristic.
Question 5: Could a practitioner use this document to make a more informed decision about whether to attempt something similar?
This is the functional test, and it subsumes the other four. A success story tells you that something worked; it does not give you the information to decide whether it would work for you. A case study gives you the information to make that assessment.
If the document provides enough context specificity, failure disclosure, uncertainty acknowledgment, bounded scope claims, and condition specification that a practitioner in the same field could use it to reason about their own situation — it is functioning as a case study. If it does not — regardless of its label — it is functioning as a success story. The functional test is unforgiving precisely because it ignores intent. A document produced with every intention of being a rigorous case study still fails the test if a practitioner cannot act on it.
Why Success Stories Prevail in Organizational Publishing
The prevalence of success stories in organizational publishing is not the result of ignorance about what practitioners need. It is the result of organizational dynamics that systematically favor success stories over case studies, even when case studies are declared to be the goal. The dynamics are structural, which is why exhortation does not fix them. You cannot ask a system to stop producing what its incentives reward.
The publication selection problem. Organizations publish when they have something to show. An implementation that produced strong, clean, attributable outcomes generates a publication impulse. An implementation where outcomes were mixed, hard to attribute, or disappointing does not. The result is a published record that is not a random sample of implementations — it is a sample of implementations that produced outcomes worth publicizing. Practitioners who read the published record without accounting for this selection bias will systematically overestimate how often interventions of a given type succeed. This is survivorship bias operating on a field's entire knowledge base: the failures are not refuted, they are simply never written down.
Case studies that include failure disclosure and uncertainty acknowledgment partially correct for this bias by describing the full experience rather than only the parts worth publicizing. But the selection problem persists at the level of what gets published at all — the case study that honestly describes a partial success is still more likely to be published than the case study that honestly describes a failure. Correcting the content of individual documents does not correct the selection of which projects become documents.
The review and approval process. Most organizational case studies go through a review process that involves the leaders whose decisions are being assessed. These leaders have obvious interests in favorable presentation. The review process rarely improves the failure disclosure, uncertainty acknowledgment, or bounded scope claims that would make the document more useful to practitioners. It regularly improves the framing, the headline outcomes, and the organization's position in the narrative. Each review pass tends to move the document further toward success story, not because anyone intends that outcome, but because every reviewer is optimizing for the thing they are accountable for, and no reviewer is accountable for practitioner usefulness.
The people most positioned to add honest failure disclosure and uncertainty acknowledgment are the practitioners who did the work. The people with authority to approve publication are typically leaders with interests in favorable presentation. These interests are not dishonest — they are human — but they systematically shape what gets published. The asymmetry is the problem: the knowledge sits with the people who lack approval authority, and the approval authority sits with the people who lack the incentive to disclose.
The communications function. In many organizations, case studies are owned by communications or marketing teams whose core function is favorable presentation. This is appropriate for success stories. It is misaligned with case study production. Communications professionals are trained to find the best angle, tell the most compelling story, and eliminate information that complicates the narrative. The skills that make a good success story producer make a poor case study producer. Asking a communications team to produce a rigorous case study is asking them to suppress the instincts that make them good at their actual job.
Organizations that want to produce genuine case studies need to locate case study production with practitioners or in functions with different incentives — evaluation teams, quality improvement functions, research arms — rather than with communications teams. The placement of the work in the org chart is not an administrative detail; it determines which selection logic the document will be subjected to.
The cost of honest failure disclosure. Organizations that acknowledge failures in published documentation take on reputational risk. If the failure is significant enough, the documentation creates a record that critics, competitors, or funders can use. This risk is real, and it shapes what gets published. A funder reading a candid account of a failed component may not finish the sentence that explains what was learned; they may stop at the word "failed."
The counterargument is also real: organizations that consistently produce honest, rigorous case studies build long-term credibility with practitioner audiences that success stories cannot create. Practitioners who trust that an organization's case studies include honest failure disclosure will read and act on those case studies. Practitioners who know that an organization's case studies are curated success stories will file them. Credibility with a practitioner audience is a slow-compounding asset; it cannot be bought with a single strong document, and it cannot be recovered quickly once a reader learns to discount everything the organization publishes.
The tradeoff between short-term reputational risk and long-term practitioner credibility is real, and different organizations will weigh it differently. An organization whose audience is primarily funders may rationally choose success stories. An organization whose authority depends on a practitioner community treating its documentation as trustworthy cannot. The point is to weigh the tradeoff explicitly, rather than defaulting to success stories while calling them case studies — which is the worst of both, because it incurs the production cost of a case study while delivering the field value of neither.
The Costs of the Conflation
The most significant cost of treating success stories as case studies is that practitioners who might benefit from field knowledge cannot access it. They may read the available documentation and conclude that approaches are better established than they are, because the published record shows only successes. They may attempt replications that are unlikely to succeed in their context, because the condition specifications that would have told them the original context was different from theirs were omitted. They may make decisions based on stated certainty that was not warranted by the underlying evidence. The cost is not only that they learn nothing; it is that they learn the wrong thing with confidence.
This matters most in fields where the gap between available published case studies and the actual distribution of implementation experience is largest. Development organizations, agricultural extension systems, organizational change consulting, educational reform — these are fields where practitioners work in highly variable contexts, where the published literature is heavily curated toward favorable outcomes, and where the cost of failed implementation is paid not by the publishers but by the communities or organizations involved. In these fields the conflation is not a documentation-quality issue; it is a transfer of risk from the publisher to the practitioner who trusted the publication.
The governance of organizational documentation is a substantive question, not a stylistic one. Organizations that invest in producing genuine case studies — documents that survive skeptical reading by practitioners, that disclose failure honestly, that bound their claims to their evidence — are making a contribution to their field. Organizations that produce success stories while calling them case studies are making a contribution to their brand. The two activities can share a template, a writer, and a webpage, which is exactly why they are so easily confused.
What to Do This Week
You do not need to redesign your organization's documentation function to act on this distinction. You can start with a single audit. Take the three documents your organization currently calls case studies that it is proudest of, and run each through the five-question diagnostic. Count how many disclose a specific failure, name a real measurement uncertainty, specify the conditions under which the approach would not work, bound their scope claims to their evidence, and would let a practitioner reason about their own situation. The count tells you, without ambiguity, what you have actually been producing.
If the audit returns success stories, you have two honest options, and they are both legitimate. The first is to relabel: call them success stories, place them with the communications function, and stop claiming they serve practitioners. The second is to produce genuine case studies, which means moving the work to a function with different incentives and accepting the reputational cost of disclosing what failed. What you cannot defensibly do is keep producing success stories under a label that promises evidence — because that is the option that fails practitioners while spending the budget that was meant to serve them.
Both forms have value. Neither substitutes for the other. The discipline is knowing which you are producing and why.
Continue in this series
This piece is part of What Is Organizational Governance? A Systems Practitioner's Complete Guide, my systematic guide to organizational governance and operating systems. Related reading:
- Writing Case Studies That Practitioners Actually Trust
- The Difference Between an Audience and a Community
- Building a Writing Practice Alongside Operational Work
- Why Consistency Compounds Faster Than Quality in Publishing
Working through this in your own organization? I help technical leaders design it directly — advisory engagements.
