Intro
Product
Product thinking for engineers — discovering real problems, measuring what matters, experimenting, growing and pricing.
- 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.
- Product thinking for engineers — outcomes over output, the product trio and Cagan's four risks
- Finding problems worth solving — intensity, frequency, willingness to pay
- Jobs to be done — what customers hire a product for, and who you really compete with
- User research — Mom Test interviews, usability tests, synthesis
- Continuous discovery and assumption testing — weekly contact, opportunity solution trees, cheap tests
Strategy and planning
Turn discovery into choices: where to play, what to build next and how to scope it.
- Product strategy and positioning — vision, strategy, differentiation
- Prioritization — RICE, ICE, Kano, cost of delay
- PRDs, PR/FAQs and specs — docs that align teams without freezing discovery
- Roadmaps and OKRs — outcome-based plans, now/next/later
- MVPs and scoping — smallest test of the riskiest assumption
Metrics and experimentation
Measure what matters and learn with controlled experiments.
- Product metrics and the north star — north star, inputs, guardrails, vanity traps
- Product analytics — events, funnels, cohorts, SQL for product questions
- A/B testing and experimentation — design, size and analyze tests correctly
- Experimentation pitfalls — peeking, SRM, novelty, interference
Growth and monetization
Keep users, grow the base and capture value.
- Activation and onboarding — aha moments and time-to-value
- Retention and engagement — cohort curves and why retention underpins growth
- Growth loops and acquisition — funnels vs loops, virality, referrals
- Pricing and packaging — value metrics, tiers, freemium vs trials
- Product-led vs sales-led growth — self-serve, sales and hybrids
Shipping and specialties
Launch well, iterate and apply product craft to platforms, AI and interviews.
- Launching products and features — tiers, betas, measuring launch success
- Iteration and feedback loops — support, data and kill decisions
- Developer and API products — DX, docs and API adoption
- AI product strategy — what to build, defend, price and evaluate
- Product sense interviews — structured answers to design and metrics prompts
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.
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.