Ship a Product from 0 to 1 as PM

Proof required

Submit: (1) user research evidence: at least 5 user interviews or conversations with documented key insights — date, participant description, 2–3 specific verbatim quotes per participant, and the core insight extracted; (2) a product spec of at least 500 words covering: problem statement with evidence, proposed solution, success metrics, scope (in/out of scope), and engineering requirements; (3) evidence of engineering alignment — a written reply from an engineering team member confirming they have reviewed and will build this spec, or meeting notes documenting the engineering team's commitment.

What gets checked

• User research evidence must include specific verbatim quotes — paraphrased summaries do not satisfy the research documentation standard; the quotes must come from real people, with participant descriptions that confirm they are in the target user group
• Spec includes success metrics that are specific and measurable before any user adopts the product — 'users will love it' is not a metric; 'daily active users ≥ 50 within 30 days of launch' is
• Engineering alignment is documented, not assumed — the spec sitting in a Google Doc is not alignment; a written confirmation or meeting record showing the engineering team reviewed and agreed to build it is

Common mistakes

• Writing the spec before doing user research and retrofitting insights to justify a pre-decided solution — the order matters: real problem evidence first, spec second; a spec that was written in the first week and then 'validated' with research that confirms it has not been validated
• Setting success metrics after launch using what happened — the spec must contain success metrics written before the build begins; metrics added post-launch to match what the product achieved do not satisfy the pre-committed standard
• Treating engineering alignment as a handoff, not a collaborative review — a spec emailed to engineering without an acknowledgement that they reviewed and agreed to the scope does not constitute alignment; if engineering pushes back on scope, that negotiation and its resolution is part of the M1 evidence

Resources

What a verifier looks for

• Research authenticity: ask the submitter to name one insight from user research that surprised them and changed the spec — if they cannot, the research may have been confirmatory rather than genuinely investigative
• Success metric quality: the spec's success metrics must be pre-committed; check that the document was written before launch (date or version history) and that the metrics are specific enough to be unambiguously met or not met within the stated timeframe
• Engineering alignment: a read-receipt on a Slack message does not constitute alignment; alignment requires evidence that an engineering team member reviewed the scope and agreed to build it — a written 'looks good, we'll start on Monday' from an engineer satisfies the standard

Own a milestone like this? Submit proof and invite verifiers — sign in to get started.

Proof required

Submit: (1) a public or internal link to the shipped product — a URL, app store link, or internal system link that demonstrates the product exists and is accessible to the intended users; (2) a build coordination log: at least 3 entries from the build period documenting a specific decision, unblocking action, or scope adjustment you made — not a status update log, but a decisions log; (3) first user adoption evidence: at least 1 real user using the product after launch, documented with a usage metric, a user screenshot, or a user quote.

What gets checked

• Product link goes to a real product that can be accessed, not a landing page or a prototype — a prototype is a discovery artefact; a shipped product has real users who can complete real tasks with it
• Build coordination log contains actual decisions — 'met with engineering today' is a status update; 'de-scoped the notification system from V1 after engineering estimated 2 weeks for it; agreed to ship without it and revisit in V2' is a decision
• First user adoption evidence is from a real user after launch — a colleague trying the product counts; a tester during development does not; the adoption must be post-launch

Common mistakes

• Shipping a prototype and calling it a product — a Figma prototype, an Airtable form, or a static HTML page that demonstrates a concept is not a shipped product in the PM proof sense; the product must be functional enough for a real user to complete the core user journey
• Coordination log that only records progress — a log that says 'engineering completed the login module' is a status update, not a coordination record; the PM's specific contribution to unblocking or deciding must be documented
• Counting internal team members as the first user adoption evidence — a product launched 'internally' where the only 'users' are the engineering team and the PM is not a shipped product proof; the user adoption evidence must come from people who are not part of the build team

Resources

What a verifier looks for

• Product existence: click the submitted link during verification — a 404, a landing page with no functional product, or a Figma prototype does not satisfy the shipped product standard
• Coordination log quality: count how many entries are status updates vs. decisions; a log with 10 entries and 0 decisions is not a coordination record in the PM sense
• First user adoption: ask the submitter to describe what the first real user did with the product — if they cannot describe a specific user action, the adoption evidence is not based on real observed usage

Own a milestone like this? Submit proof and invite verifiers — sign in to get started.

Proof required

Submit: (1) an adoption report comparing the M1 pre-committed success metrics with actual results at 30 days (or 60 days for B2B products) — achievement, partial achievement, or non-achievement of each metric, with data source screenshots; (2) a lessons-learned document (400 words minimum) covering: which spec assumption proved wrong, what you would de-scope or change in the spec if you did this again, and what specifically drove or limited adoption; (3) documentation of a real-time Q&A session with a named, qualified reviewer — the reviewer must have ≥3 years of hands-on product management experience, a verifiable professional profile, and must not be your direct report or a close personal friend; the session documentation must include the reviewer's specific challenge questions and your responses.

What gets checked

• Adoption report compares M1 pre-committed metrics to actual results — the metrics must be the same ones from the spec, not new metrics chosen post-launch to show success; any discrepancy between spec metrics and report metrics must be explicitly explained
• Lessons-learned document identifies at least one spec assumption that proved wrong — 'everything went as planned' is rarely honest; the discipline is identifying which assumption diverged from reality, not whether the product succeeded overall
• Q&A documentation shows reviewer challenge questions and PM responses in real time — a summary of 'we had a good discussion' is not documentation; the specific questions and specific answers, including the reviewer's follow-up challenges, are required

Common mistakes

• Choosing post-launch metrics that happen to show success and calling them the pre-committed metrics — the spec must have been written before launch and the M3 report must use the exact metrics from the spec; any metric swap must be explicitly disclosed and justified
• Selecting a reviewer who will be supportive rather than challenging — a friend, a mentor who has only seen successful aspects of your work, or someone who agrees with you before seeing the evidence is not meeting the ADVERSARIAL VERIFICATION standard; the reviewer must be capable of and willing to challenge specific decisions
• Providing only positive lessons learned — 'the launch went well, the users liked it, I would just launch faster next time' is not a real lessons-learned document; the M3 lessons-learned must identify at least one specific assumption that turned out to be wrong and what that means for future specs

Resources

What a verifier looks for

• Metric pre-commitment: compare the M3 adoption report metrics to the M1 spec metrics — if they differ without explanation, ask the submitter to account for the discrepancy; post-launch metric selection to show success is the most common failure mode in PM proof submissions
• Reviewer qualification: the reviewer's name and verifiable professional profile must be included; check that the profile shows ≥3 years of hands-on PM experience (not just management of PMs or product marketing roles); close personal friends or current direct managers are not meeting the adversarial verification standard
• Q&A documentation quality: generic discussion notes ('we discussed the spec and the reviewer said it was good') do not satisfy the standard; look for specific challenge questions ('why did you decide to de-scope the notification system?') and specific responses that show the PM reasoning in real time — not a post-session write-up of what they wish they had said

Own a milestone like this? Submit proof and invite verifiers — sign in to get started.