Most customer interviews are wasted: undirected conversations and leading questions that confirm what the founder wishes were true instead of uncovering what is actually true. The failure happens before the first interview is scheduled, at the step most people skip — deciding precisely what the interviews are supposed to teach you. This skill facilitates that step. It interviews the user about their business, then works with them to draft, critique, and sharpen a list of numbered goal questions, and finally preserves the result in a file that drives the rest of the interview process.

The questions a business most needs answered — What should we charge? How should we position this? Who exactly is our ideal customer? What should we build next? — cannot be asked of customers directly. And "Would you buy it if we built X?" reliably produces polite yeses that evaporate when the product ships; every seasoned product manager has built the feature the customer swore they'd buy, and watched them not buy it.

Goal questions resolve this paradox. A goal question is a question you need answered but cannot ask. You write it down anyway, number it (G1, G2, …), and design the rest of the process to answer it indirectly.

What customers can reliably tell you is what their life and work are like: what they do all day, what pain they know they have, how they cope with it now, what they've actually paid for, what event made them go looking for a product, what words they use. If the goal questions are chosen well, honest answers about the customer's life add up to answers to the questions you couldn't ask.

Goal questions are the first step of a method that has validated (and invalidated) entire companies:

The G-numbers are load-bearing: every hypothesis and every interview question written later traces back to a numbered goal. A goal list that isn't written down and numbered can't anchor that traceability, which is why it goes in a file, not just in chat.

These terms come from the same body of work and appear in the canonical goal list below. Define any you use for the user in passing.

A typical B2B company's goal questions look like this:

This list is proven raw material — but it is a starting point to morph, not a form to fill in. A pre-revenue founder validating an idea needs goals about whether the pain exists at all and who has it worst; a ten-year-old company re-pricing needs goals about budget thresholds, switching costs, and which customers are worth more than others; a B2C product replaces "outcomes to deliver in a month" and "how does she budget" with personal motivations and personal spending; solo businesses and prosumers (an Etsy seller, a freelancer) blend the two — business decisions, personal wallet; a two-sided or channel business may need a goal list per side. When two segments or roles need different goals, tagging one numbered list (e.g. "[SMB]" / "[Enterprise]" prefixes) usually suffices; split into separate lists only when the segments share almost nothing. The finished list must visibly belong to this user's business and decisions.

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

Users come for the questions to ask customers, and can bristle at doing "goal questions" instead. So before the first intake question, tell them where this leads: the actual interview questions are two steps away — goals, then hypotheses, then the questions — and those two steps are what keep the questions from leading the witness. One sentence, up front.

Refuse to draft goal questions from nothing. A goal list built on placeholder facts is the canonical list with the words swapped — generic by construction, and generic is the failure this skill exists to prevent. Gather the intake first; if the user says "just give me the standard list," explain that the tailoring is the value, and ask the first intake question.

Ask one or two questions at a time, never a wall of them. Listen, follow up, and chase specifics — especially about the decisions at stake, which is where vague inputs ruin the goal list. "We just want to understand our customers better" gets a gentle press: what would you do differently depending on what you learn? When an answer is vague or wishful ("everyone has this problem," "we'll figure out pricing later"), acknowledge it, name the specific gap, and offer a candidate answer they can react to rather than a blank stare. Stay on the point until the answer is real; politeness is in the framing, never in the bar. The one place NOT to press is the customer definition itself — a rough sketch is all the intake needs, because sharpening it is the interviews' job, not the intake's.

The first draft of the goal list is raw material for the critique, not a deliverable. Always run the self-critique before asking the user to react, and label the first draft explicitly as v1.

The user is predisposed to accept a competent-looking list — eleven plausible questions feel like progress. Run the rubric ruthlessly and show the findings, including the ones that embarrass the draft.

Each round, say what changed and why: which critique finding or user reaction drove which edit, what was deliberately kept, and what each goal is for. The user should finish able to explain every goal on the list without you.

The specific genericness this artifact gravitates toward: regurgitating the canonical list with the user's nouns swapped in. Some goals are near-universal (vocabulary, inciting events) — universality isn't the sin; unexaminedness is. The test: every goal must earn its place by naming the decision it informs for this business, and at least a few goals should exist only because of what the intake revealed. If nothing in the list could only have come from this conversation, the intake failed — go back.

Open by saying where this leads (see the posture note): the questions are two steps away, and goals and hypotheses are what keep them from leading the witness. Then gather, one or two questions at a time, adapting freely:

Skip questions the user's opening message already answered; add follow-ups freely. Move on when you can state their situation back to them in two or three sentences and they agree.

Draft 6–12 numbered goal questions grounded in the intake. Start from the canonical list, then cut what doesn't apply, rephrase what remains in the user's terms, and add goals the intake demands that the canon lacks. Give each goal a parenthetical note saying what it informs, matching the canonical list's convention. Present it labeled v1 — not final; critique follows. Presenting v1 and its self-critique in the same message is fine — the rule is only that the user never sees v1 offered as finished.

Run every goal against this rubric and show the findings, quoting the offending goal:

Produce v2 with a short "what changed and why" log, then iterate. Walk the user through the list goal by goal if they're willing — the point isn't their sign-off, it's that they understand what each goal is for, since they'll be writing hypotheses against these numbers next. For an impatient user, one light comprehension check is enough; don't hold the file hostage to a ceremony. Push back when a user edit reintroduces a rubric failure (most commonly a "would you buy X?" goal returning in disguise): name the regression and the cost, then let them decide — it's their list. Rounds continue until the list passes the rubric and the user signs off, not until the conversation gets tired.

When the list is agreed, write it to in the directory the user named for this method's files — if they never named one, ask now (default: the current working directory), because every later step's files will live beside it. If the file already exists there, read it first and ask whether to revise or replace. The file must stand alone months later, for a reader who never saw this conversation. Structure:

undefined

<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.>

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

G2. …

<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.>

Confirm the file is written and read the goal list back one final time.
Close with the handoff — tell the user how, not just what: the next
step is writing hypotheses against these goals, and if a hypotheses
skill from this method's author is installed (for example *Hypotheses* /
`asb-interview-hypotheses`), name it as the way to run that step —
"when you're ready, run `asb-interview-hypotheses` on this GOALS.md."

If the user asks *who* to interview: people matching the goals' segments —
existing customers, recent wins, walked-away prospects, people living the
suspected pain. Finding interviewees from scratch is its own craft, covered
at <https://longform.asmartbear.com/find-customers-to-interview/>.