Milestone map
Milestone map
3 milestones
Identify and personally contact 50 target users
1–2 weeks (outreach + logging)
Write a list of 50 specific, named people who match your target user profile and have the problem you're solving right now. For each person, note how you know them (or how you'll reach them) and what specifically about their situation makes them a fit. Then contact all 50 — not with a pitch, but with a question about the problem you're solving. The goal is conversations, not demos.
Proof required
Submit your 50-person list (names optional if you prefer to anonymise — role/context is sufficient), the outreach message you used, and a log showing which contacts responded and what the response was (positive/neutral/negative).
What gets checked
- All 50 are specific people with context explaining why they fit — 'people who work in HR' is not a person.
- Outreach message asks about the problem, not about your product — it passes the test of 'could I send this before the product exists?'
- Response log is complete for all 50 contacts — not just the positives.
Common mistakes
- Contacting only people who already know you well — warm contacts are easiest but not representative of whether strangers will use it.
- Outreach message that mentions the product by name in the first line — it reads as a pitch and response rates collapse.
- Stopping the list at 20 people and extrapolating — 50 contacts is the minimum for a meaningful signal.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the founder which 5 contacts were the least obvious choices and why they were included — reveals whether the list was thought through.
- Ask what the response rate was and what they attribute it to — vague answers mean the outreach wasn't tracked systematically.
- Ask whether the outreach message could have been sent before the product was built — if not, it was a pitch, not a discovery message.
Onboard 10 users to the actual product
2–4 weeks (dependent on product readiness)
Convert at least 10 people from your outreach list (or referrals from them) into active users of your actual product — not a demo, not a waitlist, not a Figma prototype. For each user, document: how you onboarded them (personally walked them through it, or self-service), what they did in the first session, and what question or confusion they expressed. Onboard at least 3 of the 10 in person or on a live call.
Proof required
Submit onboarding notes for each of the 10 users (anonymised), evidence that each used the product (e.g. screenshots of their activity in your analytics or product dashboard), and a one-paragraph summary of the most common first-session confusion.
What gets checked
- Product usage evidence is from your analytics/database, not from user self-reporting — 'they said they used it' is not evidence.
- At least 3 of the 10 were onboarded live (call, in-person, or screen share) — this is how you catch UX problems that would kill silent self-service.
- First-session confusion paragraph names a specific UX moment, not a vague 'it was confusing' summary.
Common mistakes
- Counting demo account signups as users — a user is someone who encountered the product independently and did something with it.
- Skipping the live onboarding sessions because it's 'not scalable' — at 10 users, scalability is irrelevant; learning is the goal.
- Not documenting the confusion moments — these are the most valuable data in this milestone.
Resources
Foundationstart here
What a verifier looks for
- Ask the founder to describe what user 7 did in their first session — if they can't recall without notes, the documentation wasn't maintained.
- Ask which 3 were onboarded live and what they learned from those sessions that they wouldn't have learned from self-service onboarding.
- Verify analytics evidence exists for each user — screenshots from a real product dashboard, not a constructed table.
Retain 7 of 10 through second active session
2–3 weeks (tracking window post-onboarding)
Retention, not acquisition, is the signal that product-market fit is possible. Of your 10 initial users, track who returns for a second active session within 2 weeks of their first. Document what triggered their return (did you prompt them, did they come back on their own, or did they not return?). Write a one-page retention analysis covering which users returned, what they did in session 2, and your hypothesis for why 3 (or more) didn't come back.
Proof required
Submit session 2 analytics evidence for each returning user, a log showing which users returned organically vs. were prompted by you, and your one-page retention analysis with specific hypotheses for the non-returners.
What gets checked
- 7 of 10 reached session 2 — if fewer, the milestone is not met; document what happened and what changes before attempting again.
- Organic vs. prompted return is tracked — users who came back only when poked by the founder signal weak retention.
- Non-returner hypotheses are specific to each person's situation — 'they weren't a good fit' is not a hypothesis.
Common mistakes
- Prompting users who hadn't returned and counting the prompted session 2 as organic retention.
- Defining 'second session' as a response to a direct message from the founder rather than unprompted product usage.
- Retention analysis that only covers the returners — the non-returner analysis is the more important half.
Resources
Foundationstart here
What a verifier looks for
- Ask what the exact retention number was and how many of the returns were organic vs. founder-prompted.
- Ask what their hypothesis is for the specific user who most surprised them by not returning.
- Ask what one change they'd make to session 1 to improve session 2 retention — the answer reveals whether the analysis produced actionable insight.
Part of