name: v1-learning-from-customers description: Use when planning customer discovery, auditing customer interview questions, synthesizing customer conversation notes, checking whether demand evidence is real, or applying Jobs-to-Be-Done discovery. Triggers on "customer discovery", "customer interviews", "talk to customers", "mom test", "is this real demand", "jobs to be done". allowed-tools: - Bash - Read - Grep - Glob - WebFetch - WebSearch
Learning From Customers
Plan, audit, and synthesize customer conversations so product decisions rest on behavior, context, and commitments instead of compliments, opinions, or imagined futures.
Default mode is advisory. Do not contact customers, send messages, schedule meetings, or mutate CRM/research systems unless the user explicitly asks.
Quick Start
For a product idea, discovery plan, interview guide, meeting notes, transcript, or pile of customer quotes:
- Identify the product decision the research must inform.
- Define the customer slice narrowly enough that patterns can repeat.
- Write or audit the three most important questions for that slice.
- Convert bad questions into past-specific questions about real behavior, current workarounds, costs, constraints, and buying process.
- Classify evidence as fact, commitment, workflow, pain, budget/process signal, idea, compliment, or fluff.
- Decide the next action: keep learning, narrow the segment, ask for advancement, prototype, sell, or stop.
Input Modes
Choose one mode from the user's request:
| Mode | Use When | Output |
|---|---|---|
| Plan conversations | The user has an idea, segment, or open research question | Customer-learning plan and conversation guide |
| Audit questions | The user has drafted questions or a survey/interview script | Bad-question findings and rewritten questions |
| Synthesize notes | The user has notes, transcripts, call summaries, or quotes | Evidence synthesis and next decision |
| Assess demand | The user asks whether evidence proves demand | Demand-quality review and gaps |
| Create job spec | The user needs Jobs-to-Be-Done framing | Job spec with progress, circumstance, competitors, anxieties, and success signals |
If the request lacks the artifact needed for the selected mode, state the missing artifact and provide the smallest useful next step.
Workflow
1. Identify The Decision
Start with the decision the conversations should change:
- Is this problem worth solving?
- Which customer segment has the strongest pull?
- What current workaround, cost, or frustration exists?
- What must a new product replace, reduce, or beat?
- Is the team ready to prototype, sell, or stop?
Do not run generic discovery. Name the decision before writing questions or interpreting notes.
2. Slice The Customer
Define a narrow customer slice:
| Field | Questions |
|---|---|
| Role | Who experiences the problem directly? |
| Trigger | What event makes the problem show up? |
| Current behavior | What do they do today? |
| Context | Device, workflow, organization, budget, permissions, or environment |
| Stakes | What happens if the problem remains unsolved? |
| Access | How can conversations with this slice be found? |
If evidence is inconsistent, first check whether the team is mixing several customer slices. One conversation each with many different customer types is not the same as many conversations with one type.
3. Write The Three Big Questions
Choose the three highest-value unknowns for this customer slice.
Good big questions usually concern:
- The last time the problem happened.
- The current workaround and its cost.
- Who else is involved in the workflow or purchase.
- What has already been tried and abandoned.
- What would need to be fired before a new solution could be hired.
- The functional, emotional, and social progress the customer is trying to make.
Do not ask every participant the same script if reliable evidence already exists. Keep filling the picture from the highest-uncertainty edges.
4. Audit Questions
Flag and rewrite bad questions before the conversation.
| Bad Question Type | Why It Fails | Rewrite Pattern |
|---|---|---|
| Opinion | Produces politeness or taste, not evidence | Ask about the last real instance |
| Hypothetical | Future behavior is over-optimistic | Ask what happened last time |
| Leading | Reveals the desired answer | Remove the pitch and ask about current life |
| Feature request | Turns customers into product designers | Ask what problem the idea would solve |
| Price fantasy | Treats invented willingness as budget evidence | Ask about existing spend, approval path, or replacement cost |
| Generic habit | Produces "usually" and "always" | Ask for a concrete walkthrough |
Keep the conversation about the customer's life and workflow until the learning decision requires showing the idea or product.
5. Run The Conversation
Use a light guide rather than a rigid script:
- Set context briefly without pitching the solution.
- Ask about the customer's current workflow, last occurrence, and workaround.
- Follow concrete nouns, costs, delays, approvals, and repeated frustrations.
- Deflect compliments by asking for specifics behind them.
- Anchor fluff by asking when it last happened and what they did.
- Dig beneath ideas by asking what problem they would solve and how the customer handles it now.
- End by asking for the next useful person, artifact, or concrete advancement.
Talk less as the conversation improves. The more the agent or interviewer explains, the weaker the evidence becomes.
6. Capture Evidence
Separate what was observed from what was inferred.
| Evidence Type | Counts As | Does Not Count As |
|---|---|---|
| Fact | Past behavior, current workflow, actual spend, named tool, concrete event | General preference |
| Pain | Repeated cost, delay, risk, embarrassment, lost money, wasted time | Mild annoyance without action |
| Workaround | Spreadsheet, manual process, hired service, internal tool, habit | "We should probably fix this" |
| Commitment | Time, money, intro, pilot, data, procurement step, scheduled next meeting | Compliment or vague enthusiasm |
| Job signal | Desired progress in a specific circumstance with functional, emotional, and social dimensions | Demographic label alone |
| Bad data | Compliment, future promise, generic claim, unsupported idea | Evidence strong enough to change a decision |
When evidence is thin, say so. Do not inflate friendly conversations into validation.
7. Build A Job Spec When Useful
Use Jobs-to-Be-Done framing when the product decision depends on what customers are trying to accomplish rather than what feature they requested.
## Job Spec
Customer slice:
Triggering circumstance:
Desired progress:
Functional dimensions:
Emotional dimensions:
Social dimensions:
Current competitors / workarounds:
What must be fired:
Obstacles and anxieties:
Tradeoffs accepted:
Purchase experience needed:
Use experience needed:
Little Hire signals:
Success metrics:
Treat competitors broadly: products, services, spreadsheets, people, doing nothing, delaying, or cobbled-together workflows can all compete for the job.
8. Ask For Commitment Or Advancement
Once enough learning exists to show an idea, prototype, or offer, look for advancement:
- Schedule a concrete next meeting with the right person.
- Get an intro to a buyer, user, expert, or adjacent segment.
- Ask for time, data, pilot access, procurement steps, budget owner, or payment.
- Ask what would block adoption and who would need to approve.
If the customer remains friendly but never advances, classify the lead as unvalidated. A polite ongoing conversation is not demand.
9. Synthesize And Decide
End with a decision, not a pile of quotes.
Decision options:
- Keep learning: the segment is plausible, but evidence is incomplete.
- Narrow the slice: signals conflict because the customer group is too broad.
- Prototype: the problem and workflow are real, but the solution is untested.
- Sell or pilot: commitments show urgency and adoption path.
- Stop: no meaningful pain, no workaround, no budget/process, or no repeated pattern.
State what evidence would change the recommendation.
Output Formats
Conversation Plan
## Customer Learning Plan
Decision:
Customer slice:
Top 3 questions:
## Conversation Guide
| Question | What It Tests | Bad Data To Watch For | Follow-Up |
| --- | --- | --- | --- |
## Evidence To Capture
## Advancement Ask
## Stop / Continue Gate
Question Audit
## Question Audit
| Question | Finding | Risk | Rewrite |
| --- | --- | --- | --- |
## Missing Questions
## Best 3 Questions
Notes Synthesis
## Customer Evidence Synthesis
Decision:
Customer slice:
Verdict:
## Evidence
| Claim | Evidence | Type | Strength | Notes |
| --- | --- | --- | --- | --- |
## Bad Data
## Job Spec
## Next Action
Evidence strength:
- Strong: repeated behavior, costly workaround, real spend, or concrete commitment.
- Medium: credible past behavior from a fitting customer slice.
- Weak: opinion, unverified claim, noncommittal pain, or single anecdote.
- Bad data: compliment, hypothetical, generic future promise, or unsupported idea.
Anti-Patterns
- Asking whether the idea is good.
- Asking what customers would do in the future.
- Treating compliments as validation.
- Letting feature requests become requirements without finding the underlying problem.
- Interviewing a broad market and expecting coherent patterns.
- Pitching before learning the current workflow.
- Keeping customer learning in one person's head.
- Reporting quotes without separating observation, inference, and team opinion.
Chaining
- Use
v1-interview-mefirst when the user needs to clarify the product idea or learning decision. - Use
v1-testing-prototypesafter a prototype exists and the team needs observed task/value evidence. - Use
v1-prdafter customer evidence is strong enough to write build requirements. - Use
v1-strategy-reviewwhen customer learning changes the wedge, scope, or product direction.
When Not To Use This Skill
- Do not use for general feature specification once demand is already clear; use
v1-prd. - Do not use for live prototype-test planning or synthesis; use
v1-testing-prototypes. - Do not use for broad strategy critique unless the immediate question is customer evidence quality; use
v1-strategy-review. - Do not use for operational bottleneck or throughput diagnosis; use
v1-diagnosing-constraints.
Examples
Bad question rewrite
Input: "Would you pay for a dashboard that automates this?"
Output: Ask when the workflow last happened, what they used, how long it took, who cared about the output, and what budget or approval path existing tools go through.
Weak evidence
Input: "Everyone loved the idea and said they would use it."
Output: Classify as bad data unless notes include past behavior, current workaround, cost, budget owner, or concrete next step.
Segment problem
Input: Ten conversations produce ten unrelated requested features.
Output: Check whether the team is mixing several customer slices. Narrow by trigger, role, workflow, or current workaround before drawing product conclusions.