Product Manager
Be credible for an associate product manager role: able to size an opportunity, prioritise honestly, write a spec and measure whether it worked.
This is a starting point — make it yours
Use this goal to build your own roadmap — tailored to you and starting fresh.
What the job actually is
Most people arrive with a wrong model of product management — usually either 'mini CEO' or 'writes tickets'. Fixing that first makes everything else make sense.
Learn the shape of the role and its boundaries~5h
What a PM owns (the problem, the priority, the why), what they don't (design, architecture, people management), and how it differs from project and programme management. Influence without authority is the defining constraint.
Done when: you can explain the difference between a PM, a designer and an engineering lead's decisions on the same feature.
Learn to write a problem statement without a solution in it~4h
"Users can't find their order history" not "add an order history page". Harder than it sounds — solutions smuggle themselves into problem statements constantly, and doing so removes every option but one.
Done when: you can rewrite five solution-shaped requests as problems.
Learn the metrics vocabulary properly~6h
Activation, retention, engagement, churn, north star metrics, leading vs lagging indicators, and why vanity metrics persist. Retention is the one that matters most and gets discussed least.
Done when: you can define a north star and two supporting metrics for three products you use.
Learn enough of the technical side to be trusted~8h
APIs, databases, what makes a change expensive, why estimates are uncertain, and what technical debt actually costs. You don't need to code; you need to not propose things that are quietly absurd.
Done when: you can read an API doc and sketch what a feature would require of it.
Discovery and evidence
The half of the job that stops you from confidently building the wrong thing.
Interview eight users of a product you don't own~10h
Pick any product with real users and talk to them about how they actually use it. Ask about the last time, not the general case — memory of specifics is far more reliable than self-description.
Done when: eight interviews are done and you have three findings you did not expect.
Size an opportunity with numbers you can defend~6h
How many users are affected, how often, what it's worth. The numbers will be estimates — the skill is making the assumptions explicit so someone can argue with them rather than with you.
Done when: you have a one-page sizing with every assumption labelled and sourced.
Learn experiment design and its limits~6h
A/B tests, sample size, why you can't peek at results early, and when an experiment is the wrong tool — low traffic, long feedback loops, or a change too small to detect.
Done when: you can design a valid test for one hypothesis and name two situations where testing wouldn't work.
Write a competitive teardown of one product~6h
Not a feature list. What is this product betting on, who is it deliberately not for, and where is it vulnerable? Strategy questions in interviews are usually a version of this.
Done when: a two-page teardown exists that names the bet and one vulnerability.
Deciding and shipping
Prioritisation is the job. Everything else is support for it.
Learn three prioritisation frameworks and their failure modes~6h
RICE, opportunity scoring, and cost of delay. Every framework is a way of making assumptions explicit, not a way of avoiding judgement — and each can be gamed by whoever fills in the numbers.
Done when: you can apply RICE to ten items and explain where the scoring is doing the arguing for you.
Write a full product spec for a real feature~8h
Problem, evidence, success metric, scope, explicit non-goals, open questions, and the rollout plan. Non-goals are the most valuable section and the one juniors omit.
Done when: an engineer could read it and start work without asking what the feature is for.
Run a real prioritisation exercise with disagreement in it~6h
Take a backlog — a society, a side project, an open source repo — and decide the order with people who want different things. Handling the disagreement is the exercise.
Done when: a prioritised list exists that at least one other person disagreed with and understood.
Ship one thing end to end, however small~15h
A change to a society's website, a feature in a friend's project, an internal tool. Having actually shipped something and watched the metric afterwards is what separates candidates.
Done when: it is live, and you have measured whether it did what you expected.
Interviewing
PM interviews test structured thinking aloud, which is a distinct skill from doing the job well.
Practise product sense questions aloud~8h
"Design a X for Y." Clarify, pick a user, name their problem, generate options, choose with a stated trade-off, define a metric. The structure is the answer; the idea matters less.
Done when: you can work through five such questions aloud in a consistent structure.
Practise estimation and metric-debug questions~8h
"How many X are sold in the UK annually?" and "engagement dropped 20% overnight — what do you do?". Both reward a visible, checkable method over a confident number.
Done when: you can do five of each, showing your working and sanity-checking the result.
Turn your work into three STAR stories~5h
A conflict, a decision made on incomplete information, and a failure. Rehearse them until they are two minutes each — the failure story is the one that decides the interview.
Done when: three stories are written and timed at two minutes.
Do two mock interviews with someone in the role~5h
Practising alone hides your worst habits, especially rambling. Someone who does the job will spot in ten minutes what you would not notice in ten hours.
Done when: two mocks are done and you have acted on the feedback from both.