Craft

The Portfolio Case Study Template That Sells Your Work

By Dan Kovac · 9 min read

A portfolio case study needs six parts: context, problem, approach, decisions and trade-offs, outcome, and what you would do differently. Aim for 600 to 1,000 words per case study, and three strong ones beat ten thin ones. This is the template for presenting your own work to hiring managers and clients, not the marketing kind that showcases a customer's results.

That is the whole game. Everything below is detail.

First, which kind of case study?

Search for "case study template" and most of what you will find is marketing material: a company interviews a happy customer, wraps the quotes in a branded PDF, and hands it to the sales team. Useful if you run content for a SaaS business. Useless if you are a product manager, designer, or engineer trying to show your work.

A portfolio case study is a different animal. The subject is you. The reader is someone deciding whether to interview you, hire you, or pay your day rate. And the question they are silently asking is not "did this project go well?" It is "how does this person think, and would they think that way for me?"

That changes what you write. A marketing case study sells an outcome. A portfolio case study sells a decision-maker. Everything in the template below is built around that difference.

What sections does a portfolio case study need?

Six. Each one answers a question the reader already has. Copy this structure and fill it in:

1. CONTEXT (2-3 sentences)
   Where were you? Company, team size, your actual role.
   Be precise about what was yours and what was the team's.

2. PROBLEM (1 short paragraph)
   What was broken, for whom, and how did you know?
   Name the evidence: a metric, user complaints, a deadline.

3. APPROACH (1-2 paragraphs)
   What did you do, in order? Research, options considered,
   who you worked with. Process, not platitudes.

4. DECISIONS & TRADE-OFFS (1-2 paragraphs)
   The hardest part and the most valuable. What did you
   choose NOT to do, and why? What did you argue for?
   What constraint forced your hand?

5. OUTCOME (1 short paragraph)
   What changed, ideally with a number. If you can't share
   numbers, share direction and magnitude.

6. WHAT I'D DO DIFFERENTLY (2-3 sentences)
   One honest reflection. This is what separates a
   practitioner from a portfolio-filler.

Two of these sections do most of the selling, and they are the two most people skip. Decisions and trade-offs is where judgement lives. Anyone can list activities; explaining why you cut scope, shipped the uglier option, or overruled a stakeholder is what a senior reader actually wants. And what you would do differently signals self-awareness. Nobody believes a project with no regrets. Naming one makes every other claim on the page more credible.

The template in action: weak vs strong

Here is the same project written twice, for a product manager at a B2B invoicing startup.

The weak version (this is most portfolio project descriptions):

Onboarding redesign. I led the redesign of our onboarding flow, collaborating closely with design and engineering to improve the user experience. The new flow streamlined the sign-up journey, increased activation, and received positive feedback from stakeholders.

Fifty words, zero information. No evidence of a problem, no decisions, no way to tell whether this person drove the work or watched it happen. "Increased activation" without a baseline is decoration.

The strong version, compressed to show the shape (yours would run longer):

Getting new customers to their first invoice. I was the PM for growth at a 40-person invoicing startup, working with two engineers and a designer.

Six in ten new sign-ups never sent an invoice. Sign-up numbers looked healthy, so nobody had noticed; I found it while segmenting activation by week-one behaviour.

I watched fifteen session recordings before touching the backlog. Most people stalled at the same step: connecting a bank account, which we required before anything else. The fix everyone expected was better copy on that screen. The fix I proposed was making the bank connection skippable, so people could send their first invoice manually and connect later.

Sales pushed back, since connected accounts converted to paid at a higher rate. The trade-off: we would risk fewer connections in week one to get more people to the moment the product proved its value. I argued the connection was a commitment people would make after that moment, not before it. We time-boxed it as a four-week experiment to make the decision reversible.

First-invoice rate in week one went from 40% to 58%, and bank connections recovered to previous levels by week three.

What I would do differently: I would have tested the copy change first anyway. It was two days of work, and I never proved the expensive fix was necessary, only that it worked.

Same project. The second version shows a person who finds problems in data, does primary research, makes an argument against a stakeholder, manages risk, and audits their own choices. That is what gets you the interview. If you are a PM, what surrounds the case studies matters too; if you are a designer, there is a full worked UX case study example here.

How long should a case study be?

600 to 1,000 words. Long enough to show reasoning, short enough to respect a reader who is skimming twelve portfolios before lunch.

Under 400 words, you are writing a project description, not a case study; there is no room for the decisions section, which is the part that sells. Over 1,500, you have stopped editing. If a project genuinely needs 2,000 words, it is usually two case studies wearing a trench coat: split it.

Structure for skimmers. Bold your section headings, put the outcome where it can be found in ten seconds, and front-load each paragraph so the first sentence carries it. Reward the skimmer, and some of them become readers.

How many case studies should your portfolio have?

Three good ones. Five if you are senior and they show genuine range.

Ten thin case studies tell a reader you cannot tell your best work from your filler, and that is itself a judgement signal. Three deep ones tell them you curate. Pick for range rather than recency: ideally one shows craft, one shows judgement under constraint, and one shows outcomes you can put a number on. If a single project shows all three, lead with it.

The rest of your work does not vanish. Keep a simple "selected work" list of one-liners below the case studies for anything worth mentioning but not worth 800 words. For the fuller picture of the surrounding pieces, see what to include in a portfolio.

How do you write a case study when the results are confidential?

Abstract the numbers, keep the reasoning. NDAs almost always protect the specifics: revenue figures, customer names, unreleased features. They almost never protect the thing that makes your case study good, which is how you thought.

Four techniques that keep you safe and useful:

• Use relative numbers. "Cut processing time by roughly a third" reveals nothing commercially; "from 91 seconds to 62" might.
• Describe the company, not the name. "A top-four Australian bank" or "a Series B logistics startup" gives the reader all the context they need.
• Keep every decision. The trade-offs you weighed and the options you rejected are your intellectual property, not your employer's secrets. Write those in full.
• When in doubt, ask. A two-line message to your old manager is cheaper than a takedown request. Most will say yes to an anonymised version.

A case study with abstracted numbers and sharp reasoning beats one with precise numbers and no reasoning, every time. Interviewers can always ask for specifics in the room.

Do side projects count?

Yes, if you treat them with the same rigour. A side project case study fails when it reads like a feature list ("built with React, deployed on Vercel"). It works when it follows the same six sections: what problem you noticed, what you tried, what you decided, what happened.

Side projects have one advantage client work never does: you made every decision, so every trade-off is yours to explain. They are especially valuable when you are changing fields, when your best professional work is locked behind NDAs, or when you are early in your career and the honest answer to "context" is "university". One shipped side project with real users and an honest post-mortem outweighs a portfolio of tutorials.

FAQ

Can I write a case study about a project that failed?

Yes, and a good one is memorable precisely because almost nobody does it. The structure holds; the outcome section reports what did not work, and the reflection section carries more weight. One failure among three case studies reads as honesty. Three failures reads as a pattern, so choose the one with the best lessons.

Should every case study include metrics?

No. Metrics are the easiest evidence to skim, but "shipped in six weeks with two engineers after the original estimate was four months" is also evidence, and so is a before-and-after screenshot. What every case study needs is some verifiable-sounding specific. Vague claims ("improved the experience") are worse than no claims.

How long does it take to write a good case study?

Budget three to four hours for the first one: an hour gathering artefacts and numbers, an hour drafting against the template, and the rest editing it down. The second takes half that. Write it while the project is fresh if you can; reconstructing decisions two years later is the hard part, not the writing.

Can I reuse the same case study across job applications?

The case study itself, yes. What you change is the framing sentence when you share it: which of your three case studies you point a specific reader at, and why. That is another argument for range over volume.

Where should case studies live?

On a page you own, at a link you can drop anywhere: applications, DMs, an email signature, a conference bio. PDFs get lost in downloads folders, and platform feeds surround your work with everyone else's. One stable URL per case study also means people can find your work when they go looking, and being findable changes your odds.

Write one while it is fresh

The template is the easy part to hand you. The habit is the part that pays: one case study written while the details are fresh beats three reconstructed in a panic the week you start job hunting.

A case study is strongest when it does not sit alone. Wired to the project it came from, the experience that produced it, and the writing where you worked the problem out, it stops being a claim and becomes a visible trail of how you think. That trail is the edge over a similar candidate whose judgement is invisible. If you want somewhere to put them, Flexfolio gives you a portfolio on your own link in minutes, with room for case studies, writing, and the rest of your work. Designers can see how it fits their workflow at flexfolio.co/for/designers.