Product Management: The Job Is Mostly Deciding What Not to Build

Fifteen products, then three

In May 1997, at Apple's developer conference, Steve Jobs, back at the company as an adviser, talked about focus. "You think, well, focusing is saying yes? No. Focusing is about saying no" ¹. Apple had lost $1,045 million in its 1997 fiscal year. Over the following year it did what Jobs described. Its annual report for 1998 put it in one sentence: "During 1998, the Company simplified its product line, moving from approximately 15 separate individual products to three main product families" ². It also discontinued the MessagePad and eMate lines. In fiscal 1998 Apple reported net income of $309 million ².

No single decision turned Apple around, and the product cut was one of several. But it shows the part of product management that most job descriptions leave out. The visible work is building things. The work that decides whether a product succeeds is choosing, again and again, what not to build.

Product management is the job of deciding what a product should do, for whom and why, and then making sure the team builds that and not something else. A product manager owns the problem the product solves and the case for each thing it does, from the first idea through launch and for as long as the product lives.

The roadmap is the visible half of product management. The list of things you will not build is the other half.

This page covers where the job came from, how it differs from project management and the product owner role, the four questions every product decision has to answer, what saying no costs and what not saying it costs, and a one-page product decision you can use this week.

Where the job came from

Product management began in soap. On May 13, 1931, Neil McElroy of Procter & Gamble wrote a three-page memo proposing "brand men": one person responsible for each brand, who would "Take full responsibility, not simply for criticizing individual pieces of printed word copy, but also for the general printed word plans for his brands" ³. He was specific about focus even then: "one man should not have to work on more than two brands at the very most" ³. P&G's own timeline records the moment simply: "1931 — Neil McElroy creates brand management" ⁴.

The software version took its modern shape decades later. Ben Horowitz's memo "Good Product Manager/Bad Product Manager," written in the 1990s and published in 2012, opened with a line that is still quoted in nearly every job posting: "A good product manager is the CEO of the product" ⁵. Google created what it calls "the first Associate Product Manager program of its kind" in 2002, turning product management into a role people could be trained for ⁶.

The CEO comparison is useful and misleading in equal measure. A product manager carries a CEO's accountability for the outcome, but almost never a CEO's authority over the people building it. The job is done mainly by persuasion: with evidence about customers, with a clear account of what the product is for, and with the discipline to say why something is not on the list. Horowitz put the core of it plainly: good product managers "crisply define the target, the 'what' (as opposed to the how)" ⁵.

Product manager, project manager, product owner

Three roles are easily confused, and the confusion is expensive, because each optimizes for something different.

In many companies one person is both product manager and product owner; the product owner is a role within Scrum, the product manager a job. The useful test is the question each one asks first. A project manager who keeps a doomed project on schedule has done the job; a product manager who ships a product nobody needs has not.

Product management also overlaps with strategy. A product strategy is a business strategy at the scale of one product: a choice of customer, a reason to win and a list of things to give up. For how the product team fits alongside corporate strategy and business operations, see strategy vs. corporate development vs. BizOps; for the strategy document itself, see product strategy.

The four questions every product decision has to answer

Marty Cagan of the Silicon Valley Product Group reduced the product manager's risks to four, and they make a good test for any idea on a roadmap ⁹:

• Value: "whether customers will buy it or users will choose to use it."
• Usability: "whether users can figure out how to use it."
• Feasibility: "whether our engineers can build what we need with the time, skills and technology we have."
• Business viability: "whether this solution also works for the various aspects of our business" ⁹.

Of the four, value is the one most easily assumed, because the people proposing an idea are rarely the people who would buy it. That is why the strongest product disciplines force the value question first. Amazon's "working backwards" process starts with a draft press release for the finished product, written before anything is built. Its key tenet is "to start by defining the customer experience, then iteratively work backwards from that point," and its verdict on weak ideas is blunt: "If the press release doesn't describe a product that is meaningfully better (faster, easier, cheaper) than what is already out there... then it isn't worth building" ¹⁰.

What saying no costs, and what not saying it costs

Saying no is uncomfortable because its costs are visible and immediate: a disappointed executive, a lost deal, a team that wanted to build the thing. The cost of not saying it arrives later and lands on someone else's budget.

Amazon's Fire Phone is a clean example, because Amazon reported the cost itself. It announced the phone on June 18, 2014, at $199 on a two-year contract, exclusively on AT&T ¹¹. Three months later, its quarterly filing reported "charges estimated at $170 million primarily related to Fire phone inventory valuation and supplier commitment costs," with $83 million of inventory and commitments still on hand ¹². In September 2015 Amazon said it had sold through its inventory and did "not plan to replenish stock" ¹³. Our analysis of the Fire Phone traces the decisions that led there. The lesson for product managers is not that Amazon made a mistake; every product company does. It is that the bill for a missing no is paid in inventory, write-downs and the attention of a team that could have been building something else.

The opposite case is LEGO. After a net loss of DKK 1,931 million in 2004, the company narrowed its focus back to its core bricks and decided to sell its Legoland parks ¹⁵. It returned to a profit of DKK 505 million in 2005 and DKK 1,430 million in 2006 ¹⁴. Our analysis of the LEGO turnaround covers what was cut and why.

The product decision scorecard

Use one row per request, idea or roadmap item. The point of the scorecard is the last three columns: every item gets a decision, a reason and a date to look at it again, so "not now" never quietly becomes "never decided."

How to decide what not to build

1. Write the product's one choiceState, in a sentence, the customer the product serves and the job it does for them. Every later decision is tested against it.
2. Collect requests in one placeSales asks, executive ideas, customer tickets and the team's own ideas all go on the scorecard. Requests that live in side conversations get built by whoever pushes hardest.
3. Demand evidence of valueFor each item, find behavior that shows the need: workarounds, churned customers who named it, usage of a related feature. An opinion, however senior, is not evidence of value.
4. Score the other three risksUsability, feasibility and business viability, each high, medium or low, with one line of reasoning ⁹.
5. Decide, in writingBuild, not now or no, with a reason the requester will read. A short written no is kinder than a long silence.
6. Protect the noPublish what the product will not do this year, and keep it with the roadmap. The list prevents the same request from being argued again every month.
7. Set kill criteria for what you buildFor each item you build, agree in advance the result that would make you remove or rework it. See kill criteria.

A worked example

The company below is invented.

Nobody got everything they asked for, and nobody was left guessing. That is what a good product decision looks like from the outside.

Before you commit to the roadmap: a checklist

• The product's one choice of customer and job is written down and agreed.
• Every roadmap item has evidence of value from customer behavior, not only from requests.
• Each item has been scored on usability, feasibility and business viability.
• Each item quotes the strategic choice it serves.
• There is a published list of what the product will not do this year.
• Every request that was declined has a written reason and a revisit date.
• Each item we build has a result, agreed in advance, that would make us remove or rework it.

Monday morning: list everything your team is building or has promised, and next to each item write the customer behavior that proves it is needed. The items with an empty column are where the next no should come from.

McElroy asked that no brand man carry more than two brands. Jobs cut fifteen products to three families. Both understood the same thing about the job: a product manager's power is not in how much the team builds. It is in how clearly the team knows what it is not building, and why.

Questions

What is product management?

Product management is the job of deciding what a product should do, for whom and why, and making sure the team builds that and not something else. A product manager owns the problem the product solves and the case for each thing it does, for as long as the product exists.

What does a product manager do?

A product manager works out which customer problems the product should solve, gathers evidence that the need is real, decides what to build and what not to build, and works with engineering, design, sales and support to deliver it and measure whether it worked.

What is the difference between product management and project management?

A project manager delivers a defined piece of work on time and on budget; PMI defines a project as a temporary endeavor. A product manager owns an ongoing product and is measured on whether it delivers customer and business outcomes.

What is the difference between a product manager and a product owner?

Product owner is a role defined by the Scrum Guide: the person accountable for maximizing the value of what one Scrum team delivers, through its backlog. Product manager is a broader job covering the product's strategy, customers and outcomes. In many companies one person does both.

How do product managers decide what not to build?

By testing each idea against the product's choice of customer and job, demanding evidence of value from customer behavior, scoring usability, feasibility and business viability risk, and recording each decision with a reason and a date to revisit it.

Where to go next

• Strategy vs. Corporate Development vs. BizOps: Who Owns What
• Initiative Prioritization Scorer: RICE, Head to Head
• Product Strategy
• Product-Market Fit
• Kill Criteria