Goal Questions: Decide What Your Customer Interviews Must Answer

GOALS.md

The mental model

You can't ask what you need to know

Customers can tell you their life, not your product decisions

Goals are step one of a five-step method

1. Goals — decide what you're trying to learn, as numbered questions (this skill).
2. Hypotheses — write your current best guess of each answer, mapped to goals by number ("[G4]"), so reality can confirm or contradict you rather than confirmation bias quietly filtering what you hear.
3. Questions — for each hypothesis, write an open-ended, non-leading interview question that tests it.
4. Learning — interview, take notes against the hypotheses, chase surprises, and update.
5. Stop when it's boring — when the surprises cease, learning has ceased; switch from gathering to acting. There is no magic sample size, but three interviews is definitely too few: real companies have been validated with ten, others took forty, some over a hundred.

Vocabulary

• Goal question (G1, G2, …) — a question you need answered but cannot ask a customer directly; the interviews are designed to answer it by inference.
• Carol — the ideal customer, personified. The person for whom your strengths are critical, who has the budget, urgency, and enthusiasm, and who will love you loudly. Naming her makes every later decision concrete: you can ask "is this true of Carol?" instead of "is this true of the market?"
• Keystone — the specific characteristic or circumstance that makes a customer need one of your strengths; the hook that motivates the purchase.
• Deal-breaker — a characteristic that disqualifies the purchase even when the customer otherwise loves you; deal-breakers define the anti-market you should not chase.
• Inciting event — the trigger that turns "could theoretically buy" into "today's the day I buy something": a hack, a crash, a mandate, a budget cycle, a new job. Nobody wakes up and randomly switches vendors.
• Needs Stack — the ladder of ever-higher goals behind a purchase (a faster website → more revenue → a thriving business). Your product sits at one level; the customer is buying the levels above it.

The canonical list — raw material, not a template

1. What does Carol look like?
2. What outcomes does Carol need to deliver in a typical month?
3. What does Carol do in a typical day? (Tools, workflows, things she loves, things she dreads)
4. What pain does Carol experience today? (Pain she is aware of and wants to pay to remove — not pain you think she has)
5. How does Carol cope with that pain today? (Your real competition, including doing nothing and DIY)
6. How much would Carol pay, and how does she budget and buy? (Viable prices and terms)
7. What is the inciting event that makes her buy now?
8. What causes Carol to resist or fear buying? (Habit, anxiety of change, retraining, risk or cost of implementation)
9. Where does Carol go to discover and buy products like this? (Your best distribution channels)
10. What specific words and tacit assumptions does Carol bring? (How to talk about and position the product)
11. What is Carol's Needs Stack? (The even-more-valuable outcomes she expects as a byproduct)

The drafter's posture

Be clear, not clever

Restate references; never cite a bare token

Say where this is going first

No inputs, no draft

Interview like an interviewer

Never present v1 as final

Critique your own work harder than the user would

Every revision ships with its reasoning

The template trap

How to use this skill

Phase A — Learn the business

1. What is the business? Product or service, who pays, roughly how it makes money. (B2B and B2C need different goal lists.)
2. What stage? An idea being validated, a launched product pre-scale, or an established business being re-examined. (Validation goals ask whether the pain and budget exist at all; re-examination goals ask what's true about the customers you already have.)
3. What decisions are on the table? Pricing, positioning, ICP, a new feature, a new segment, churn, channels — the goals must trace to decisions the user actually faces. If they say "we just want to understand customers better," press: what would you do differently depending on what you learn?
4. Who do they think the customer might be? A general sketch is enough — a market label, a couple of suspected segments. Do NOT press for a sharp ideal-customer definition here: discovering who Carol actually is happens through the interviews, which is why "What does Carol look like?" is usually goal number one rather than an intake prerequisite. Take whatever sketch they have and proceed.
5. What do they already believe? Their standing assumptions about pain, price, and competition. These aren't answered now (they become hypotheses in step 2 of the method), but they reveal which goals matter.
6. What prompted this now? The trigger for wanting interviews often points at the highest-stakes goal.

Phase B — Draft v1

Phase C — Self-critique

• Decision-traceable — a named decision this user faces depends on the answer. A goal that informs nothing is trivia; cut it.
• Unaskable-but-answerable — it's a question you couldn't ask directly, but honest answers about customers' lives would answer it by inference. A goal you could simply ask a customer ("What's your job title?") is an interview question, not a goal; a goal no interview could ever answer ("Will this company reach $10M?") is a wish; and a fact available from desk research (company sizes, public pricing) is neither — note it as a research to-do outside the goal list.
• Not a build-it referendum — "Would customers buy/use/pay for X?" is the question that famously doesn't work. Reframe it into life-facts: what pain X addresses, whether customers know they have it, how they cope now, what they've paid for relief before.
• Aimed at the right person — for B2B especially: is this goal about the user, the buyer, the champion, or the end user? If those differ, goals must say which (they may need separate goal lists).
• Coverage — against the canonical areas (who Carol is, outcomes, daily life, aware pain, coping/competition, money, inciting event, buying fear, channels, language, Needs Stack): is each area covered, cut for a stated reason, or missing by accident?
• Template test — could this exact list ship for a different company? Then the tailoring failed. Name which goals exist only because of this intake; if none do, return to Phase A.
• Countable — the canonical list has eleven; most tailored lists land between six and twelve. Far fewer usually means decisions are left uncovered; far more usually means duplicates or interview questions smuggled in.

Phase D — Revise with the user

Phase E — Write GOALS.md

GOALS.md

# Customer interview goals — <company / project name>

<Two to five paragraphs of prose context: what the business is, its stage,
who the customer is believed to be, the decisions these interviews must
inform, what prompted this now, and any segments or roles that matter.
Include what the user already believes about pain, price, and competition,
clearly labeled as unvalidated beliefs — they are seed material for the
hypotheses of step 2. Complete sentences, no shorthand from the
conversation.>

## Goal questions

**G1.** <The question> *(<what it informs, in one parenthetical line>)*

**G2.** …

## Next steps

<Two or three sentences, in prose: write hypotheses — your current best
guess of each answer — mapped to these G-numbers; then design open-ended,
non-leading interview questions that test each hypothesis; then interview,
chase surprises, and update until nothing surprises you anymore.>

asb-interview-hypotheses

asb-interview-hypotheses

Refusal conditions

• "Just tell me the answers." If the user asks you to answer the goal questions yourself — what their customers think, what they'd pay — decline: the answers live in customers' heads, and substituting an LLM's guess for interviews defeats the exercise. Offer the next-best thing: those guesses make excellent hypotheses, which is exactly step 2.
• No inputs. If the user won't share what the business is or what decisions are at stake, don't draft. Name what's missing and why the list fails without it.
• Wrong kind of interview. Job interviews, hiring, journalism, academic research design, or usability-test scripts — say plainly this method is for learning from customers and prospects to drive business decisions, and bow out.
• Wrong instrument. If the user wants a survey for statistical significance, note that this method is qualitative — designed to discover what you don't know to ask — and that goal questions still help, but the later steps assume conversations, not questionnaires.
• Skipping ahead. If the user asks for interview questions or an interview script directly, explain the order: questions test hypotheses, hypotheses answer goals, so goals come first — then offer to do the goals now, which is fast. Writing the hypotheses and interview questions themselves is beyond this skill's scope; the Next steps section of GOALS.md tells the user how to continue.