Guide
Sections
5
Pages
128
Reading time
~5 h
Take first
Nothing

What you will be able to do

  • Separate problems from solutions and run user interviews that produce honest, usable evidence.
  • Turn discovery into a strategy, a prioritized roadmap and a crisp PRD or PR/FAQ.
  • Define a north star metric and input metrics, instrument events and answer product questions with SQL and funnels.
  • Design, size and analyze an A/B test, and avoid peeking, SRM and other common errors.
  • Diagnose activation and retention problems with cohort curves and design growth loops.
  • Choose a pricing model and value metric, and decide between product-led and sales-led go-to-market.
  • Launch features well and answer product sense interview questions with structure.

The best engineers understand why they are building something, not just how. A well-designed service that nobody needs is still a failure. A mediocre prototype that proves a hair-on-fire problem is progress. This topic is product thinking from an engineer's seat: finding problems worth solving, turning discovery into strategy and specs, defining metrics, running honest experiments, and driving activation, retention and growth — including pricing, go-to-market shape, launches and the product sense interview.

It pairs with Startups, which covers the business economics around the product (unit economics, burn, markets). It overlaps Career on how you collaborate with PMs and designers day to day. Use these pages when you want to own outcomes, not just tickets.

You will leave able to separate problems from solutions, run interviews that produce honest evidence, shape a roadmap around outcomes, define a north star with guardrails, design a sound A/B test, diagnose activation and retention, reason about pricing and go-to-market, and answer product sense prompts with structure — the outcomes listed for these pages, practiced against real work rather than memorized.

Who this is for

You are a junior or mid-level engineer who ships features and wants to understand whether those features matter. You may work with a PM, or you may be the closest thing to one on a small team. You do not need a product title. You need the habit of asking: what problem, for whom, and how will we know?

If you are founding or joining an early startup, read this alongside startup ideas and product-market fit. If you build AI features, the later pages on AI product strategy and AI product UX connect discovery to evals and UX.

How to study it

Read against a live product. After problems worth solving, score three ideas your team has debated. After user research, sit in on one support call or customer interview this week. After product metrics, write down your team's north star and whether anyone actually watches it.

Do not treat Further learning as a syllabus to finish. Pull one book or talk when a page is thin relative to a decision you face. Practice beats passive reading: a bad interview you ran teaches more than three articles about interviewing.

Pace: discovery and strategy pages first if you are fuzzy on "why we build." Metrics and experiments when you have traffic worth measuring. Growth and monetization when retention or pricing is the bottleneck. Shipping and specialties when you launch, build platforms or interview for product-adjacent roles.

Hands-on beats highlights. Keep a running note of one problem statement, one metric definition and one experiment idea tied to your team's actual product. Update that note as you read; by the end of discovery and metrics units you should have something you could paste into a design doc.

Unit roadmap

The numbered list is a shorter path. The sections below are every lesson: 128 in all, about 5 hours of reading.

Product thinking and discovery

Separate problems from solutions, and gather evidence before you write code.

Strategy and planning

Turn discovery into choices: where to play, what to build next and how to scope it.

Metrics and experimentation

Measure what matters and learn with controlled experiments.

Growth and monetization

Keep users, grow the base and capture value.

Shipping and specialties

Launch well, iterate and apply product craft to platforms, AI and interviews.

Course resources

Marty Cagan's Inspired is the canonical framing of empowered product teams, discovery vs delivery and the four risks. His SVPG articles are free and worth bookmarking.

SVPG articles (Marty Cagan)A partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group

Teresa Torres's Continuous Discovery Habits and Product Talk blog are the practical operating system for weekly customer contact and opportunity solution trees.

Product Talk (Teresa Torres)Learn a structured and sustainable approach to building great products from Teresa Torres and the rest of the Product Talk team.Product Talk

Rob Fitzpatrick's The Mom Test is the shortest, sharpest guide to customer conversations that do not lie to you.

The Mom Test (Rob Fitzpatrick)How to talk to customers & learn if your business is a good idea when everyone is lying to you.The Mom Test

Lenny Rachitsky's newsletter and podcast are the best ongoing feed of practitioner product advice (growth, retention, PM craft) as of 2025–2026.

Lenny's NewsletterDeeply researched product, growth, and career advice for product leaders, founders, and ambitious builders. Click to read Lenny's Newsletter, a Substack publication with millions of subscribers.lennysnewsletter.com

Marty Cagan on Lenny's Podcast is a clear hour on what great product teams actually do — discovery, strategy and empowerment — without process theater.

The nature of product | Marty Cagan, Silicon Valley Product GroupLenny's Podcast

Product thinking and discovery

Outcomes vs output

Shipping is output. Outcomes are changes in user or business behavior. The build trap is optimizing the first and ignoring the second.

Four product risks

Every failed product fails at least one of value, usability, feasibility or viability. Name the biggest risk before you write code.

Product thinking for engineers

Outcomes over output — why engineers who understand users and business build better software. Start here for the map.

The product trio

A PM, a designer and an engineer share outcomes. Discovery is shared work, not a handoff, and product management is not project management.

Product-minded engineers

Ask what problem, for whom and how you will know — then reshape the solution, cut scope to keep the outcome and watch the numbers after ship.

Problem vs solution

Fall in love with the struggle, not the dashboard. Solutions are disposable; the pain is not.

Finding problems worth solving

Pain intensity, frequency and willingness to pay — separating hair-on-fire problems from nice-to-haves.

Scoring problems

Intensity, frequency, workarounds and willingness to pay — the filter between hair-on-fire and nice-to-have.

Where problems come from

Mine support, sales, analytics, dogfooding and observation. Cross-check before a request becomes strategy.

Problem statements

Who, the job, the obstacle, the cost, the workaround, the evidence — then a hypothesis that can fail.

What is a job to be done

People hire a product to make progress in a circumstance — not to buy a feature list or a demographic label.

Jobs to be done

What customers hire a product to do — and how JTBD reframes competition and features.

Forces of progress

Push and pull move people toward a new product. Anxiety and habit hold them. Great products fail when the last two win.

Switch interviews

Reconstruct the last time someone hired or fired a product. Past timelines beat hypothetical "would you switch?"

Job stories

When circumstance, I want progress, so I can outcome. A usable job statement you can design and cut scope against.

The Mom Test

Talk about their life, not your idea. Ask about the past, not the future. Compliments are false positives; past behavior and money already spent are not.

User interviews

Recruit the segment in your problem statement, run a 30-minute script that stays in their world and take notes in their words. Five to eight good interviews beat fifty mediocre surveys.

User research

Interviews that avoid false positives, usability tests with five users, and synthesizing findings. Start here for the map.

Usability testing

Give realistic tasks, ask people to think aloud and do not help until they are stuck. About five users find most issues in a given design; then fix and retest.

Research synthesis

Affinity-map quotes into observations, insights and ideas — in separate columns. An insight is surprising, grounded in multiple data points and actionable.

Opportunity solution trees

A living map from outcome to opportunities to solutions to tests — so you compare ideas under the same customer need.

Continuous discovery and assumption testing

Weekly customer contact, opportunity solution trees and cheap tests before building.

Riskiest assumptions

State what must be true for an idea to work, then test high-hurt and high-uncertainty beliefs first.

Cheap discovery tests

Fake doors, concierge, Wizard of Oz and prototypes — spend days, not months, to see if an assumption holds.

A week of discovery

One outcome, two interviews, one cheap test, a kill criterion and a Friday decision — no production feature required.

Strategy and planning

Vision vs strategy vs roadmap

Vision is the destination. Strategy is a focused bet under constraint. Roadmaps and tactics execute. Do not mix the four layers.

Rumelt's strategy kernel

A good strategy has a diagnosis, a guiding policy and coherent actions. Fluff, goal-lists and twelve "priorities" are not strategy.

Product strategy and positioning

Vision, strategy, positioning and differentiation: deciding where to play and how to win. Start here for the map.

Product positioning

Position from the alternative customers already use, not from the category you wish you were in. Dunford's five components, in order.

The strategy one-pager

If the strategy does not fit on one page, it is not focused enough to execute. Include non-goals and how you will know.

Opportunity cost

The real price of a yes is the best alternative you did not ship.

RICE scoring

Reach × Impact × Confidence ÷ Effort — a comparable score that structures debate, not a verdict.

Prioritization

RICE, ICE, Kano, cost of delay and opportunity cost: choosing what not to build.

ICE, Kano and cost of delay

Faster scoring when reach is similar, categories of need, and how much waiting costs per week.

Capacity allocation

Reserve capacity for growth, commitments, reliability and debt so incidents are not the only planning process.

Cheaper versions

Engineers win prioritization with honest effort, thinner slices, and a written reason when they override a score.

Writing a PRD

A short doc that answers problem, users, metrics, non-goals and P0 behavior — sized to the bet.

Requirements vs specs

Product owns observable behavior. Engineering owns how it is built. Mixing them too early locks the wrong decisions.

PRDs, PR/FAQs and specs

Writing product requirement docs and Amazon-style PR/FAQs that align teams.

PR/FAQ and working backwards

Write the press release as if the product shipped. If you cannot make a customer care, kill the idea cheaply.

Acceptance criteria

Turn P0 requirements into testable conditions, including the edge cases that bite in production.

Living PRDs

Right-size the doc, mark status, publish a changelog, and pair it with an eng design doc for the how.

Outcome roadmaps

A roadmap tells the organization which problems you will solve, in what rough order. It is not a Gantt contract of seventeen features by March 31.

Now / next / later

Three columns that communicate sequence and uncertainty without fake dates. Outcomes on top, bets underneath, Later without a calendar.

Roadmaps and OKRs

Outcome-based roadmaps, now/next/later, and OKRs that guide rather than constrain. Start here for the map.

Writing OKRs

Objectives are qualitative aims. Key results are measurable evidence — typically 2–4 per objective. Ship lists, sandbagging and fake cascades are not OKRs.

Roadmap capacity

Partition capacity so sales commitments and discovery coexist without lying. Plan the quarter from strategy plus eng-weeks, and leave slack.

Riskiest assumption

An MVP tests the belief that, if false, kills the idea — written so it can fail.

Types of MVP

Concierge, Wizard of Oz, single-feature wedge, or glued tools — pick the cheapest honest signal.

MVPs and scoping

Building the smallest thing that tests the riskiest assumption, and iterating.

Appetite and shaping

Fix the time, vary the scope: how much is this idea worth, not how long will it take.

Cutting scope

Cut personas, surfaces and polish first. Never cut the aha, trust basics, or instrumentation.

Pivot, persevere, or kill

Pre-declare the signals that mean continue, change the job, or stop — a clean kill is a successful MVP.

Metrics and experimentation

The north star metric

One number that captures customer value, tends to lead revenue and that teams can actually move. Write it as a count of actors doing a valuable action.

Metric trees

Break the north star into 3–5 input metrics teams own. When the star is flat, diagnose which factor stalled instead of shipping random features.

Product metrics and the north star

Choosing a north star that reflects customer value, decomposing it into input metrics teams own, and pairing it with guardrails. Start here for the map.

Guardrails and vanity metrics

Pair every primary metric with 2–4 guardrails so you cannot silently destroy trust. Vanity metrics move easily and do not change what you build next week.

AARRR and leading metrics

Pirate metrics map the journey. They do not replace a north star. Prefer metrics that move in weeks over ones that only confirm last quarter.

Event tracking plans

Name events as object_action, merge anonymous identity in the first session and treat the tracking plan as a contract. Bad events in a fancy UI stay bad.

Product funnels

A funnel is an ordered sequence of events for the same actor. Conversion multiplies across steps, so size each lever with arithmetic before debating features.

Product analytics

Designing event tracking plans, reading funnels and cohorts, writing the SQL that answers product questions, and avoiding mix-shift illusions. Start here for the map.

Simpson's paradox in mix shift

Every segment can get worse while the overall rate improves, because more traffic came from the high-converting segment. Segment before you celebrate.

Analytics SQL and debugging

A few warehouse shapes — DAU, windowed funnels, cohort retention — answer most product questions. When a number looks wrong, check definition, deploy, identity and mix before rewriting the query.

Randomization and causality

Why a dashboard cannot tell you what caused a change, and how random assignment isolates the effect of a product tweak.

Designing an experiment

Write the hypothesis, primary metric, guardrails, unit and exposure definition before anyone looks at a p-value.

A/B testing and experimentation

Designing randomized experiments, sizing samples with real arithmetic, reading lift and confidence intervals, and shipping only what the data actually supports.

Sample size for A/B tests

How many users you need, why tiny lifts demand huge traffic, and how to pick an MDE you would actually ship on.

Reading A/B test results

Lift, confidence intervals and p-values, and why a significant result can still be the wrong ship.

Peeking at experiments

Checking the p-value daily and shipping when it dips below 0.05 inflates false positives from 5% into the teens or worse.

Metric fishing

Test 20 metrics and something will be "significant." Ship on one pre-registered primary, and treat the rest as leads.

Experimentation pitfalls

Peeking, metric fishing, sample ratio mismatch, novelty effects, network interference, CUPED and Twyman's law — how trustworthy experiments go wrong and how to catch them.

Sample ratio mismatch

If you asked for 50/50 and observe 48/52 on a large sample, stop. The experiment is invalid until you explain the split.

Novelty and interference

Day-one spikes fade, and my treatment can change your outcome. Short tests and independent-user math both lie here.

CUPED

Subtract the predictable part of a metric using pre-experiment data. You get the same MDE with less traffic — if the experiment was valid.

Growth and monetization

Aha moments

Activation is the early action that predicts retention — found with cohort analysis, not a brainstorm.

Activation and onboarding

Aha moments, time-to-value and onboarding flows that turn signups into active users.

Time to value

How long a new user waits to feel the outcome they came for — and the patterns that shrink that wait.

Onboarding patterns

Checklists, empty states, tours and walkthroughs — which surfaces actually move people toward value.

Activation funnels

Treat activation as a queryable funnel, find the biggest leak, and experiment there with retention as the guardrail.

The leaky bucket

Acquisition without retention only scales the leak. Improving churn compounds; buying more traffic does not change the hole in the bucket.

Retention curves

Three shapes matter — decay to zero, flatten above zero, smile. Flattening is the product-market-fit signal. Compare cohorts, not blended actives.

Retention and engagement

Retention curves, cohort analysis, DAU/MAU and why retention is the foundation of growth. Start here for the map.

Engagement metrics

Retention asks whether they come back. Engagement asks how deeply they use it. DAU/MAU, L7 and power-user curves only work if you match the product's natural frequency.

Retention levers

Habit loops, careful notifications, resurrection, critical-path quality and — for paid products — splitting voluntary vs involuntary churn. Diagnose the curve before you add an engagement feature.

Funnels vs loops

Funnels diagnose steps. Loops explain where the next user comes from — the output of one cycle becomes the input of the next.

Growth loops and acquisition

Funnels vs loops, virality math, content and paid loops, and referral programs.

K-factor

K = invites per user × conversion. Below 1 still cuts CAC. Cycle time sets how fast generations stack.

Types of growth loops

Content, paid, sales and collaboration loops fit different products. Network effects amplify a loop; they are not themselves a loop.

Referral programs

A designed viral loop. Ask activated users, reward in-product currency, measure retention — and budget for fraud.

Value metrics

Charge for a unit that grows with customer value and with your cost to serve.

Good-better-best packaging

Three tiers so buyers self-segment. Gate admin and scale, not the aha.

Pricing and packaging

Value metrics, tiers, freemium vs trials, usage-based pricing and how to test prices.

Freemium vs trials

Free forever when free users create distribution. Time-boxed trials when each free account is expensive to serve.

Usage-based pricing

Bills that scale with consumption, plus the metering UX that stops a surprise invoice from destroying trust.

Willingness to pay

Survey ranges, interviews, and careful tests — then grandfather existing customers when you raise prices.

Product-led growth

The product acquires, converts and expands. Sales does not create demand from zero for every deal.

Sales-led growth

Humans drive the path to revenue when ACV and buying complexity can pay for their time.

Product-led vs sales-led growth

When self-serve wins, when you need a sales team, and how hybrids work.

Product-qualified leads

Usage predicts buy intent. Sales arrives with context, instead of restarting from a cold form fill.

GTM and the roadmap

PLG prioritizes activation and billing. Sales-led prioritizes SSO, audit logs and SE tooling. Hybrids need both.

GTM failure modes

Two funnels that do not talk, sales habits inside a PLG product, and comp plans that fight the motion.

Shipping and specialties

Launch tiers

Match launch ceremony to blast radius, not to how hard the code was.

Alpha and beta

A bounded group of users who find cliffs before you spend the marketing budget.

Launching products and features

Launch tiers, betas, checklists and measuring whether a launch worked.

Soft launch and percentage rollout

Make the feature available, learn from real load, and spend the marketing budget only after the path works.

Launch checklists and runbooks

A go/no-go gate across engineering, docs, support and GTM, plus a one-page launch-day clock.

Measuring launches

Write success metrics and guardrails before launch day, then double down, iterate or sunset.

Feedback channels

Every channel lies in a different way. Combine support, in-app, sales and behavior — never let volume from one source set the roadmap.

Iteration and feedback loops

Turning feedback, support tickets and data into continuous improvement and kill decisions.

Quantifying feedback

A lightweight taxonomy plus counts and a linked metric turns anecdotes into decisions — and stops you staffing the wrong team.

Closing the feedback loop

Tell people what you did with their input — shipped, planned, or no — or they stop talking and you lose the channel.

Iterate or kill

Double down, iterate, or sunset. Killing is underused. Endless polish on a bad bet is overused.

Developer experience

Developers adopt a path from curiosity to production, measured in time-to-first-call, not endpoint count.

API design as UX

Resource names, errors, versioning and webhooks are the interface. Prefer additive compatibility.

Developer and API products

Treating APIs, SDKs and docs as products: developer experience and adoption.

SDKs, quickstarts and docs

Raw HTTP is the contract. The kit around it — snippets, guides, samples, CLI — is how most people integrate.

Developer funnels

A north star that reflects production value, and the cliffs between signup, first call and live traffic.

API pricing and rate limits

Meter names people understand, a free tier that reaches aha, and 429s that come with docs and a dashboard.

When AI fits

Pick jobs with high value, tolerable errors and a verifier. Skip demos that cannot be checked.

Copilot vs agent vs automation

Positioning is a product choice. Assist, act with tools, or run in the background — each implies different UX and liability.

AI product strategy

What to build with AI, how to defend it, how to price it, and how evals become product requirements.

Evals as product specs

If you cannot define good, you cannot ship. An eval set is how quality becomes a requirement instead of a vibe.

AI product economics

Inference COGS can invert a seat price. Meter recognizable work, not tokens, and cap the power users.

AI product moats

Foundation models commoditize. Defend with workflow, data, integrations and distribution — not a clever prompt.

Product sense framework

Clarify, pick a north star, segment, name one pain, generate three distinct solutions, then choose an MVP with metrics. Interviewers reward decisions, not idea lists.

Product sense interviews

Structured answers to product design, improvement and metrics questions. Start here for the map.

Diagnosing a DAU drop

Verify the dashboard, scope the cut, split acquisition vs retention, then rank hypotheses. Jumping to a home-feed redesign is how candidates fail.

Product sense practice

Judgment is choosing and cutting. Use company-native strengths, timed mocks and weekly 15-minute app critiques — not cramming frameworks the night before.