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

You'll sign in first, then come straight back here.

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

You'll sign in first, then come straight back here.

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

You'll sign in first, then come straight back here.