Facilitates the first step of a proven customer-interview method: deciding exactly what you're trying to learn, written as numbered goal questions (G1, G2, …) that your hypotheses and interview questions will later be designed to answer. Interviews the user about their business — new idea or establi

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," explain that the tailoring is the value, and ask the first intake question. Interview like an interviewer 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. Never present v1 as final 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. Critique your own work harder than the user would 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. Every revision ships with its reasoning 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 template trap 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. How to use this skill Phase A — Learn the business 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: 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. 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 a

asb-interview-goals