How to learn Product management
This curriculum takes you from zero product management knowledge to a deeply strategic, data-informed, and leadership-level practitioner. Each stage builds on the last: you first absorb the core mental models of PM work, then learn how to discover and validate the right problems, then master execution and cross-functional collaboration, and finally develop the strategic and leadership thinking that separates great PMs from good ones.
Foundations: What Product Management Actually Is
New to itUnderstand the role of a product manager, the core frameworks (discovery, delivery, strategy), and the mindset shift from feature-builder to outcome-owner.
▸ Study plan for this stage
Pace: 10–12 weeks total (~30–40 pages/day, 5 days/week): Weeks 1–4 for "Inspired" (~400 pages), Weeks 5–7 for "The Lean Startup" (~300 pages), Weeks 8–11 for "Continuous Discovery Habits" (~370 pages), with Week 12 reserved for review, reflection, and completing exercises.
- The Product Manager's core responsibilities: defining the right product, not just building features — as Cagan argues, PMs own outcomes, not output
- The four big risks every product faces (value, usability, feasibility, business viability) introduced in Inspired, and how discovery work de-risks them before a single line of code is written
- The difference between empowered product teams and feature teams (Cagan's central thesis): empowered teams are given problems to solve, not solutions to build
- The Build-Measure-Learn loop from The Lean Startup: validated learning through rapid experimentation replaces big-bang releases and assumption-driven roadmaps
- Minimum Viable Products (MVPs) as learning instruments, not cheap versions of the final product — Ries's distinction between optimization and discovery
- The concept of Innovation Accounting (The Lean Startup): using actionable metrics and milestones to measure real progress toward product-market fit
- Continuous discovery as a weekly team habit, not a phase — Torres's core argument that discovery is ongoing, collaborative, and structured around customer interviews
- The Opportunity Solution Tree (Torres): a visual framework for connecting desired outcomes → opportunities → solutions → experiments, preventing teams from jumping to solutions prematurely
- According to Cagan in Inspired, what is the fundamental difference between an empowered product team and a feature factory, and why does that distinction matter for how a PM spends their time?
- What are the four product risks Cagan identifies, and for each one, which role on the product team is primarily responsible for addressing it during discovery?
- How does Ries define a 'pivot' in The Lean Startup, and how does the Build-Measure-Learn loop inform the decision of when to pivot versus persevere?
- What makes an MVP a learning tool rather than a product shortcut, and what is the danger of confusing the two — as illustrated by examples in The Lean Startup?
- Torres argues in Continuous Discovery Habits that discovery should be a weekly team habit rather than a project phase. What structural practices does she recommend to make this sustainable?
- How does the Opportunity Solution Tree from Torres prevent the common PM trap of jumping straight from a business outcome to a specific solution, and how does it connect to the risk-reduction ideas in Inspired?
- Role Audit Journal (during Inspired): For one week, shadow or interview a PM (or reflect on your own current role). Log every task against Cagan's framework — is each activity discovery, delivery, or strategy? Identify where time is being lost to feature-factory behaviors.
- Four-Risk Analysis (after Inspired): Pick a product or feature you know well. Write a one-page risk assessment mapping it against Cagan's four risks (value, usability, feasibility, viability). For each risk, write one discovery activity that would reduce it before development begins.
- MVP Design Sprint (during The Lean Startup): Choose a real or hypothetical product idea. Define the single riskiest assumption, design the smallest possible experiment to test it (no code required), and write a crisp hypothesis in Ries's format: 'We believe [assumption]. We will know we are right when [measurable signal].'
- Metrics Makeover (after The Lean Startup): Take a vanity metric you've seen used on a team (page views, downloads, sign-ups) and rewrite it as an actionable metric using Ries's innovation accounting principles. Define a baseline, a target, and the decision that will be triggered if the target is or isn't hit.
- Weekly Customer Interview Practice (during Continuous Discovery Habits): Conduct at least two structured customer interviews using Torres's guidelines — recruit from your existing network or a product you use. Record the session (with permission), then map what you heard onto an Opportunity Solution Tree, identifying at least three distinct opportunity nodes.
- Full Opportunity Solution Tree Build (after all three books): Pick a product outcome (e.g., 'increase user activation by 20%'). Build a complete Opportunity Solution Tree: list opportunities from your interviews, generate multiple solutions per opportunity, and design one assumption test per solution. Evaluate your tree against Cagan's four risks and Ries's MVP principles to stress-test it end-to-
Next up: Mastering these foundational frameworks — empowered teams, validated learning, and continuous discovery — gives you the mental models needed to tackle the next stage, where you'll apply strategic thinking and prioritization to decide *which* opportunities and bets are worth pursuing at scale.
The single most-cited introduction to modern product management; establishes the vocabulary of product teams, product discovery, and what separates great PM organizations from the rest. Read this first to get the full map.
Introduces the Build-Measure-Learn loop and the concept of validated learning, which underpins nearly every discovery technique you will encounter later. Reading it second anchors Cagan's ideas in a concrete operating model.
Translates the lean mindset into a weekly, repeatable practice of customer interviews and opportunity mapping; bridges the gap between theory and day-to-day PM habits before you move to deeper topics.
Understanding Users: Research & Problem Discovery
New to itDevelop the skills to talk to customers, synthesize insights, and frame the right problem before jumping to solutions.
▸ Study plan for this stage
Pace: 4–5 weeks total: Week 1–2 — "The Mom Test" (~30 pages/day, ~130 pages); Week 3–5 — "Competing Against Luck" (~20–25 pages/day, ~260 pages). Allow extra time after each book for reflection and exercises.
- The Mom Test rule: ask about people's lives and past behaviors, not opinions or hypotheticals — compliments and forward-looking statements are not data (The Mom Test)
- Avoiding 'bad data': recognizing the three types of bad conversations — fluff, false positives from social pressure, and pitching instead of learning (The Mom Test)
- Digging for specifics: how to uncover real problems by asking for concrete stories, workarounds, and the last time something happened (The Mom Test)
- The Jobs-to-Be-Done (JTBD) framework: customers 'hire' products to make progress in a specific circumstance — the unit of analysis is the job, not the customer demographic (Competing Against Luck)
- The Four Forces of Progress: the push of the current situation, the pull of the new solution, anxiety about the new, and attachment to the old — all four must be understood to explain adoption (Competing Against Luck)
- Circumstances over attributes: why customer segments defined by demographics or psychographics are less predictive than the specific situation in which a job arises (Competing Against Luck)
- The difference between correlation and causation in customer data: big data can reveal patterns but cannot explain the causal mechanism behind a purchase decision (Competing Against Luck)
- Integrating research into problem framing: combining rich interview insights (The Mom Test) with the JTBD causal structure (Competing Against Luck) to write a precise, actionable problem statement
- According to The Mom Test, why is asking 'Would you use this product?' a dangerous question, and what should you ask instead?
- What are the three types of 'bad data' Rob Fitzpatrick warns against, and how can you recognize each one in a real conversation?
- How does the Jobs-to-Be-Done framework redefine who your 'customer' is, and why does Christensen argue that demographics alone fail to predict buying behavior?
- What are the Four Forces of Progress, and how would you use them to explain why a customer switched from one solution to another?
- How would you combine a Mom Test-style customer interview with the JTBD lens to write a problem statement that captures both the specific circumstance and the functional/emotional/social dimensions of the job?
- Christensen argues that 'big data' can mislead product teams — what is the core limitation he identifies, and how does qualitative interview research address it?
- Run 3 real customer interviews using only Mom Test-compliant questions (no hypotheticals, no pitching). Record them, then review the transcript and highlight every moment you accidentally asked for an opinion — rewrite those questions correctly.
- Take one interview transcript and extract a JTBD story: identify the struggling moment (circumstance), the functional job, the emotional job, and the social job the person was trying to accomplish. Map it to Christensen's Four Forces.
- Write a 'bad interview' script full of leading questions and compliment-fishing, then rewrite it as a 'good interview' script using The Mom Test principles. Share both versions with a peer and discuss the differences.
- Choose a product you use daily. Interview yourself using the 'switching interview' technique from Competing Against Luck: reconstruct the timeline from first thought to first use. Identify the push, pull, anxiety, and habit forces at play.
- Synthesize insights from your 3 interviews into a single one-page problem statement that includes: the specific circumstance, the job to be done, the current inadequate solution, and the metric of progress the customer cares about.
- Audit a product you know well (or a case study) by listing its features and then mapping each feature back to a job-to-be-done. Identify any features that cannot be mapped to a real job — these are candidates for cutting.
Next up: Mastering how to listen for real problems and frame them as causal jobs-to-be-done gives you the validated foundation you need to move into ideation and solution design — the next stage will build directly on these problem statements to teach you how to generate, prioritize, and test potential solutions.
A short, practical guide to conducting customer interviews that yield honest signal rather than polite noise; essential reading before you run your first discovery interview.
Introduces Jobs-to-be-Done theory, giving you a powerful lens for understanding why customers 'hire' products; deepens the user-insight work started with The Mom Test by adding a causal framework.
Execution: Building & Shipping Great Products
Some backgroundMaster the craft of writing specs, prioritizing ruthlessly, working with engineering and design, and iterating toward product-market fit.
▸ Study plan for this stage
Pace: 6–8 weeks total: Weeks 1–3 cover "Escaping the Build Trap" (~25–30 pages/day, ~240 pages); Weeks 4–7 cover "Shape Up" (~20–25 pages/day, ~145 pages, with slower pace for hands-on application); Week 8 is a synthesis and reflection week with no new reading.
- The Build Trap: the dangerous organizational pattern of measuring success by output (features shipped) rather than outcomes (value delivered), and how PMs escape it by focusing on business results and customer impact
- Product vs. Project vs. Feature Teams: Perri's distinction between reactive order-takers and empowered product teams, and why team structure determines whether great products are even possible
- The Product Kata: Perri's continuous improvement loop (understand the direction → analyze the current state → set the next goal → choose experiments) as a disciplined framework for iterating toward product-market fit
- Outcome-Based Roadmaps: replacing date-driven feature lists with roadmaps organized around problems to solve and measurable outcomes, enabling flexibility without losing strategic alignment
- Shaping vs. Building: Singer's core separation of the creative problem-framing work (shaping) from the execution work (building), ensuring teams never start a cycle with an under-defined or over-specified problem
- Appetite over Estimates: Singer's concept of fixing time (6-week cycles or 2-week cool-downs) and letting scope flex, replacing the dysfunctional practice of estimating features and then blaming engineers for missing deadlines
- Breadboards & Fat-Marker Sketches: Singer's lightweight shaping tools for communicating the concept and key interactions of a solution without over-constraining the design, preserving creative latitude for the building team
- Hill Charts & Scope Hammering: Singer's execution-phase tools for visualizing real progress (uphill = discovery, downhill = execution) and the discipline of cutting scope to protect the time boundary rather than slipping the deadline
- According to Perri, what are the three main symptoms that a company is stuck in the build trap, and what organizational conditions most commonly cause it?
- How does Perri's Product Kata differ from a standard sprint retrospective, and why does she argue the Kata is necessary even in teams already running Agile ceremonies?
- What is the difference between an outcome-based roadmap and a feature roadmap, and how would you defend an outcome-based roadmap to a stakeholder who demands specific delivery dates?
- In Singer's framework, what makes a pitch 'well-shaped'? What are the four properties a shaped solution must have before it is eligible to be bet on in a cycle?
- How does the concept of 'appetite' in Shape Up fundamentally change the conversation between a PM and an engineering team compared to traditional estimation, and what does it require of the PM during shaping?
- How do the Hill Chart and the practice of Scope Hammering work together to prevent the 'never-ending project' failure mode that Perri describes as a hallmark of the build trap?
- Build Trap Audit: Choose a current or past product initiative. Using Perri's framework, audit it across three dimensions — team structure (feature/project/product?), success metrics (output or outcome?), and roadmap format (date-driven or outcome-driven?). Write a one-page diagnosis and one concrete recommendation for each dimension.
- Product Kata Practice: Pick one real problem in your product area. Run a full Product Kata loop on paper: state the strategic intent, map the current state with data, define a specific target condition (measurable outcome, not a feature), and design one experiment to test your next step. Time-box this to 90 minutes.
- Outcome Roadmap Rewrite: Take an existing feature roadmap (your own, a public example, or a fictional one) and rewrite it as an outcome-based roadmap using Perri's structure. Identify the business outcomes, the customer problems beneath each, and remove or defer any feature that cannot be tied to a stated outcome.
- Shape a Real Problem: Select an unsolved problem from your backlog. Following Singer's shaping process, produce: (1) a written problem statement with explicit appetite (small batch or big batch), (2) a fat-marker sketch or breadboard of the solution concept, (3) a list of rabbit holes and no-gos. Share it with one engineer or designer and gather feedback without explaining it verbally first.
- Betting Table Simulation: Assemble 3–5 colleagues (or simulate solo with written personas). Present two shaped pitches for the same cycle. Run a mock betting table: each 'stakeholder' must argue for one pitch using Singer's criteria (shaped, appetized, addressable). Document the decision and the reasoning that swayed it.
- Hill Chart Retrospective: For a recently completed project, reconstruct a Hill Chart as it would have looked at three points in time (kickoff, midpoint, final week). Identify the moment the team was most 'stuck on the uphill' and write a one-paragraph post-mortem on what scope hammering could have been applied and when.
Next up: Mastering execution and shipping rhythms naturally surfaces the question of whether you are building the right product for the right market at the right time — the strategic and discovery challenges that the next stage addresses through frameworks for customer research, opportunity sizing, and product strategy.
Diagnoses the most common execution failure mode — shipping features instead of solving outcomes — and provides a framework for escaping it; pairs directly with Cagan's Inspired by showing what goes wrong in practice.
Basecamp's detailed methodology for scoping and pitching work in fixed-time cycles; gives you a concrete, battle-tested alternative to Scrum and sharpens your instincts for managing scope and risk.
Strategy & Metrics: Thinking at the Product Level
Some backgroundLearn to set a compelling product vision, define measurable success, use data to make decisions, and connect daily work to business outcomes.
▸ Study plan for this stage
Pace: 6–8 weeks total: Weeks 1–3 cover "Measure What Matters" (~30–35 pages/day, including reflection time on OKR examples); Weeks 4–7 cover "Lean Analytics" (~25–30 pages/day, which is denser with frameworks and case studies); Week 8 is a synthesis and exercise week with no new reading.
- OKRs (Objectives & Key Results): writing ambitious Objectives paired with 2–5 measurable, time-bound Key Results that signal real progress — drawn directly from Doerr's case studies at Google, Intel, and beyond
- Stretch goals vs. committed goals: Doerr's distinction between 'roofshots' (reliable, committed) and 'moonshots' (aspirational, ~70% attainment is success) and why both belong in a healthy OKR mix
- CFRs (Conversations, Feedback, Recognition): how OKRs only work when paired with continuous performance dialogue, not annual reviews
- The One Metric That Matters (OMTM): Croll's principle that at any given stage a product should rally around a single north-star metric to avoid diffusion of focus
- The Lean Analytics Stages of a Startup/Product: Empathy → Stickiness → Virality → Revenue → Scale, and how the right metric shifts at each stage
- Pirate Metrics (AARRR) as a diagnostic framework: Acquisition, Activation, Retention, Referral, Revenue — using each funnel stage to locate where a product is leaking value
- Data-informed vs. data-driven decision-making: Croll's argument that qualitative insight must accompany quantitative signals to avoid optimizing the wrong thing
- Connecting daily work to business outcomes: mapping team-level OKRs (Doerr) to funnel-stage metrics (Croll) so every sprint or experiment has a clear line to strategic impact
- After reading Measure What Matters, can you write a crisp, inspiring Objective for a product you work on, along with 3 Key Results that are measurable, time-bound, and would unambiguously prove the Objective was achieved?
- How does Doerr differentiate between a Key Result and a task or initiative, and why does that distinction matter for holding teams accountable?
- According to Lean Analytics, what is the One Metric That Matters, and how would you identify the right OMTM for a product currently in the 'Stickiness' stage versus the 'Virality' stage?
- Using Croll's AARRR framework, if your product's Activation rate is strong but Retention is poor, what does that signal about where to focus product investment — and what data would you gather to confirm it?
- How would you combine Doerr's OKR cadence with Croll's analytics stages to build a quarterly planning process that is both aspirational and grounded in real user behavior data?
- Croll warns against vanity metrics. Using examples from Lean Analytics, how do you distinguish a vanity metric from an actionable one, and can you identify a vanity metric you or your team currently tracks?
- OKR Writing Sprint: Draft a full OKR set for a real or hypothetical product — 1 company-level Objective, 2 team-level Objectives, each with 3 Key Results. Score each KR against Doerr's criteria (specific, measurable, time-bound, aggressive yet realistic). Revise until every KR passes.
- Metric Audit: List every metric your team (or a product you admire) currently tracks. Classify each as 'vanity' or 'actionable' using Croll's definitions. Then apply the OMTM filter: if you could only watch one metric for the next 30 days, which would it be and why?
- Funnel Mapping Exercise: Draw a full AARRR funnel for a product you use daily. Estimate (or look up) rough conversion rates at each stage. Identify the single biggest drop-off point and write a one-paragraph hypothesis — grounded in Croll's framework — about its root cause and a testable fix.
- Lean Analytics Stage Diagnosis: Choose a product (your own or a case study). Using Croll's five stages, argue which stage it is currently in, cite the evidence (metrics, user behavior), and define what 'graduating' to the next stage would look like in measurable terms.
- OKR ↔ Metrics Alignment Map: Create a one-page visual that connects a company's top OKRs (structured per Doerr) to the corresponding Lean Analytics funnel metrics (per Croll). Draw explicit arrows showing how movement in a funnel metric would move a Key Result.
- Stretch vs. Committed Goal Debate: Pick one Key Result you wrote in Exercise 1. Rewrite it twice — once as a committed goal and once as a moonshot stretch goal. Write a short justification (3–5 sentences) for which version is more appropriate given the product's current stage from Lean Analytics.
Next up: Mastering OKRs and analytics stages gives you the strategic and measurement vocabulary needed to tackle the next stage, where you'll learn how to translate that vision and data into prioritized roadmaps, stakeholder alignment, and execution frameworks that turn strategy into shipped product.
Introduces OKRs (Objectives and Key Results), the goal-setting system used by Google, Intel, and many product-led companies; teaches you how to translate strategy into measurable team commitments.
Provides a stage-by-stage framework for choosing the one metric that matters most at each phase of a product's life; builds the data fluency needed before tackling advanced strategy.
Advanced Mastery: Strategy, Leadership & Influence
Going deepThink and operate at the strategic and organizational level — setting multi-year vision, influencing without authority, building PM teams, and compounding product advantages.
▸ Study plan for this stage
Pace: 8–10 weeks total: Weeks 1–5 for "Empowered" (~25–30 pages/day, including reflection time after each chapter cluster); Weeks 6–10 for "Good Strategy, Bad Strategy" (~20–25 pages/day, with slower pacing to deeply analyze Rumelt's case studies and strategy critiques).
- Empowered product teams vs. feature teams — Cagan's core distinction between teams given problems to solve vs. teams given features to build, and why it changes everything about outcomes
- The role of product leadership — how VP/CPO-level leaders set context, coach product managers, and create the conditions for innovation rather than just managing output
- Product vision and product strategy as distinct artifacts — Cagan's framework for a compelling multi-year product vision cascading into team-level strategies and OKRs
- Coaching and developing strong PMs — Cagan's emphasis on hiring for character, then investing heavily in growing product sense, technical depth, and business acumen
- Influence without authority — how senior PMs and leaders align engineering, design, data, marketing, and executives around a shared product direction without direct control
- Rumelt's 'Kernel of Strategy' — the three-part structure of diagnosis, guiding policy, and coherent actions as the anatomy of genuinely good strategy
- The hallmarks of bad strategy — Rumelt's identification of fluff, failure to face the challenge, mistaking goals for strategy, and bad strategic objectives that plague most organizations
- Compounding advantage through strategic leverage — Rumelt's concept of identifying and exploiting pivotal factors and proximate objectives to create durable competitive advantages
- According to Cagan in 'Empowered,' what is the fundamental difference between an empowered product team and a feature team, and what organizational conditions must exist for empowered teams to thrive?
- How does Cagan define the responsibilities of a strong product leader, and how do those responsibilities differ from those of an individual contributor senior PM?
- What does Rumelt mean by the 'kernel of strategy,' and can you construct one — diagnosis, guiding policy, coherent actions — for a real or hypothetical product?
- How does Rumelt distinguish between a strategic goal and an actual strategy, and why does he argue that most corporate 'strategies' are really just lists of aspirations?
- Drawing on both books, how would you craft a multi-year product vision (Cagan) and then stress-test it using Rumelt's good/bad strategy framework to ensure it has real strategic substance?
- How do the leadership and influence principles in 'Empowered' connect to Rumelt's idea that good strategy requires a leader willing to make hard, focused choices and say no to competing priorities?
- Vision stress-test: Write a 1-page product vision for your current or target product, then apply Rumelt's kernel framework — explicitly write the diagnosis, guiding policy, and coherent actions. Identify where your vision is fluffy or goal-like rather than strategic, and revise.
- Feature team audit: Map out your current team's actual work for the last quarter. Classify each initiative as 'empowered problem' vs. 'feature request.' Calculate the ratio, identify the root causes of feature-team dynamics, and draft a proposal to shift one initiative toward the empowered model.
- Bad strategy hall of fame: Collect 3 real strategy documents (company all-hands decks, OKR docs, roadmaps) and annotate them using Rumelt's bad strategy hallmarks — fluff, no diagnosis, goals masquerading as strategy. Write a one-paragraph rewrite of each using the kernel.
- PM coaching plan: Using Cagan's coaching framework from 'Empowered,' assess one PM (or yourself) across the dimensions of product sense, technical depth, and business acumen. Write a concrete 90-day development plan with specific activities, feedback loops, and success criteria.
- Influence mapping exercise: For a strategic initiative you care about, draw a stakeholder influence map — list every key decision-maker and influencer, their current stance, their motivations, and a specific influence tactic (rooted in Cagan's principles) for each. Execute at least two of those tactics and journal the outcomes.
- Competitive leverage analysis: Choose a product in your domain and apply Rumelt's concept of strategic leverage — identify the one or two pivotal factors in the competitive landscape, then design a coherent set of product bets that concentrate force on those factors rather than spreading effort evenly.
Next up: Mastering empowered team design and rigorous strategy formulation from these two books equips the reader to move into execution at scale — understanding how to sustain strategic clarity, manage organizational complexity, and measure compounding product impact over time in the next stage of the curriculum.
Cagan's follow-up to Inspired focuses on how to build and lead outstanding product teams; the natural capstone after mastering individual PM craft, shifting your lens from 'how do I do PM' to 'how do I scale it'.
The definitive book on what strategy actually means — diagnosis, guiding policy, coherent actions — and how to spot the fluffy 'bad strategy' that plagues most roadmaps; elevates your thinking to the executive level.