Validating Customers

Phase 3: Validating Customers

You are executing Phase 3 of the GTM Strategist methodology. This phase is about finding your persona empirically — not making things up. Everything at this stage is still an assumption until validated through real experiments with real people.

Philosophy: You don't "define" your customer — you discover them. Brainstormed personas are fiction. Validated archetypes are strategy.

Before You Start

1. Read my-gtm-context.md — load the user's product, market, ICP hypothesis, and traction context. If Section 3 (ICP) or Section 4 (Problem & Value) are empty, ask the user to fill those in first or complete Phase 1.

2. Check for prior phase outputs:

   • outputs/01-* — Phase 1 (GTM Foundations): OPE canvas, value prop, 90-day plan
   • outputs/02-* — Phase 2 (Collecting Intelligence): beachhead segments, interview insights, competitor analysis
   • If Phase 2 outputs exist, reference interview findings and beachhead segments heavily — they are the raw material for validation.
   • If Phase 2 outputs are missing, warn the user: "Phase 3 works best when you have interview data from Phase 2. You can proceed, but your assumption map will rely more on hypothesis than evidence. Consider completing collecting-intelligence first."

3. Check outputs/03-* for any existing Phase 3 work so you build on it rather than restart.

Tasks

Work through these one at a time. Present each deliverable, get feedback, then proceed to the next.

Task 1: Map Assumptions & Plan Experiments

Duration: 1-3 hours | Output: outputs/03-assumption-map.md

Everything you believe about your customer, problem, and solution is an assumption until tested. This task makes those assumptions explicit and prioritizes which to test first.

Assumption Mapping Framework:

Guide the user through these steps:

1. List all assumptions across four categories:

   • Customer: Who they are, where they are, what they care about
   • Problem: Severity, frequency, current workarounds, willingness to change
   • Solution: Whether your approach solves it, usability, feature priority
   • Business: Willingness to pay, price sensitivity, acquisition channels

2. Score each assumption on two axes:

   • Certainty (1-5): How much evidence do you have? (1 = pure guess, 5 = confirmed by data)
   • Impact (1-5): If this assumption is wrong, how badly does it hurt your GTM? (1 = minor, 5 = fatal)

3. Identify "Leap of Faith" assumptions: High impact + low certainty. These are the assumptions that could kill your GTM if wrong — and you have the least evidence for. These get tested first.

4. Design experiments for top 3-5 leap-of-faith assumptions. For each experiment, specify:

   • Hypothesis: "We believe [assumption] because [reason]."
   • Test: What you will do to validate (interview, landing page, ad test, prototype, etc.)
   • Success metric: What result would confirm or disconfirm the assumption?
   • Duration: How long the test runs.
   • Cost/effort: Resources required.

Output structure:

# Assumption Map

## All Assumptions
| # | Category | Assumption | Certainty (1-5) | Impact (1-5) | Priority |
|---|----------|-----------|-----------------|--------------|----------|

## Leap of Faith Assumptions
[Top assumptions with High Impact + Low Certainty]

## Experiment Plan
### Experiment 1: [Name]
- Hypothesis:
- Test method:
- Success metric:
- Duration:
- Cost/effort:
[Repeat for each experiment]

## Decision Log
[Left blank — user fills in as experiments conclude]

Reference Phase 2 interview insights to pre-populate certainty scores where evidence exists. Assumptions confirmed by 5+ interviews score higher certainty.

Task 2: Create & Launch MVI (Minimum Viable Idea)

Duration: 1-3 days | Output: outputs/03-mvi-plan.md

An MVI is NOT an MVP. It is the simplest possible way to bring your value proposition to life and test whether real people respond to it. The goal is to test the idea, not the product.

Guide the user to choose an MVI format:

For the chosen MVI, define:

1. Core value proposition being tested (one sentence)
2. Format and what the user needs to build
3. Target audience — who specifically will see this? (Pull from Phase 2 beachhead segments)
4. Distribution plan — how will you get it in front of 50-100 relevant people?
5. Success metrics:
   • Primary: Signup rate, response rate, or conversion %
   • Secondary: Quality of responses, questions asked, objections raised
6. Timeline: Day-by-day plan for creation and launch
7. What you will learn — which assumptions from Task 1 does this test?

Emphasize: The MVI must strategically attract the right potential customers, not just anyone. Volume without relevance is vanity.

Task 3: Alpha Testing with 10+ Prospects

Duration: 1-2 weeks | Output: outputs/03-alpha-test-results.md

Alpha testing means getting your MVI (or early prototype) in front of real prospects and collecting structured feedback. These should be people from your Phase 2 interviews who expressed interest.

Guide the user through:

1. Recruit alpha testers:

   • Revisit Phase 2 interviewees — who showed the most enthusiasm?
   • Aim for 10+ testers minimum (expect ~50% follow-through from invites)
   • Send a personal invitation, not a mass email. Reference their earlier conversation.

2. Prepare the alpha test:

   • Record a demo or walkthrough if the product isn't self-serve yet
   • Create a structured feedback form (not just "what do you think?")
   • Key questions to include:
     • "What problem does this solve for you?" (tests understanding)
     • "How are you solving this today?" (tests alternative awareness)
     • "Would you use this in your current workflow? Where?" (tests fit)
     • "What's missing before you'd pay for this?" (tests gap to WTP)
     • "Who else on your team would need this?" (tests DMU — feeds Task 7)
     • Rating: "How disappointed would you be if this didn't exist?" (Sean Ellis test)

3. Run the alpha:

   • Share the MVI/prototype with each tester
   • Follow up within 48 hours for feedback
   • Update testers on changes you make based on their input (IKEA effect: they helped build it, they are more likely to become your first customers)

4. Synthesize results:

   • Sean Ellis score: % who say "very disappointed" (target: >40%)
   • Common patterns in feedback
   • Segments within testers: who loved it vs. who was lukewarm?
   • Feature requests / gaps mentioned 3+ times
   • Updated assumption map (which experiments from Task 1 now have data?)

Output structure:

# Alpha Test Results

## Test Setup
- MVI tested: [what you showed]
- Testers invited: [N]
- Testers who completed: [N]
- Test period: [dates]

## Sean Ellis Score
- Very disappointed: X%
- Somewhat disappointed: X%
- Not disappointed: X%

## Key Findings
[Patterns, surprises, segments]

## Feedback Themes
| Theme | Frequency | Representative Quote |
|-------|-----------|---------------------|

## Updated Assumptions
[Which assumptions from 03-assumption-map.md are now confirmed/disconfirmed?]

## Next Steps
[What to change, who to test next]

Task 4: Community Launch (5-10 Communities)

Duration: 1-2 weeks | Output: outputs/03-community-launch-plan.md

Community launches test your idea with strangers — people who have no relationship with you and no reason to be polite. This is where real market signal lives.

Guide the user through:

1. Identify 5-10 relevant communities:

   • Where does your target persona already hang out?
   • Types: Reddit subreddits, Slack/Discord groups, Facebook groups, LinkedIn groups, indie hacker communities, industry forums, Skool communities, Hacker News (if technical)
   • Pull from Phase 2 research — "where they hang out online" from interview data

2. Community warm-up (DO NOT SKIP):

   • Join each community 1-2 weeks before posting about your product
   • Observe: What topics get engagement? What tone works? What gets removed?
   • Do value commenting: answer questions, share insights, be genuinely helpful
   • Build "social karma" — earn the right to share your thing
   • This is NOT optional. Cold-posting your product in communities is spam and gets removed.

3. Craft the post for each community:

   • Adapt tone and format to each community's norms
   • Lead with the PROBLEM, not your product
   • Frame it as: "I built this because [problem]. Would love feedback from people who deal with [pain]."
   • Include a clear, low-friction call to action (try it free, sign up for beta, watch the demo)
   • Never use marketing language in communities. Be a person, not a brand.

4. Track results per community:

5. Analyze which communities responded best — this tells you where your future customers live and how they talk about the problem.