Product & Technical
Product Management
Product managers are accountable for outcomes without authority over the people producing them. The job is deciding which problems are worth solving, saying no to most of the rest, and making sure the team knows why.
Start here
You do not need to code, but you do need to understand how software is built well enough to have a credible conversation. If you come from engineering, design or analysis, you are already partway; if not, expect Stage 2 to take longer.
Understanding the problem
Most failed products are well-built solutions to problems nobody had. This stage prevents that.
RequiredDiscovery and user research
The most expensive mistake in product is building the wrong thing well. Discovery is how you avoid it.
Discovery and user research
The most expensive mistake in product is building the wrong thing well. Discovery is how you avoid it.
What to learn
- Customer interviews
- Distinguishing what people say from what they do
- Problem framing
- Jobs to be done
- Competitive analysis
- Knowing when not to build anything
Practice
Next: Understanding the market and the business.
RequiredBusiness and market context
Product decisions are business decisions. A PM who cannot connect a feature to revenue or retention will not be trusted with the roadmap.
Business and market context
Product decisions are business decisions. A PM who cannot connect a feature to revenue or retention will not be trusted with the roadmap.
What to learn
- Business models and unit economics
- Market sizing
- Positioning and differentiation
- Pricing in outline
- Understanding your company's actual constraints
Next: Enough technical fluency.
Technical fluency
Not to build it, but to have credible conversations and to sense when an estimate is wrong.
RequiredHow software gets built
Without this you cannot judge trade-offs, and engineers will notice within a week.
How software gets built
Without this you cannot judge trade-offs, and engineers will notice within a week.
What to learn
- APIs and what they imply
- Databases in outline
- Why some changes are cheap and others are not
- Technical debt as a real cost
- Reading a system diagram
- Basic SQL
Practice
Next: Data.
RequiredWorking with data
Opinions lose to numbers, and the PM who can query the data themselves moves considerably faster.
Working with data
Opinions lose to numbers, and the PM who can query the data themselves moves considerably faster.
What to learn
- Defining metrics that reflect the outcome
- SQL for your own questions
- Funnel analysis
- Cohort and retention analysis
- A/B testing and its pitfalls
- Vanity metrics and how to spot one
Tools
- SQL
- An analytics tool
Project
intermediateA product analysis
Pick a product you use. Define what its success metric should be, find or estimate the data, identify the biggest drop-off in its funnel, and propose one change with a hypothesis and a way to measure it.
- SQL or a spreadsheet
You can propose a change and say precisely how you would know if it worked.
Next: Deciding what to do.
Strategy and prioritisation
Where the actual job lives, and where the pressure is.
RequiredProduct strategy
Without a strategy, a roadmap is just a list of whoever asked most recently.
Product strategy
Without a strategy, a roadmap is just a list of whoever asked most recently.
What to learn
- Vision and narrative
- Outcome-based objectives
- Choosing what not to do
- Sequencing towards a goal
- Communicating strategy repeatedly
Next: Prioritisation.
RequiredPrioritisation
Everything cannot be first. Having a defensible method turns a political argument into a discussion.
Prioritisation
Everything cannot be first. Having a defensible method turns a political argument into a discussion.
What to learn
- Impact versus effort
- RICE and similar frameworks as tools not oracles
- Opportunity cost
- Managing a backlog honestly
- Saying no with a reason
Practice
Next: Making it happen.
Execution
Turning a decision into shipped software with a team you do not manage.
RequiredWorking with a delivery team
The day-to-day. A PM who is a bottleneck slows everything down.
Working with a delivery team
The day-to-day. A PM who is a bottleneck slows everything down.
What to learn
- Writing requirements that leave room for engineering judgement
- Acceptance criteria
- Agile in practice rather than in theory
- Scope negotiation under a deadline
- Unblocking rather than assigning
- Release planning
Next: Stakeholders.
RequiredStakeholders and influence
The defining constraint of the role: accountability without authority. Influence is the only lever you have.
Stakeholders and influence
The defining constraint of the role: accountability without authority. Influence is the only lever you have.
What to learn
- Managing upwards
- Aligning teams with different incentives
- Communicating trade-offs to non-technical people
- Handling a request you are going to refuse
- Building credibility by being right in public
Practice
Next: Learning from what shipped.
RequiredLaunch and learn
Shipping is the middle of the process, not the end. Most teams never check whether it worked.
Launch and learn
Shipping is the middle of the process, not the end. Most teams never check whether it worked.
What to learn
- Launch planning
- Instrumenting before release
- Measuring against the original hypothesis
- Deciding to iterate, keep or remove
- Writing an honest retrospective when it did not work
Project
advancedA product decision, documented end to end
Take one real feature: write the problem statement, the evidence, the options considered, the decision and its reasoning, the success metric, and after launch, what actually happened.
- A document
- An analytics tool
You have a written record of a decision and its outcome, which is the single most useful thing to bring to a PM interview.
Where this leads
You do not have to pick one now. These are the directions this path opens up once you are working.
Continue your journey
The paths closest to this one. Skills overlap more than the job titles suggest.
UI/UX Design
Decide how something should work before anyone builds it.
ViewData Analysis
Turn messy data into a decision someone actually makes.
ViewDeveloper Relations
Help developers succeed with a product, and bring their problems back.
ViewTechnical Writing
Explain complex systems so clearly that nobody has to ask.
ViewYou do not have to do this alone
Our programs are free, taught live, and built around the same progression. Join one and work through it alongside other people.