Product management cheat sheet

9 minReference

Product management cheat sheet

The Product line on a few screens: the question to ask at each stage, discovery and prioritisation tools, spec and story templates, the metrics and experiment rules, launch steps, AI product checks and how to write to stakeholders. Keep it open while you plan, write a spec or prepare a review.

If you see X, reach for Y

Most product trouble starts with skipping a step: building before the problem is clear, or launching without a way to tell if it worked.

You see	Reach for first	Then, if needed	Lessons
A stakeholder asks for a feature	Ask what problem it solves, for whom, and how they cope today	Write a one-line problem statement and get it agreed	Problems first
Nobody knows if users have the problem	5 to 8 user interviews about past behaviour	Watch the work in the field (a store, a partner shop)	User interviews, Field research
Many notes, no conclusions	Affinity map, then rank themes by frequency and pain	An opportunity solution tree	Synthesis
A big build on an untested idea	The cheapest test: fake door, concierge, prototype	An AI-built clickable prototype	Cheap tests, AI prototypes
Too many good ideas	RICE or cost of delay, scored together	Tie each one to an outcome in the strategy	Prioritisation
The roadmap is a list of dates nobody trusts	Now / Next / Later by outcome	Dates only for committed, sized work	Roadmaps
Engineers keep asking "what about…"	Edge cases and acceptance criteria in the spec	A design review with engineering early	Specs, Engineers
"Did the launch work?" has no answer	A success metric and a baseline before launch	An experiment or a staged rollout	Launch, Experiments
The headline metric moved and nobody knows why	Break it down with a metric tree	Segment by platform, city, new or returning	Metric trees, Metric reviews
Sign-ups are fine but users leave	Retention curve by cohort	Fix onboarding to reach the first value moment	Retention, Onboarding
An internal tool is built but staff avoid it	Watch frontline staff use it; count workarounds	Training, champions, retire the old way	Frontline design, Change and adoption
Leadership wants "AI in the product"	Find a task where AI fits and a wrong answer is cheap	An eval set before any build	AI problem fit, Evals
A decision keeps coming back to the same meeting	A one-page decision memo with options	Name the decider (one person)	Decision memos

The product loop on one line

Problem (who, what pain, how often, evidence), outcome (the metric that should move), options (at least three, including do nothing), the cheapest test, build the smallest useful slice, launch to a few, measure against the baseline, then decide: scale, change or stop. Write each decision down (The PM role, Value and risk).

The four risks to check

Every idea can fail in four ways. Name the riskiest one and test it first (Value and risk).

Risk	The question	Cheap way to test	Lesson
Value	Will people use it or pay for it?	Interviews about past behaviour, a fake door, a pre-order	Cheap tests
Usability	Can they work out how to use it?	Five users try a prototype while you watch	Design
Feasibility	Can we build and run it with our team and systems?	An engineer spike of a day or two	Engineers
Viability	Does it work for the business: cost, legal, support, brand?	A one-page business case and a check with legal and finance	Business cases

Interview rules

Ask about the past, not the future. "Tell me about the last delivery you received" beats "Would you use a scanner app?" (User interviews).

Start broad: "Walk me through yesterday's receiving." Then zoom in on the painful moment.
Ask "why" and "what did you do then?"; avoid "would you" and "do you like".
Do not pitch your idea. If you must show something, show it last.
One person asks, one takes notes; write a summary within an hour.
Look for workarounds: paper lists, photos in chat groups, spreadsheets. They point to real pain.
Five to eight interviews per segment usually show the main patterns.

Prioritisation tools

Use one method consistently and score as a group. The numbers start the conversation; they do not end it (Prioritisation).

Tool	Formula or rule	Good for	Lesson
RICE	(Reach × Impact × Confidence) ÷ Effort	Comparing many features on one list	Prioritisation
ICE	Impact × Confidence × Ease	Quick scoring of growth experiments	Prioritisation
Cost of delay ÷ duration (CD3)	Value lost per week of waiting ÷ weeks to build	Ordering work when timing matters	Prioritisation
MoSCoW	Must, Should, Could, Won't (this time)	Agreeing the scope of one release	Specs
Kano	Basic needs, performance needs, delighters	Seeing what users expect versus what surprises them	Prioritisation
Build, buy or partner	Is it core to how we win? If not, buy or partner	Platform and tooling decisions	Build or buy

Strategy and OKRs

A strategy is a diagnosis, a guiding policy and a few coherent actions. OKRs turn it into a quarter's goals (Strategy, OKRs).

Output

Objective: Store receiving is fast and right.
  KR1: Median time to receive a delivery falls from 51 to 30 minutes.
  KR2: GRNs corrected later fall from 1 in 12 to 1 in 30.
  KR3: 90% of the 320 stores receive every delivery in the Store app.

An objective is qualitative and inspiring; a key result is a number with a baseline and a target.
Key results measure outcomes (what changed for users), not output ("ship the scanner screen").
Three to five key results per objective; a 70% score on a stretch goal is a good quarter.

Spec and story templates

A spec answers why, what and how we will know; the stories carry the details engineers build and test (Specs, Stories and AC).

Markdown

# One-page spec: Scan to receive
Problem: Receiving a delivery takes 51 min, 21 of them on workarounds.
Who: 2 receivers per store, 320 stores, ~4 deliveries a day each.
Outcome: median receive time 30 min; corrected GRNs 1 in 30.
Not doing: supplier invoices, returns.
Solution sketch: scan each case; app compares with the order.
Risks and open questions: scanners offline in the back room?
Launch: 5 pilot stores, then by city. Owner: Imran. Decision date: ...

Output

As a store receiver, I want to scan each case against the order,
so that I find shortages before the driver leaves.

Given an open order for store S-014 with 12 cases of milk
When I scan 10 cases and tap Finish
Then the app shows "2 cases short" and asks the driver to sign

A good story is…	Check	Lesson
Independent	Can ship without waiting for another story	Stories and AC
Negotiable	Describes the need, leaves room on the how	Stories and AC
Valuable	A user or the business gets something from it alone	Stories and AC
Estimable	The team can size it	Engineers
Small	Fits in a few days, not a whole sprint	Stories and AC
Testable	Has acceptance criteria someone can check	Stories and AC

Metrics you will be asked about

Define each metric once, in writing: the exact event, the time window, and who counts (Metric trees, Funnels, Retention, Instrumentation).

Metric	Definition	Watch out	Lesson
North star	The one number that best tracks value to users, such as weekly orders delivered on time	Pair it with guardrails (cost, complaints)	Metric trees
Conversion rate	Users who complete a step ÷ users who reached it	Say which step and which window	Funnels
DAU / MAU	Daily active users ÷ monthly active users	Weak for weekly habits like groceries	Engagement and ethics
Retention (cohort)	Share of a sign-up cohort still active in week N	A flattening curve matters more than week 1	Retention
Churn	Customers lost in a period ÷ customers at the start	Define "lost" (no order in 30 days?)	Retention
Activation	Share of new users who reach the first value moment	Pick the moment from data, not opinion	Onboarding
CAC, LTV, payback	Cost to win a customer; lifetime margin; months to earn CAC back	Use margin, not revenue	Unit economics
Adoption (internal tools)	Share of the work done in the new tool	Count the work, not the logins	Change and adoption

Experiment rules

An A/B test compares two versions on randomly split users. Decide everything before it starts (Experiments, A/B test design).

Write the hypothesis: "Showing the delivery slot first will raise checkout conversion by 1 point."
Pick one primary metric and a few guardrails (order value, cancellations, support contacts).
Work out the sample size and duration first, and run whole weeks to cover weekday patterns.
Do not stop early because it looks good; peeking inflates false wins.
Check the split is even (sample ratio mismatch) before reading results.
A flat result is a result: write it down so nobody runs it again.

Launch checklist

A launch is a sequence, not a day (Launch, Production ops).

Before	During	After
Success metric and baseline recorded	Feature flag on for a pilot group (5 stores, 5% of users)	Compare with the baseline after 2 to 4 weeks
Support, sales and store staff briefed; FAQ written	Watch errors, support tickets and the metric daily	Share results, good or bad, in a short update
Events instrumented and checked in a test build	Clear rollback rule: "if X, turn the flag off"	Remove the flag and the old path
Legal, privacy and accessibility reviewed	One owner on call for questions	Decide: scale, change or stop

AI product checks

Before building an AI feature, answer these (How AI works, AI problem fit, AI feature design, Evals).

What happens when it is wrong, and who notices? Start where a wrong answer is cheap and visible.
Is there a simpler rule or search that does the job? Use it if so.
Do we have 30 to 100 real examples with the right answer to build an eval set?
How does the user check, correct or undo the output?
What does each use cost, and does it still pay at 4× festival traffic?
What data goes to the model provider, and is that allowed?

Writing to stakeholders

Lead with the answer. Busy readers stop after the first lines (Decision memos, Exec updates, Stakeholders).