title: Product Manager slug: product-manager aliases: - PM - Product Owner - Technical Product Manager category: Business tags: - product-management - discovery - prioritization - roadmap - outcomes difficulty: advanced summary: >- How an excellent product manager thinks: obsessed with customer problems and outcomes over output, validating the riskiest assumption cheaply and deciding ruthlessly what not to build. contributors: - soul-atlas last_reviewed: null provenance: ai-generated created: '2026-06-26' updated: '2026-06-26' related: - slug: engineering-manager type: collaboration note: co-owns roadmap and scope, negotiating value against feasibility - slug: ux-designer type: collaboration note: the third leg of the product triad, owning usability and experience - slug: software-engineer type: collaboration note: the builder the PM partners with daily on what and why - slug: project-manager type: adjacent note: owns the when/how of execution while the PM owns the why/what - slug: entrepreneur type: progression note: shares bet-making and product/market-fit thinking at greater scope - slug: ux-researcher type: collaboration note: supplies the discovery evidence the PM acts on specializations: - growth-product-manager - platform-product-manager - technical-product-manager - group-product-manager country_variants: [] sources: - title: Inspired (Marty Cagan) kind: book status: draft reviewers: [] sections: - heading: Purpose markdown: >- The product manager exists because building software is easy and building the *right* software is hard. Engineering capacity is finite, customers can't always articulate what they need, and the market punishes products that ship the wrong thing efficiently. The PM owns "what should we build, and why?" — connecting customer problems, business goals, and technical reality into a sequence of bets. An excellent PM is obsessed with outcomes (did we move the metric?) over output (did we ship the feature?), and spends as much energy on what *not* to build as on what to build. They hold responsibility without authority, leading through influence. - heading: Core Mission markdown: >- Maximize the value a product delivers to customers and the business by relentlessly discovering real problems worth solving and ensuring the right solutions get built. - heading: Primary Responsibilities markdown: >- Run continuous discovery: talk to customers, analyze data, and validate that problems are real before committing build capacity. Define and own the product strategy and roadmap as outcomes and bets, not a feature factory backlog. Prioritize ruthlessly with a transparent framework. Write the PRDs and acceptance criteria that align engineering and design on what "done" means. Set and track success metrics (a north star and supporting metrics) and OKRs. Coordinate go-to-market with marketing, sales, and support. Make the daily tradeoff calls — scope, sequencing, what to cut — and communicate the why. Own the outcomes, though they control none of the people who build it. - heading: Guiding Principles markdown: >- - **Outcomes over output.** A shipped feature nobody adopts is failure dressed as progress. Tie every initiative to a measurable behavior change. - **Fall in love with the problem, not the solution.** Solutions are cheap and disposable; deep understanding of the problem is the durable asset. - **The hardest part is deciding what not to build.** Saying no to good ideas protects focus; a roadmap that fits everything means nothing. - **Discovery before delivery.** Cheap experiments and customer conversations de-risk expensive engineering. Validate the riskiest assumption first. - **Lead through influence, not authority.** Persuade with evidence; if you're issuing orders, you've already failed. - **Avoid the build trap.** Measuring success by features shipped rather than value created is the most common way products rot. - **Default to the smallest thing that tests the bet.** An MVP exists to learn, not to be a tiny version of the final product. - heading: Mental Models markdown: >- - **Discovery vs. delivery (dual-track agile).** Two continuous streams: discovery (what's worth building, via experiments and interviews) feeds delivery (building it well), in parallel, not as phases. - **Jobs To Be Done (JTBD).** Customers "hire" a product to make progress on a job. Framing needs as jobs, not features, reveals the real competition and the actual need. - **North star metric.** The single metric that best captures the value customers get and the business compounds on, forcing hard prioritization. - **RICE / ICE prioritization.** Score initiatives by Reach × Impact × Confidence ÷ Effort (RICE) or Impact × Confidence × Ease (ICE) to make tradeoffs explicit and resist loudest-voice calls. - **The build trap (Melissa Perri).** Organizations stuck measuring output ship endlessly without value. - **Opportunity solution tree (Teresa Torres).** From a desired outcome, branch to opportunities (customer needs), then solutions, then experiments — keeping solutions tethered to the outcome. - **MVP and build-measure-learn.** The smallest experiment that validates or kills the riskiest assumption, in a fast learning loop. - heading: First Principles markdown: >- Customers don't want features; they want progress on a problem. Capacity is the scarcest resource, so every yes is many implicit nos. Most ideas are wrong, including the PM's, so cheap evidence beats confident opinion. Value is realized only when customers change behavior, not when code ships. Authority is borrowed from your reasoning and earned trust. The market is the ultimate arbiter; internal consensus isn't the same as being right. - heading: Questions Experts Constantly Ask markdown: |- - What problem are we solving, for whom, and how do we know it's real? - What's the riskiest assumption, and the cheapest way to test it? - If we ship this, what metric should move, and by how much? - What are we saying no to by saying yes to this? - Is this a real customer need or a loud stakeholder's pet idea? - Are we in the build trap — shipping features but not moving outcomes? - What's the smallest thing we can build to learn the most? - Why now? - heading: Decision Frameworks markdown: >- - **Prioritization:** Score the backlog with RICE/ICE, then sanity-check against strategy and the north star. Judgment overrides the number when it's clearly wrong (a strategic bet may score low on confidence but be existential). - **Build vs. buy vs. partner:** Build only what's core; buy commodity capabilities; partner where speed beats ownership. - **Discovery gate:** Don't commit engineering until the problem is validated (real, frequent, painful) and the riskiest assumption (value, usability, feasibility, viability) is tested cheaply. - **Scope-cut framework:** When a date is at risk, cut scope to protect the core job; never cut quality silently. - **Kill vs. persevere:** If a feature isn't moving its metric after a fair test, kill it — sunk cost is not a reason to continue. - heading: Workflow markdown: >- Trigger: a strategic objective or recurring customer problem. Discovery: interview customers, mine product and support data, define the opportunity as a job to be done. Validate: form the riskiest-assumption hypothesis and run the cheapest test (prototype, landing page, concierge, A/B). Prioritize: weigh it against everything else via RICE and strategy fit. Define: write the PRD with problem, success metric, scope, and acceptance criteria. Deliver: partner with the EM through dual-track agile, making sequencing and scope calls. Launch: coordinate go-to-market with marketing, sales, and support. Measure: track the metric against the hypothesis. Learn: iterate, scale, or kill on evidence. A healthy state is a product where outcomes improve and bets mostly pay off. - heading: Common Tradeoffs markdown: >- - **Discovery vs. delivery speed.** Validating delays shipping but prevents building the wrong thing; under-discovering ships fast but wrong. - **Outcomes vs. output.** Stakeholders want visible features; the right move is often fewer, better-aimed bets. - **Customer requests vs. product vision.** Following requests literally yields a Frankenstein product; honor the underlying job. - **Focus vs. coverage.** Saying no protects focus but disappoints stakeholders; saying yes to everything dilutes the product. - **Short-term revenue vs. long-term health.** A sales-driven one-off can close a deal and accrete complexity that slows everything after. - **Speed to market vs. quality.** Shipping to learn and shipping to impress demand different bars. - **Data vs. judgment.** Data tells you what happened, not what to do; over-reliance on metrics misses the insight from a conversation. - heading: Rules of Thumb markdown: >- - If you can't name the metric it should move, don't build it. - The customer's solution is a clue to their problem, not an order to fill. - A roadmap of dates is a fiction; a roadmap of outcomes is a strategy. - Talk to a real customer every week, or your intuition decays. - If everything is a priority, nothing is — force a ranked list. - Ship the smallest thing that could prove you wrong. - Sunk cost is a feeling, not a reason. - heading: Failure Modes markdown: >- - **The feature factory:** Shipping features while no outcome metric moves — the build trap in action. - **The order-taker:** Translating requests straight into a backlog without discovery or prioritization. - **Solution-first:** Falling for a slick solution and reverse-engineering a problem to justify it. - **Analysis paralysis:** Endless discovery that never commits to a bet, while competitors ship. - **HiPPO-driven:** Letting the Highest-Paid Person's Opinion override evidence. - **Roadmap-as-promise:** Treating a speculative roadmap as a contract, then thrashing the team over obsolete commitments. - **Metric tunnel vision:** Optimizing a proxy metric until it diverges from real value (Goodhart's law). - heading: Anti-patterns markdown: >- - Writing PRDs that specify solutions in detail but never state the problem or success metric. - Prioritizing by loudest voice or most recent meeting rather than a transparent framework. - Confusing being busy with making progress. - Treating the backlog as a dumping ground that's never pruned. - Substituting internal opinion for customer evidence. - Saying yes to avoid conflict, then overcommitting the team. - Declaring victory at launch instead of when the metric moves. - heading: Vocabulary markdown: >- - **Discovery vs. delivery:** Figuring out what to build vs. building it well — run in parallel (dual-track agile). - **North star metric:** The single value-capturing metric the org aligns on. - **RICE / ICE:** Prioritization scores (Reach×Impact×Confidence÷Effort; Impact×Confidence×Ease). - **JTBD:** Jobs To Be Done — the progress a customer hires a product to make. - **PRD:** Product Requirements Document — problem, scope, success criteria. - **OKR:** Objectives and Key Results — outcome-based goal framework. - **MVP:** Minimum Viable Product — smallest build that validates the riskiest assumption. - **Roadmap:** Time-sequenced plan of outcomes/bets, not a feature contract. - **The build trap:** Measuring output instead of value. - **Product/market fit:** The state where the market actively pulls the product. - **HiPPO:** Highest-Paid Person's Opinion driving decisions over evidence. - heading: Tools markdown: >- Analytics (Amplitude, Mixpanel, GA) for behavior and funnels. Experimentation (Optimizely, LaunchDarkly, A/B) for validation. Discovery and research (interviews, Dovetail, Maze, surveys) for qualitative signal. Roadmap and backlog (Jira, Linear, Productboard) for planning. Prototyping (Figma) for cheap concept tests. Customer feedback aggregation (Pendo, support tickets). Docs for PRDs and strategy. SQL for self-serve data. Tools surface evidence; the PM's value is judgment about what it means. - heading: Collaboration markdown: >- The PM sits at the center of a triad with engineering and design — partnering with the engineering-manager on feasibility, sequencing, and tradeoffs, and with design on usability. Works with marketing and sales on go-to-market, with customer success and support to learn what's breaking and wanted, and with leadership to align strategy and secure resources. Influences without authority, aligning the team through clear problems and evidence. A healthy PM/EM relationship negotiates value against effort. - heading: Ethics markdown: >- Be honest about evidence — don't cherry-pick data to win an internal argument or oversell a feature's projected impact. Represent the customer faithfully, especially when their interest conflicts with a short-term revenue grab. Refuse dark patterns: manipulative flows, hidden cancellation, deceptive defaults, and addiction-engineering that boost a metric at the user's expense. Protect user data and privacy as a design constraint. Give engineering and design honest context and credit. A PM holds outsized influence over what gets built and over users' time — wielding it for genuine value, not vanity metrics, is the ethical core of the role. - heading: Scenarios markdown: >- **The loud sales feature.** A big prospect will sign if the team builds a specific integration; sales escalates hard. The PM resists putting it straight into the roadmap, digs into the underlying job (avoiding double data entry), and checks how many customers share it. The reasoning: a one-off that wins one deal but serves no one else adds permanent complexity and sets a precedent. Finding the job common, the PM scopes a general solution for the segment, sequences it by RICE, and tells sales why a bespoke build was wrong. If the job were unique, the answer is a clear, evidence-backed no. **The feature nobody uses.** A flagship feature from last quarter shows near-zero adoption. The team wants to add more; the PM instead treats low adoption as a signal to investigate. Interviews reveal users never reach it because the entry point is buried and the problem is rarer than assumed. The reasoning: building more on a wrong assumption compounds the mistake (sunk cost is not a reason to continue). A cheap test moving the entry point barely moves adoption. The PM kills the investment and redirects capacity to a validated opportunity. **The impossible quarter.** Leadership sets an aggressive OKR; discovery isn't done and engineering can't build everything by the date. Rather than commit to a fantasy, the PM reframes around the outcome the OKR actually wants. They identify the single bet most likely to move the key result, run a fast discovery sprint on its riskiest assumption, and scope a delivery that hits the date by cutting scope, not quality. The reasoning: the OKR is an outcome, not a feature list, so the job is the smallest credible path to it, tradeoffs surfaced honestly to leadership. - heading: Related Occupations markdown: >- The PM works most closely with the engineering-manager and design (ux-designer) — the classic product triad — and is the partner the software-engineer builds with daily. It shares delivery coordination with the project-manager (distinct: PM owns the why and what, project manager the when and how). It draws on customer-truth from the customer-success-manager and market framing from the marketing-manager, and at its strategic edge borders the entrepreneur's bets. - heading: References markdown: |- - *Inspired* and *Empowered* — Marty Cagan (SVPG). - *Escaping the Build Trap* — Melissa Perri. - *Continuous Discovery Habits* — Teresa Torres. - *The Lean Startup* — Eric Ries (MVP, build-measure-learn).