Milestone map
Milestone map
4 milestones
Find one channel that works repeatably
2 weeks. Three runs of the same channel in 14 days. If you cannot run the same channel three times in two weeks, it is not a scalable channel — that is useful information.
From your launch data, pick the channel with most completions per hour of effort. Run it three more times in two weeks: new posts, same channel and audience. Track each run separately. If it keeps producing users, it's a distribution channel. If not, document why and try the next one.
Proof required
Share a table of the three runs: date, what you posted or sent, and where. Add completions produced and time taken. Write 200 words on whether the channel is repeatable. Say why one run beat another, and name the limiting factor.
What gets checked
- Three runs, each with a date and a completion count.
- The metric is core-action completions, not clicks or signups.
- The limiting factor is specific, like the number of active posters. 'It depends on the post' isn't.
Common mistakes
- Running three different channels. This milestone tests one channel's repeatability.
- Measuring clicks. 20 visitors who all complete beat 500 who bounce.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
Arena
What a verifier looks for
- Check the table has dates, channels and measured completion counts for all three runs.
- Ask to see the event tracking that proves these are completions, not visits.
- Ask them to predict a fourth run's result. A specific range shows they understand the channel.
You'll sign in first, then come straight back here.
Build one repeatable acquisition loop
5 weeks minimum: 1 week to document the process before starting, then 4 weeks running the system. The discipline of the schedule is the milestone — missing a week because 'I was busy' is a failure of the system, not an excuse.
Turn your best channel into a system that runs without daily effort. Write a process anyone could follow. Set a fixed schedule and a weekly check on results. Run it for four weeks at under 3 hours a week. Track the users it brings each week.
Proof required
Share the written process as a public or shareable page. Share a four-week log: week, hours spent, users gained, running total. Write 200 words on what you templated or automated to stay under 3 hours. Say whether it reduced effectiveness.
What gets checked
- A stranger could follow the process: where, when, which title format and first comment.
- The log shows real numbers, including zero weeks.
- Hours are under 3 in at least three of the four weeks.
Common mistakes
- Writing the process afterwards. It must exist before week 1, as the thing you follow.
- Counting feature work as acquisition hours. The 3-hour limit covers distribution only.
Powstik Guide
A written acquisition process and a four-week log.
Steps
- Write your best channel as steps anyone can follow.
- Set a weekly schedule.
- Log hours spent and users gained.
- Adjust one thing each week.
Template
Process link: | Week | Hours | Users gained | Change made | |------|-------|--------------|-------------|
What gets sent back
- Process only you could run.
- Fewer than four weeks.
- No numbers.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Can you follow the process without asking questions? If not, it isn't specific enough.
- Is the log dated week by week, or a summary written at the end?
- Ask them to walk through one week's hours. Unrecalled hours were estimated.
- Ask if a part-time contractor could run it today. If not, it's still personal.
You'll sign in first, then come straight back here.
Reach 500 users; interview word-of-mouth users
6–10 weeks from Milestone 2. If your repeatable channel produces 50 users per week, you reach 500 in 10 weeks. If it produces 10 per week, 50 weeks. The rate the channel produces tells you whether this outcome is achievable on this timeline — honest accounting is the milestone.
Reach 500 users who completed the core action. Record every source: your channel, word-of-mouth referrals, and new channels tested. Interview five users who arrived by word of mouth. Ask how they heard and why they tried it. This shows whether the product can grow organically.
Proof required
Share analytics with 500+ core-action completions, broken down by source. Share notes from five word-of-mouth interviews. Cover how they heard, why they tried it and what surprised them. Write 200 words on the channel versus word-of-mouth ratio. Say what it means for organic growth.
What gets checked
- 500+ completions with at least three distinct sources in the breakdown.
- Interview notes include the users' actual words. 'They heard from a friend' isn't a quote.
- The ratio is reported honestly, even if word of mouth is tiny.
Common mistakes
- Not tracking sources. Use UTM parameters or a signup question from the start.
- Skipping interviews. Word-of-mouth users found you unaided; learn exactly why.
Resources
Foundationstart here
Masteryfor the dedicated
What a verifier looks for
- Look for a source breakdown. If there's none, ask for the UTM or source report.
- Ask them to read out one interview quote that surprised them.
- Ask what share came from word of mouth, and what that says about product-market fit.
- Confirm the count is core-action completions, not signups or page views.
You'll sign in first, then come straight back here.
Reach 1,000 users and document changes
This milestone is met when it is met. The 1,000 user milestone takes as long as your acquisition channel requires. Do not fake it by counting users who did not complete the core action. An honest 800 is better than a dishonest 1,000.
Reach 1,000 users who completed the core action. Then publish a 500-word retrospective on what changed from user 1 to 1,000. Cover what you built unplanned and what you planned but didn't build. Add the use case that surprised you. Say what the product is really for versus what you thought.
Proof required
Share analytics with 1,000+ core-action completions and the retrospective's public URL. Write 150 words on the biggest thing you got wrong about users.
What gets checked
- 1,000+ completions of the same core-action event used throughout this path.
- The retrospective is at a public URL that loads without a login.
- The wrong belief is specific, with the evidence that disproved it.
Common mistakes
- Switching to registered users because completions are fewer. Keep the same metric.
- Writing the retrospective before user 1,000. The lessons come from the users.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask for the event name behind the 1,000. If it differs from Milestone 3, ask why.
- Check all four sections are present in the retrospective.
- Ask what the product is really for now. 'The same thing' means they haven't listened.
- The wrong belief needs evidence, not just 'fewer people wanted feature X'.
You'll sign in first, then come straight back here.
Part of