A team ships a feature that took three months. It works, it is fast, and it passes every test. Six weeks later almost nobody uses it. In the retrospective everyone is puzzled, because nothing went wrong: the schedule held, the code was clean. What went wrong happened before the first line was written. Nobody had checked that anyone wanted it, that people could find it, that the company could afford to run it, or that it fitted the product's direction.
Someone on a product team owns that question. In many companies the person is called a product manager, or PM. The job is hard to describe because it has little formal power and no fixed deliverable. A PM does not write most of the code, draw the screens or sign the budget. The PM is answerable for whether the thing is worth having, and works through people who do the rest. This piece explains what the job is, where it came from, and how it bends in different places.
- Who takes it
- Part 1 of the Product Management minor, a short route that sits beside many majors. A minor here is not a degree of its own: it adds one skill to a degree. Pairs with: Computer Science, Business Administration, Marketing, Psychology. Business schools teach it as a product management elective, often in the second year of an MBA or a final year of a bachelor's, and short professional courses teach it to people who are already working. Engineering and design students meet it through capstone projects.
- What it is for
- Deciding what a team should build, and why, with evidence rather than opinion.
- Comes after
- Nothing is required. Helpful neighbours: Product Innovation & Go-to-Market (34/63) and UI & UX Design (36/75).
- Leads to
- Product Discovery & Customer Research (36/96), Product Strategy, Roadmaps & Prioritization (36/97) and Product Metrics & Experimentation (36/98).
- What this piece gives you
- You will not be hired as a PM after this. You will be able to name the four risks every product carries, say who on a team should own which kind of decision, tell an output from an outcome, and write a one-page brief. Easier first reads: Starting a Business (04) and How to talk to customers (04/05).
The four risks: what a product manager is really managing
Marty Cagan, a long-time product leader who writes and teaches through the Silicon Valley Product Group, summarises the job as reducing four kinds of risk before a team commits to build something. Value risk: will customers choose to use or buy it? Usability risk: can they work out how to use it? Feasibility risk: can our engineers build it with the time, skills and technology we have? Business viability risk: does it work for the business, including cost, law, brand, pricing and partners? Value and viability are usually led by the product manager, usability by the designer, and feasibility by the engineers, so the decision to build is shared. That arrangement is called the product trio in Teresa Torres's Continuous Discovery Habits (2021): a product manager, a designer and an engineer who talk with customers together every week.
The useful skill is matching each doubt to the cheapest test. A conversation tests value; a paper prototype tests usability; an engineer's two-day spike tests feasibility; a spreadsheet and a talk with finance and legal tests viability. Try classifying the assumptions of an invented idea.
An invented idea: Pantry Pal, an app that photographs your fridge and suggests dinner recipes, for a monthly fee. Six assumptions the team is making. Choose the risk each belongs to, then check.
Without JavaScript: "people open it weekly" is value; "shoppers find the photo button unaided" and "a parent with a baby can add groceries in under a minute" are usability; "recognises common items accurately in a second on a mid-range phone" and "a small team can build it for two platforms in six months" are feasibility; "the price covers the cost per user of running the model" is viability.
Product, project, program, owner: whose job is this?
The titles blur, so separate the questions. A product manager answers what and why: which problem is worth solving, for whom, and how we will know it worked. A project manager answers how and when: scope, schedule, resources, risks and communication for a defined piece of work (the Project Management minor, 36/90 to 36/94, is about them). A program manager coordinates several related projects towards one goal; the title is used differently in different firms, and Microsoft in particular built its own role of that name, which sits close to what others call product management. A product owner is a Scrum role. The 2020 Scrum Guide says the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Some companies use "product owner" as a junior or narrower product manager; others use it for the person who orders the backlog inside a team that has a PM above them.
Nobody wins this argument, and both camps have good reasons. Construction, aerospace and pharmaceuticals plan in phases with gates because late change is ruinous, and a product manager there works with a project manager, not instead of one. Software, where change is cheap, often lets the product team hold both jobs. In a small company one person does everything; in a large one the roles may be split among dozens. What matters is that each decision has a clear owner.
Eight tasks. Assign each to the role that most often owns it in a team that splits the work this way. In your workplace the split may differ, and that is worth discussing.
Without JavaScript: deciding which customer problem to solve and saying no to a big customer's request are the product manager's; tracking the release plan and chasing a vendor renewal are the project manager's; testing checkout with a prototype and sketching three price displays are the designer's; judging buildability and flagging a payment-provider risk are the engineer's.
Outputs versus outcomes
An output is a thing the team makes: a feature, a page, a release. An outcome is a change in what people do that matters to them and to the business. Josh Seiden's short book Outcomes Over Output (2019) puts it as a change in human behaviour that drives business results. Teams that measure output ship a lot and learn little. Teams that measure outcomes are allowed to find that the feature they built did not help, and to stop.
Writing the goal as an outcome does three useful things. It makes the team prove that the problem is real before they build. It leaves room for engineers and designers to find a better solution than the one the manager imagined. And it makes the review honest: you either moved the number or you did not. The opposite habit is the feature factory, a name popularised by John Cutler, in which a team is judged by how many things it ships and nobody checks what happened afterwards.
Each card names something to build. Pick the statement that describes the change you want to see.
Without JavaScript: "launch a referral program" becomes "more existing customers recommend us and new ones sign up through them"; "build a dashboard" becomes "new users find a useful number in five minutes without asking support"; "redesign checkout" becomes "fewer people leave at the payment step"; "add dark mode" becomes "people who use it at night keep using it after the first week"; "integrate a local mobile-money provider" becomes "customers in the new market can pay in a way they already trust".
Where the job came from
In 1931 Neil McElroy, then a young manager running advertising for Procter & Gamble's Camay soap, wrote a memo (dated 13 May 1931) arguing that each brand should have its own dedicated "brand man", who would study its sales, work out why it was weak in a given place, and make a plan with the sales and advertising teams, instead of leaving it to be one line among many. P&G adopted the system, and brand management spread through consumer goods. McElroy later became the company's president and then US Secretary of Defense. The brand man is a root of the product manager.
Other roots grew in other places. Japanese car makers developed powerful chief engineers who owned a vehicle from concept to launch; Kim Clark and Takahiro Fujimoto studied them in Product Development Performance (1991) and called them heavyweight product managers. Microsoft developed program managers who specify what software should do. At Google, Marissa Mayer started the Associate Product Manager programme in 2002 to recruit and train young people for the role, and similar schemes spread. The job is a family of related roles, not one invented thing, and the same job can be called by four titles.
The job in different places
A product manager in a three-person startup talks to customers every day and may also write the site. In a large company the PM spends more time aligning with other teams. For a business-to-business product the buyer is often not the user, so there are two customers to satisfy. In hardware, a design cannot be patched after it ships, so lead times and manufacturing partners dominate. Outside Silicon Valley the shape changes again, and many of the best-known products grew elsewhere: M-Pesa, a mobile-money service, was piloted in Kenya in 2005 with funding from a UK government challenge fund granted to Vodafone and launched fully by Safaricom in March 2007; Mercado Libre was founded in Buenos Aires in August 1999 and grew from an online marketplace into payments; Nubank was founded in São Paulo in 2013 around a credit card managed from a phone; Grab began in Kuala Lumpur in 2012 as MyTeksi, a taxi-booking app; and WeChat, released in January 2011, added Mini Programs in 2017, apps that live inside the messaging app.
Choose a setting. The bars are the author's judgement of where a PM's attention goes, on a scale of 0 to 5. They are an illustration, not measured data.
Without JavaScript: in a startup the PM's attention is on customers and engineering; in a big company on aligning with other teams; in B2B on stakeholders and pricing; in hardware on lead times; in regulated finance on regulation and partners; on a super-app platform on partners and developers.
A week in the job, and how it goes wrong
A typical week for a PM on a team that works well: a handful of customer conversations with the designer and an engineer; time with data on how people use what is already live; sessions with engineers about what is feasible and in what order; updates and arguments with stakeholders; and writing, because a decision written down travels farther than a decision said. The job rewards curiosity and clear writing more than any technical skill. There is also less authority than the title suggests. The idea that a product manager is "the CEO of the product" is a popular claim and a misleading one, because the PM has influence and accountability without the power to order anyone to do anything.
Failures are patterns, not personalities. The feature factory measures output. The roadmap as a promise turns a list of hopes into dates that other teams plan around, so that learning something new feels like breaking a contract. The relay is a PM who passes requests from stakeholders to developers without testing them. The loudest voice picks the feature when evidence is thin. And some failures are loud: Google+, launched on 28 June 2011 and closed to consumers on 2 April 2019, was shut after Google said that 90% of user sessions lasted under five seconds, and Juicero, a juice-press company that raised about $120 million, began selling its press in 2016 at $699, cut the price to $399 in January 2017, and suspended sales in September 2017 after a news story in April showed that its packs could be squeezed by hand. Each failure can be read with the four risks: the question is which one nobody tested.
Template: a one-page product brief
A brief is a thinking tool: if you cannot fill a box, you have found what to learn next. Fill it in, press Copy, and paste it into your team's notes. Nothing is saved or sent anywhere.
What a graduate just sees
- Every product carries four risks, value, usability, feasibility and viability, and each has a cheapest test.
- "We built it and it worked" is not the same as "it was worth building".
- Product answers what and why; project answers how and when; both are real jobs and the split can differ.
- An outcome is a change in what people do, which is why it can be checked.
- A roadmap that is a list of dates turns learning into broken promises.
- The job has influence and accountability, without authority.
- The role is a family: brand men, chief engineers, program managers, product owners.
- The same job looks different in a startup, a bank, a factory and a messaging app.
Where it shows up next
- Product Discovery & Customer Research (36/96): the tests behind each risk, from interviews to fake doors.
- Product Strategy, Roadmaps & Prioritization (36/97): choosing among ideas and saying no.
- Product Metrics & Experimentation (36/98): how to check that an outcome moved.
- UI & UX Design (36/75) and Shipping Software (36/76): the designer and engineer sides of the trio.
- In the world: a banking app's new feature, a car maker's next model, a ministry's public service, a startup's first release.
If you want to go deeper
- 📘 Textbooks. Marty Cagan, Inspired: How to Create Tech Products Customers Love (Wiley, 2nd edition, 2017), the best-known account of the four risks and the product-team model; and Teresa Torres, Continuous Discovery Habits (Product Talk, 2021), on the weekly practice of the trio.
- 📘 Gentler. Melissa Perri, Escaping the Build Trap (O'Reilly, 2018), on outputs versus outcomes in large organisations; and Josh Seiden, Outcomes Over Output (2019), a very short book.
- 🌐 Free course. The articles at Silicon Valley Product Group, including "The Four Big Risks", and the free articles and templates at Product Talk.
- 🌐 Reference. The Scrum Guide (2020) for the Product Owner accountability.
Product management is the job of finding out whether something is worth building before, and while, a team builds it. Name the four risks, give each its cheapest test, ask for outcomes instead of outputs, and keep what you write down short enough that a team will read it.
Try this: pick a feature you use daily and guess which risk its makers were least sure of. Then write one sentence for the change in your own behaviour they hoped for.
Sources. Cagan, Inspired (2nd edition, 2017) and "The Four Big Risks," Silicon Valley Product Group; Torres, Continuous Discovery Habits, 2021; Seiden, Outcomes Over Output, 2019; Neil McElroy's Procter & Gamble memo of 13 May 1931; Clark and Fujimoto, Product Development Performance, 1991; Scrum Guide, November 2020; accounts of M-Pesa (2005 pilot, March 2007 launch), Mercado Libre (1999), Nubank (2013), Grab (2012), WeChat Mini Programs (2017), Google+ (2011 to 2019) and Juicero (2013 to 2017) from company and press histories. The Pantry Pal idea and the bar scores are invented for illustration.
- 📘 Cagan, Inspired
- 📘 Torres, Continuous Discovery Habits
- 🌐 SVPG articles