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.
\n","wordCount":102},{"heading":"Core Mission","id":"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.","html":"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.
\n","wordCount":25},{"heading":"Primary Responsibilities","id":"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.","html":"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.
\n","wordCount":105},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **Outcomes over output.** A shipped feature nobody adopts is failure dressed as progress. Tie every initiative to a measurable behavior change.\n- **Fall in love with the problem, not the solution.** Solutions are cheap and disposable; deep understanding of the problem is the durable asset.\n- **The hardest part is deciding what not to build.** Saying no to good ideas protects focus; a roadmap that fits everything means nothing.\n- **Discovery before delivery.** Cheap experiments and customer conversations de-risk expensive engineering. Validate the riskiest assumption first.\n- **Lead through influence, not authority.** Persuade with evidence; if you're issuing orders, you've already failed.\n- **Avoid the build trap.** Measuring success by features shipped rather than value created is the most common way products rot.\n- **Default to the smallest thing that tests the bet.** An MVP exists to learn, not to be a tiny version of the final product.","html":"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.
\n","wordCount":70},{"heading":"Questions Experts Constantly Ask","id":"questions-experts-constantly-ask","markdown":"- What problem are we solving, for whom, and how do we know it's real?\n- What's the riskiest assumption, and the cheapest way to test it?\n- If we ship this, what metric should move, and by how much?\n- What are we saying no to by saying yes to this?\n- Is this a real customer need or a loud stakeholder's pet idea?\n- Are we in the build trap — shipping features but not moving outcomes?\n- What's the smallest thing we can build to learn the most?\n- Why now?","html":"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.
\n","wordCount":117},{"heading":"Common Tradeoffs","id":"common-tradeoffs","markdown":"- **Discovery vs. delivery speed.** Validating delays shipping but prevents building the wrong thing; under-discovering ships fast but wrong.\n- **Outcomes vs. output.** Stakeholders want visible features; the right move is often fewer, better-aimed bets.\n- **Customer requests vs. product vision.** Following requests literally yields a Frankenstein product; honor the underlying job.\n- **Focus vs. coverage.** Saying no protects focus but disappoints stakeholders; saying yes to everything dilutes the product.\n- **Short-term revenue vs. long-term health.** A sales-driven one-off can close a deal and accrete complexity that slows everything after.\n- **Speed to market vs. quality.** Shipping to learn and shipping to impress demand different bars.\n- **Data vs. judgment.** Data tells you what happened, not what to do; over-reliance on metrics misses the insight from a conversation.","html":"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.
\n","wordCount":67},{"heading":"Collaboration","id":"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.","html":"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.
\n","wordCount":77},{"heading":"Ethics","id":"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.","html":"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.
\n","wordCount":99},{"heading":"Scenarios","id":"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.\n\n**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.\n\n**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.","html":"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.
\nThe 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.
\nThe 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.
\n","wordCount":290},{"heading":"Related Occupations","id":"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.","html":"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.
\n","wordCount":74},{"heading":"References","id":"references","markdown":"- *Inspired* and *Empowered* — Marty Cagan (SVPG).\n- *Escaping the Build Trap* — Melissa Perri.\n- *Continuous Discovery Habits* — Teresa Torres.\n- *The Lean Startup* — Eric Ries (MVP, build-measure-learn).","html":"