How to Write a Professional Case Study That Shows How You Think

A professional case study is a short, structured account of one piece of real work. Not a project summary, not a gallery, not a testimonial. Its job is to let a reader who was not there understand what the situation was, what you decided, and what happened, well enough to judge how you think.

Most case studies fail in one of two ways. Either they describe the outcome and skip the reasoning ("we redesigned onboarding and activation improved"), or they describe the process in such generic terms that any project could be substituted in ("we conducted research, synthesised insights, and iterated"). The structure below is designed to prevent both.

The structure

Think of these as eight questions. You do not have to answer all of them for every case, but you should know which ones you are skipping and why.

1. Context

Where were you, and what was the situation before the work began? Team size, your role, the stage of the product or company, the time frame. Two or three sentences. The reader needs just enough to calibrate the rest: a decision that is bold at a ten-person startup may be routine at a large company, and vice versa.

2. Problem

What was actually wrong, and how did you know? Be concrete. "Onboarding was confusing" is a diagnosis without evidence. "Sixty percent of new sign-ups never reached the first project screen, and support tickets clustered around the second step" is a problem a reader can take seriously.

If the problem was ambiguous at first and you had to frame it, say so. Problem framing is itself a skill worth showing.

3. Constraints

What limited your options? A launch date already promised to customers. A legacy system that could not change this quarter. One engineer instead of three. A legal or compliance requirement. A stakeholder who had already committed to a direction. Budget.

Constraints are the most under-documented part of most work, and the most revealing. A decision only makes sense in light of what was not possible. Without constraints, every case study reads as if the obvious best option was simply chosen.

4. Decision

What did you choose to do? State it plainly, and state when you committed to it. This is the centre of the case study. Everything before it explains why this decision was reasonable; everything after it shows what it led to.

If the decision was made jointly, say who was involved and what your part was. Claiming sole authorship of a team decision undermines credibility fast.

5. Alternatives

What else did you consider, and why did you reject it? This is the section that most clearly separates a thoughtful practitioner from someone who happened to be present. Two or three alternatives are enough. For each, one sentence on what it was and one on why it lost.

Rejected options often reveal more judgment than the chosen one. "We considered a full redesign but rejected it because the date could not move; instead we removed two steps and rewrote the primary action" tells a reader exactly how you weigh scope against time.

6. Execution

What did you actually do? Keep this proportionate. Execution is usually the longest part of the real work and should be one of the shorter parts of the case study. The reader wants to know what shipped and what it took, not a week-by-week log.

7. Outcome

What happened? Use real numbers where you have them, with their time frame, and be honest about attribution. "Activation rose from 40% to 55% over the following eight weeks; other changes shipped in the same period, so we attribute part of the gain to this work" is more credible than an unqualified claim.

If the outcome was mixed, say so. If it was bad, this is a Failed Case, and it is worth writing up for exactly that reason. See Why You Should Share Failed Projects, Not Just Success Stories.

8. Reflection

What would you do differently? What do you now do by default because of this? Reflection is where the case study stops being a record and becomes evidence of learning. Keep it specific. "I would involve the support team earlier" is useful; "I learned a lot" is not.

Not every case needs every element

A short Idea, a proposal you could not pursue, may have context, problem, proposed approach, expected impact, and the assumptions you would need to validate, and nothing else. A small fix may have a problem, a decision, and an outcome in three paragraphs. A large launch may use all eight sections with subsections.

The goal is completeness of reasoning, not completeness of template. If a section would be padding, leave it out. If a reader would ask "but why?" at some point, that is the section you are missing.

Writing it well

A few things that consistently improve case studies:

• Write in the first person, about your actual role. "I" for what you did, "we" for what the team did. Do not inflate; do not hide.
• Prefer specifics to adjectives. One real constraint beats three descriptions of how challenging the project was.
• Keep confidential information out. You can describe the work at a company without naming the company, and you can describe a metric's direction without disclosing its absolute value. Decide what is disclosable before you write, not after.
• Cut the process theatre. Listing every method you used ("interviews, surveys, affinity mapping, journey maps") without saying what they changed is filler. Mention a method only when it produced a decision.
• Let the title do work. "Reducing review time for a 200-application hiring round" tells a reader more than "Hiring tool case study".

Capturing it while it is fresh

The hardest part of a good case study is not the writing. It is remembering the details: the exact number, the alternative you argued about, the constraint that shaped everything. Those fade fast. The reliable habit is to capture the raw account, a few sentences of what happened and why, soon after the work, and structure it later.

How this maps to YourHero

YourHero is built around this structure. Each Case Study starts with a Story Type, Success, Failed, or Idea, and the core narrative for that type: for a Success Case, Problem, Action, and Result; for a Failed Case, the problem, the attempted action, why it failed, and the learning; for an Idea, the opportunity, the proposed approach, the expected impact, and the assumptions still to validate. Optional modules add Context, Constraints, Decisions, Alternatives, Outcomes, and Reflection when a case warrants them, so a small case stays small and a large one has room.

You can read real examples on Discover, or create your profile and write your first case. Start with the one piece of work you find yourself explaining most often in interviews. That is usually the one worth documenting first.