Become Product Manager

Proof required

Submit the PRD or feature spec (with a git commit timestamp or document creation date predating the build), the evidence that informed the problem statement (user feedback, analytics screenshot, or stakeholder email — redacted if sensitive), and a one-paragraph description of what actually shipped vs what was in the spec (any changes and why).

What gets checked

• Problem statement is backed by evidence — a quote from a user, an analytics metric, or a documented stakeholder pain; 'I think users need this' is not evidence
• Success metrics have measurable thresholds ('increase checkout completion rate from 67% to 72% within 60 days') not vague aspirations ('improve checkout')
• The spec predates the build — a post-hoc spec is documentation, not a product requirement

Common mistakes

• A spec that describes what to build without explaining why — a PRD that has requirements but no problem statement is an engineering ticket, not a product requirement
• Success metrics that cannot be measured (NPS increase, 'users will be happier') — metrics that cannot be measured cannot determine whether the feature succeeded
• The spec was written after the feature shipped rather than before — a post-hoc spec is not a product planning artefact

Resources

What a verifier looks for

• Ask for the original problem evidence before reading the spec — a PM who cannot produce user evidence for the problem statement is working from intuition
• Check the success metrics: ask the submitter how they would measure them after the feature ships — if they cannot describe the measurement method, the metric was not well-chosen
• Ask what changed between the original spec and what shipped — genuine product work always involves scope negotiation or changed understanding; a zero-change spec was either not used or was written after
• Confirm the spec predates the build — ask for the document timestamp or git commit date

Proof required

Submit the synthesis document: key themes from the 5 interviews (minimum 2 specific user quotes per theme), the prioritisation framework used (which criteria, how they were weighted), and the recommendation memo (problem, evidence, recommendation, risks of the recommendation). Include a cover note naming who the memo was sent to and their role.

What gets checked

• At least 2 specific user quotes per theme — themes that are not supported by specific quotes are interpretations, not findings
• Recommendation memo ends with a specific recommendation — 'we should build X first because Y' not 'here are 3 options for the team to consider'
• The memo was sent to a real decision-maker — not kept as a personal document; the impact of product discovery is in the decisions it drives

Common mistakes

• Conducting user interviews where all interviewees agree — a discovery that finds unanimous agreement on a single solution has not actually explored the problem space
• A synthesis that lists interview notes rather than synthesised themes — themes are interpretations that span multiple interviews, not summaries of individual sessions
• A recommendation memo that lists options rather than making a recommendation — the value of a PM is in making the call, not in presenting options

Resources

What a verifier looks for

• Ask the submitter to read one user quote from the synthesis that changed their prior belief about the problem — genuine discovery always produces at least one update
• Check that themes are supported by specific quotes from multiple different interviewees — a theme supported by only one person is an outlier, not a finding
• Ask what the decision-maker decided to do with the recommendation — this is not always available but is the most important downstream signal of the discovery's quality
• Ask what the submitter would do differently in the next discovery cycle — genuine learning from a first discovery cycle always produces specific process improvements

Proof required

Submit both the M1 spec and M2 synthesis plus the reviewer's written assessment: the prioritisation challenge and response, the metrics challenge and response, the what-would-make-this-wrong response, the hypothetical stakeholder scenario and response, and their sign-off confirming their role and a live session.

What gets checked

• Prioritisation challenge response names the specific trade-off (what was deprioritised and why, not just why this was chosen)
• What-would-make-this-wrong response identifies a specific falsifiable condition — not 'if the users don't like it' but 'if the checkout completion rate does not increase within 30 days despite the feature shipping'
• Reviewer sign-off confirms 5+ years of shipping products in industry as a PM (not in adjacent roles like engineering or design)

Common mistakes

• Prioritisation challenge response that defends the choice without acknowledging what was deprioritised — a PM who cannot name the trade-off has not actually prioritised, they have just decided
• Hypothetical stakeholder response that is passive ('I would try to negotiate') rather than specific ('I would scope it down to X to get it done in 2 months, and propose Y as a fast follow')
• A reviewer who is a designer or researcher rather than a product manager — the challenge questions must come from someone who has owned product prioritisation decisions

Resources

What a verifier looks for

• Ask the what-would-make-this-wrong question early — it is the most revealing indicator of whether the submitter is defending a position or testing a hypothesis
• The hypothetical stakeholder scenario should be a real constraint (a real constraint type they encounter in your domain) — 'engineering says 6 months' is more realistic than an extreme scenario
• Reviewer minimum qualification: 5+ years as a product manager (not VP/CPO without active product ownership, not designer, not engineer with some product involvement)
• Ask what the submitter would do in the first week of a new PM role — this tests whether the M2 discovery process is a learned habit or a one-time exercise