Case studies for small teams

The version of this that works is simpler than the version most people imagine. Most advice about case studies assumes a team that does not exist at your size. Here is the version that does not.

Content is the part of a project most likely to be underestimated and most likely to delay a launch. If two people in the business would answer this differently, that gap is the actual problem.

What to keep

Problem, approach, result, in that order. It is worth being explicit about, because assumptions differ quietly. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

How to approach it

Name the client if they will let you. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. Three things worth confirming about case studies before you move on:

• Someone can say what the current setup is without going to look
• Name the client if they will let you — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.