First-Pass Analysis

Write down what you expect before you code anything, then let the data earn each theme by recurrence and by surviving the cases that do not fit.

Practice, not research: the coding moves come from established qualitative methods (Braun & Clarke, 2006; Corbin & Strauss, 2008) and negative case analysis from Lincoln & Guba (1985); these are codified craft, not experimentally validated tools. The caution on significance tests follows the ASA statement (Wasserstein & Lazar, 2016). The limit of three themes is a rule of thumb.

Use it when:

• Your interviews, survey answers or records are in, and you need to see what they say before anyone writes a slide.
• A colleague already "knows" the answer, and you want a page that shows whether the data agrees.
• You are about to grade evidence or write insights and need a first, honest map of the material.

Skip it when:

• You have not collected anything yet: plan the work in 2.5 Simple Study Design Sheet and capture it with 2.7 Data Capture Templates.
• The themes are stable and you need to judge how far to trust them: go to 2.9 Evidence Quality Judgment.

A first pass gives you discipline, not proof. The coding steps borrow from two qualitative traditions, thematic analysis and grounded theory's structured coding (Braun and Clarke, 2006; Corbin and Strauss, 2008). Both are widely taught rather than experimentally tested, and both insist that a theme must recur across sources; one vivid quote is not enough. With numbers, simple counts and averages are safe. The risk sits in the jump to significance tests, which people often read as saying more than they do; the statisticians' own association issued a statement to correct this (Wasserstein and Lazar, 2016).

Under both lies a test borrowed from Popper (1935): trust a pattern only as far as you have hunted for its exceptions. Qualitative researchers call that hunt negative case analysis (Lincoln and Guba, 1985). So Step 1 records your expectations before coding, Step 2 counts how many sources carry each theme, Step 4 looks for the cases that break it, and Step 5 checks the result against the hypotheses you wrote in 2.3 before the data existed.

List what you collected and what is wrong with it. Then, before you code a single line, write what you expect the data to say.

Strong answer: "Sixteen phone interviews, eight with cafes that stopped ordering and eight with cafes that still order, weeks 1 to 3. Two of the former cafes gave short answers. I expect price to come up most." Not: "Lots of good interviews."

What I expect to find, written before coding:

What already surprised me while collecting:

Illustrative example: the business, the roles and all numbers are made up.

The Gothenburg bakery from 2.1 has finished its study of small cafes that stop ordering.

Step 1: Sixteen interviews (eight former, eight current cafes) and two years of order history. Two former cafes gave short answers. The sales lead expected price to dominate.

Step 2: Three themes. Waste at the minimum order: six of eight former cafes, one of eight current. Wanting small daily amounts: five former, two current. Price: one former cafe, and only when asked.

Step 3: Cafes whose orders sat at the minimum stopped far more often than cafes that ordered above it. The sales lead notes that the smallest cafes may simply be more fragile.

Step 4: One former cafe never mentioned waste; the owner had sold the business. Kept, and logged as a rival explanation.

Step 5: Waste hypothesis supported. Price hypothesis unclear rather than rejected: the interviews did not test it directly. The expectation from Step 1 did not survive, which the sales lead writes at the top of the page before the owner reads it.