Grow Your Product to 1,000 Users

Proof required

Share a table (spreadsheet or markdown) showing the three channel runs: date, what you posted or sent, where, how many core-action completions it produced, and how long it took. Write 200 words on whether this channel is repeatable and why — what made one run work better than another, and what is the limiting factor (audience size, post quality, timing, or something else)?

What gets checked

• Three separate runs are documented with dates and results — not 'I posted three times' but a table showing each run's specific output with completion counts
• Core-action completions are the metric, not clicks or signups — same standard as Milestone 3 of entrepreneur-launch-product
• The repeatability assessment names a specific limiting factor — 'the subreddit has 50,000 members but only 200 active daily posters' is specific; 'it depends on the post' is not

Common mistakes

• Running three different channels and calling it 'testing the channel' — this milestone is about repeatability of ONE channel; switching channels every run tells you nothing about whether any channel works consistently
• Measuring clicks instead of completions — a channel that sends 500 visitors who all bounce is worse than a channel that sends 20 visitors who all complete the core action

Resources

What a verifier looks for

• Ask for the table showing three runs. Are the dates, channels, and completion counts all present? If the table has only one row or has estimates instead of measured numbers, M1 is incomplete.
• Check the metric. Are completions of the core action being tracked, or clicks to the landing page? Ask the submitter to show the event tracking that proves these are completions, not visits.
• Ask: 'If you ran this channel a fourth time tomorrow, what result would you predict and why?' A founder who can give a specific prediction with a range has a model of how the channel works. A founder who says 'I don't know' has not yet understood what drives the results.

Proof required

Share the documented acquisition process (a markdown file or Notion page — must be public or shareable). Share a four-week log showing: week number, hours spent, users acquired, cumulative total. Write 200 words on what you automated or templated to get below 3 hours per week and what the quality tradeoff was — did systematising reduce effectiveness?

What gets checked

• Documented process is specific enough that a stranger could follow it — not 'post on Reddit' but 'post in r/[specific] on Tuesday at 9am EST with title format [template] and first comment containing [specific content]'
• Four-week log shows real numbers — if week 3 produced 0 users, the log shows 0, not an estimate or an omission
• Hours-per-week is below 3 in at least three of the four weeks — if it takes 8 hours every week, the process is not systematised

Common mistakes

• Documenting the process after running it rather than before — the documentation must exist before week 1 begins; it is the thing you follow, not the thing you write afterward
• Counting hours spent on features as 'acquisition hours' — the 3-hour limit is for distribution activity only; building features while running the channel does not count toward the limit

Resources

What a verifier looks for

• Ask for the acquisition process document. Can you follow it without asking the submitter any questions? If you need to ask 'what do you mean by post,' the document is not specific enough.
• Check the four-week log. Is it a real log with dated entries, or a summary written at the end? A real log has weekly entries that were written as each week completed.
• Verify the hours. Ask the submitter to walk through what they did in a specific week that took less than 3 hours. If they cannot recall, the hours were not tracked — they were estimated.
• Ask: 'Could you hand this acquisition process to a part-time contractor today and have them run it without you?' If yes, the system exists. If no, it is still personal, not systematised.

Proof required

Share your analytics showing 500+ core-action completions with a breakdown by acquisition source. Share notes from five word-of-mouth user interviews — how they heard, what made them try it, what they expected vs what they got. Write 200 words on the ratio of channel-driven users to word-of-mouth users and what it tells you about whether the product has organic growth potential.

What gets checked

• Analytics show 500+ core-action completions with source attribution — not 500 total users with no breakdown; the channel breakdown must show at least three distinct sources
• Five interview notes contain specific quotes from real users — not paraphrases; the actual words the user used matter; 'they heard from a friend' is not a quote
• Word-of-mouth ratio analysis is honest — if 498 came from the channel and 2 from word-of-mouth, that is reported as a low organic growth signal, not hidden

Common mistakes

• Not tracking acquisition source — if you cannot tell where each user came from, you cannot know which channel to double down on; UTM parameters or a 'how did you hear about us' question on signup are required from the start
• Skipping the user interviews because 'I already know why people use it' — word-of-mouth users are your most valuable users; they found you without your help; understanding exactly why they tried it is irreplaceable signal

Resources

What a verifier looks for

• Check the analytics breakdown. Is there a channel attribution column? If the analytics show only total users with no source breakdown, ask the submitter to show the UTM report or acquisition source data.
• Read the five interview notes. Do they contain direct quotes? Ask the submitter to read one quote aloud that surprised them. A founder who cannot point to a surprising quote did not listen carefully enough in the interviews.
• Ask: 'What percentage of your users came from word-of-mouth?' Then ask: 'What does that tell you about whether you have product-market fit?' A founder who understands that high organic growth is the PMF signal has extracted the right lesson from this milestone.
• Verify the core-action completion count, not registered users. Ask to see the event that counts as a completion in the analytics. If it is a page view or a signup, not a core action, the 500 number is overstated.

Proof required

Share your analytics showing 1,000+ core-action completions. Share the public URL of your 500-word retrospective. Write 150 words on the single biggest thing you got wrong about your users before you had 1,000 of them.

What gets checked

• Analytics show 1,000+ core-action completions — not 1,000 signups, not 1,000 page views; the core action as defined in entrepreneur-launch-product Milestone 1, same event as used throughout this path
• Retrospective is published publicly at a URL that works without a login — same standard as entrepreneur-launch-product Milestone 5
• The 'what I got wrong' reflection names a specific belief held before launch that users proved incorrect, with the specific evidence that proved it wrong

Common mistakes

• Counting total registered users instead of core-action completions — every milestone in this path has used the same metric; do not change it at the end because the number is smaller
• Writing the retrospective before reaching 1,000 — the document must be written after the 1,000th user completes the core action; the lessons come from the users, not from the plan

Resources

What a verifier looks for

• Check the analytics. Is the 1,000 count the core-action completion event or total users? Ask the submitter to show the event name in the analytics. If it is a different metric than the one used in Milestone 3, ask why it changed.
• Read the retrospective. Does it contain the four required sections: what you built that you did not plan, what you planned but did not build, a surprising use case, and what the product is actually for? A retrospective that only describes what happened without these four elements is incomplete.
• Ask: 'What is your product actually for, and how is that different from what you thought it was for on launch day?' The answer is the core of the retrospective. If the answer is 'the same thing,' they have not listened to their users.
• Check the 'what I got wrong' reflection. Does it name a specific belief with specific evidence that disproved it? 'I thought more people would want feature X but they didn't' is not specific. 'I believed the primary user was a student, but 70% of completions came from working professionals over 35, which I discovered when I looked at the signup email domains' is specific.