How to Write a Case Study for a Product That Has Not Launched

Selection is where most pre-launch case studies succeed or fail, long before any writing happens. You want people who felt the problem acutely, who used the product enough to have an opinion, and who will let you publish specifics. The biggest logo is not automatically the best story; a smaller customer who can explain the problem, process, and result may be more credible to the next buyer per 100tasks' testimonial question guide.

Run candidates through a short screen before you commit:

That last row is worth its own process. A design partner agreement should lock scope, success measures, and reference rights up front, so publishing later is a formality rather than a negotiation as the pilot proof framework recommends. If you have no such agreement yet, ask for permission in writing before the interview, covering quotes, images, logo, recordings, and results.

Aim for two or three partners rather than one. Salesforce's step-by-step guidance on case studies starts with defining the objective and then choosing the client whose experience aligns with it in Salesforce's small business guide. With a single partner you are hostage to one company's timeline, legal review, and enthusiasm. Two or three also lets you show the same problem in different contexts, which is exactly what a cautious pre-launch buyer needs: evidence the solution works beyond one friendly pilot.

The strongest structural advice for case studies is also the most ignored: start with the buyer's problem, not your feature list. Grey Matter's analysis of why case studies fail finds that companies build stories around their most exciting wins while prospects are stuck on basic questions like whether this will solve their specific problem, and whether anyone like them has succeeded per Grey Matter's guide to case studies that prove messaging.

A practical way to apply this before launch:

1. Write down the three to five core problems your positioning claims to solve, in the buyer's words.
2. For each one, note whether you have a design partner who actually felt it.
3. Read the gaps aloud. Any core problem without a matching partner is a claim you cannot yet support, and your case study should not pretend otherwise.
4. Pick the one or two problems where you have both an acute partner and usable artifacts, and write those first.

This produces a decision rule you can reuse: publish a case study for a problem only when you can name the person, describe their old workflow, and show what changed. Otherwise, keep the claim off the page and out of the launch deck.

The framing also shapes the narrative. Good case studies follow a story arc where the customer is the hero and the vendor is the guide, not the other way around as Elliott Pearce's best-practices guide explains. Before launch, that arc matters even more, because the reader's sympathy for the customer's struggle is doing the persuasive work that results usually do.

A recorded 45 to 60 minute conversation is the single highest-yield activity in this process. Structure it in three blocks of roughly 20 minutes each: background and the old way of working, what happened after they started using the product, and where they are now and what comes next per Edify's case study process. Record it, with permission, and take structured notes so you can focus on the dialogue rather than transcription.

Questions that reliably produce usable pre-launch material:

• What was happening in your business when you first looked for a solution, and why did it become urgent then?
• Walk me through the last time you did this the old way, step by step.
• Who else felt the problem, and how did it affect them?
• What alternatives did you consider, including doing nothing?
• What nearly stopped you from working with us?
• What changed in your week after you started using it?
• What would you say to someone in your role who is considering it?

Several of these lean negative on purpose. Asking what nearly stopped them and what they still find lacking keeps the story credible, and the answers often become the most persuasive lines in the write-up because they pre-empt the reader's objection. A quote that acknowledges a limitation reads as true; an unbroken string of praise reads as marketing.

Prepare before the call. Review the original goal, timeline, and scope, verify any usage or outcome data you plan to discuss, and tell the customer where the material may appear and how approval will work per the interview preparation checklist from 100tasks. Do not send a script that tells them what to say. Send topics, not sentences.

The case study is only as strong as the artifacts behind it. Collect them during the pilot, not after, because memory reconstructs and tidies, and tidied evidence is easy to challenge. A pilot proof framework worth copying asks you to capture customer type, the specific pain, the old workflow, pilot scope, what was tested, who participated, success signals, objections surfaced, a factual quote, what changed afterward, and an explicit statement of what the evidence does and does not prove per Dowhatmatter's B2B pilot template.

Here is the collection checklist to hand a founder today:

Not all proof is equal, and it helps to rank it. Compliments on the interface and survey interest sit at the weak end; repeated use, stakeholder questions, and a genuine workflow change are better; a signed letter of intent, a paid pilot, an expansion request, or a referral is strong per the proof strength ladder in the same framework. Lead with the strongest item you have and label it precisely.

Labeling is the part people skip. Write "three users, 14 days, measured by our own logs" rather than "customers love it." Write "the pilot covered UK vendors only" if that is true. The template's final field, what this proves and does not prove, is the one that builds trust with a reader who is already suspicious of pre-launch claims. For a model of how careful B2B writers handle this, the structure in Articulate's guide explicitly separates the challenge, the process, and the result so a reader can see which part is evidence and which is context in Articulate's guide.

Pair numbers with quotes. The most useful quote includes a concrete figure and a human reaction in the same breath. One example cited in Gainsight's storytelling guide has a customer describing 200 users turning on a feature within a week and noting it would otherwise have been 200 phone calls per Gainsight's case study storytelling guide. That single sentence carries a number, a comparison, and a tone of voice. Collect those.

Once you have the artifacts, the page itself is straightforward. A workable structure:

1. Headline and summary. Name the customer, the problem, and the stage honestly. A title like "How a three-person finance team replaced a 10-hour weekly invoice match with a 14-day pilot" tells a reader exactly what they are getting.
2. The problem in their words. Open with an anecdote or a concrete scene from the old workflow rather than company boilerplate. Setting the scene before the pitch is the first move in Gainsight's storytelling approach per Gainsight.
3. Context. Who the customer is, their role, team size, and why the problem mattered then.
4. What you built with them. The pilot scope: how long, how many users, what was manual, what was automated. Naming your own manual onboarding is a credibility signal, not a weakness.
5. What happened so far. The measured change, labeled as early or small-sample, with the method stated.
6. What it does not prove. One short paragraph on limits, gaps, and the objections that remain open.
7. What comes next. What the customer plans, what you are building, and what a reader in the same situation should do.

Keep it scannable. Adobe's case study guidance stresses clear copy, a standard format, and claims supported by data or customer statements per Adobe's guide to writing case studies. A dense block of text that reads like a brochure gets closed. Headings, a short summary, and one or two pull quotes do more than another paragraph of setup.

If you are drafting the page yourself and want a scaffold, this outline keeps you honest about which sections have evidence and which are still empty:

Problem (customer's words):
Context (who, role, why now):
Pilot scope (users, duration, manual vs automated):
What changed (metric, method, date):
Objections surfaced:
What this proves / does not prove:
What comes next:

A case study that sits on an unlinked page does little. Salesforce's guide frames case studies as reusable across sales conversations, social posts, email, and proposals, precisely because they answer objections before those objections become roadblocks per Salesforce. Before launch, the highest-value placements are usually a sales follow-up email, a launch announcement, and a short version in your investor materials.

Reuse the same evidence at different lengths. Articulate's guide describes how a single customer story supports early research, supplier comparison, the internal business case, and the final decision, which means one well-documented pilot can seed a webpage, a one-page PDF, a few social posts, and a slide per Articulate. You do not need three formats written from scratch; you need one set of artifacts quoted accurately in three places.

Keep it current and keep it honest. When the product launches and real outcomes arrive, revisit the page, upgrade the labeled early numbers to measured ones, and note the change. That habit, of treating the case study as a living document rather than a one-off asset, is what turns early pilot evidence into a library that sales can trust. If your team needs help turning interviews and usage logs into a finished, publishable page, Quanta can build the site, the document, or the deck around the evidence you already have.