Asb Interview Goals

Goal Questions: Decide What Your Customer Interviews Must Answer

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 GOALS.md file that drives the rest of the interview process.

The mental model

You can't ask what you need to know

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.

Customers can tell you their life, not your product decisions

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.

Goals are step one of a five-step method

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

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.

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.

Vocabulary

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.

• 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

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

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)

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.

The drafter's posture

Be clear, not clever

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.

Restate references; never cite a bare token

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.

Say where this is going first

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.

No inputs, no draft

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,"