What Is Product Management? Product Manager vs Product Owner vs Project Manager

Version note: This post is conceptual; role definitions are based on the Scrum Guide 2020 and Marty Cagan's SVPG (Silicon Valley Product Group) articles (especially "The Four Big Risks," 2017).

Guess First

On Monday morning Bookstore's sales director emails the team: "Build a campaign module for the November campaign period. We should be able to define coupons in the admin panel, the discount should apply in the cart, and a banner should appear on the home page. It has to be ready by 27 November."

Three people read this email. The Product Owner adds an epic called "Campaign module" to the Product Backlog and asks the team how long it will take. The project manager opens a Gantt chart and works out a task list backwards from 27 November. The product manager asks the sales director a question: "What do we want to change with the campaign? What did we miss most in last year's campaign?"

Which of the three behaved correctly? And you, as the .NET developer who will build this, which question should you not start coding without an answer to? Consider this too: does anyone on the team know how many people used the coupon system built last year?

Product or Project?

The two words are so similar that they constantly get mixed up, but what is being managed differs. A project has a beginning and an end and tries to deliver a defined scope by a given date and budget. "Getting the campaign module live by 27 November" is a project; it ends on 27 November.

A product is something that keeps producing value for a group of customers, and it doesn't end. Bookstore's online store is a product; the campaign module becomes a part of it, but the product keeps living on 28 November. The product's problem isn't solved because the campaign module went live; the real question is whether the module solves a problem for the customer and the company.

This distinction affects developers directly. From a project view, success is "delivering on time and in scope"; from a product view, success is "what you delivered changing something." Code written with a project view counts as complete on 27 November. For code written with a product view, 27 November is a beginning: coupon usage, the basket size of campaign orders and whether campaign customers come back are measured, and the module is changed or removed accordingly.

Three Roles: Product Manager, Product Owner, Project Manager

When the three role names are abbreviated, two of them end up identical: both become PM (Product Manager or Project Manager), which makes the confusion worse. We won't use abbreviations in this post. Let's put the differences in a table:

According to the Scrum Guide 2020, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team; it is one person, not a committee, and is accountable for effective Product Backlog management. The Guide doesn't say Product Owner is a job title; it describes an accountability. In practice, in most companies this accountability is taken on either by someone with a Product Manager title or by someone whose job is only writing the backlog and who takes no part in product decisions. The second is very close to the "proxy Product Owner" problem described in the Scrum series' post on the Scrum Team and its accountabilities. The mechanics of the Product Backlog are the subject of the third post in the same series; this series doesn't go there.

The project manager comes from another world: a role that manages scope, time, cost and risk as described by standards such as the PMBOK. A product team may not have a project manager; when it does, they usually coordinate dependencies in fixed-date work involving several teams or an external supplier. In work like the campaign module, a project manager is useful: coordinating with marketing, design and the payment provider is real work. But "what do we want to change with the campaign?" is not their question.

Cagan's Four Risks

In his 2017 article "The Four Big Risks" at SVPG, Marty Cagan says a product idea can fail for four different reasons. Value risk: will the customer buy this or choose to use it? Usability risk: can the user figure out how to use it? Feasibility risk: can our engineers build it with the time, skills and technology we have? Business viability risk: does this solution also work for the other parts of the business, such as sales, legal, finance and brand?

Cagan also separates the owners of these risks: value and business viability risk belong to the product manager, usability risk to the product designer, and feasibility risk to the tech lead, the senior engineer on the team. That last point matters to you. Feasibility is more than "can we build this?"; it is "can we build this by 27 November, without breaking the existing order flow, in a way that handles campaign-day traffic?" and the person on the team best placed to answer that is the person who knows the code.

Let's look at the campaign module through the four risks. Value: how many customers used last year's coupon system? Were coupon orders bigger than orders without coupons, or did we give discounts to customers who would have bought anyway? Usability: is the coupon code entered in the cart or at payment? Feasibility: where in the existing OrderPricing flow does the cart discount calculation go; if home page traffic triples on campaign day, which cache strategy serves the banner? Viability: how coupons are recorded in accounting, and whether they comply with agreements with publishers. None of these questions are in the email, and each one can change the shape of the module.

Feature Factory and the Empowered Product Team

A typical response to the opening email goes like this: the Product Owner opens the epic, the team splits it into stories, spreads them over Sprints, the module goes live on 27 November and the team moves on to the next request. Nobody checks whether the campaign changed anything. Using the name John Cutler popularized in 2016, this is a feature factory: a way of working where success is measured in features delivered, outcomes are not measured and the team never takes part in the "what" question.

Cagan's counter-model is the empowered product team: the team is given a problem to solve and an outcome to reach, and the team (product manager, designer and engineers together) finds the solution. In the Bookstore example, instead of "build a campaign module," that would mean telling the team "increase new customer acquisition in the November campaign compared to last year, without lowering the share of customers who place a second order within 60 days after the campaign." Maybe the solution is a coupon module. Maybe lowering the free shipping threshold is more effective and far cheaper to build. Knowing that requires understanding the problem, which is the subject of the rest of the series.

Being empowered doesn't mean "the team does whatever it wants." The company's strategy, product vision and goals draw the frame; the team is responsible for solving the problem within that frame. The sales director's 27 November date is a real constraint and the team can't afford to ignore it. What changes in an empowered team is who decides, with what information, what makes it by that date.

Where the Developer Fits

This series is written for developers, because product decisions are not only the product manager's decisions. The developer is indispensable in three places.

The first is feasibility. You are the one who best knows the cost and risk of an idea. The difference between "this takes two weeks" and "this takes two weeks, but it needs a migration on the orders table and deploys are frozen in campaign week" changes the product decision. Cagan's advice is for engineers to be present where ideas are first discussed, during discovery, not at delivery time.

The second is data. Most product decisions rest on the question "how many people use this?", and the answer usually lives in the logs, database or events of the code you wrote. In post 07 of this series we will measure product metrics ourselves with Angular and ASP.NET Core.

The third is ideas. Engineers know best what technology makes possible today. Cagan often stresses that some of the best product ideas come from engineers. A sentence like "to show shipping cost on the product page, we can pull a precomputed table from the carrier's API (Application Programming Interface)" can put a solution on the table the product side hadn't thought of.

In Production

The product view starts after delivery. When the campaign module goes live, the infrastructure to collect usage data should be ready too; every feature for which people say "let's build it first, we'll think about measuring later" is forgotten without being measured. Adding "the related events are collected in production" to the delivery definition (the Definition of Done in Scrum) is a simple way to push the team toward a product view.

Look at where decisions are actually made, not at the paper definition of the roles. Your team may have someone with the title "Product Owner," but if the order of the Product Backlog changes every week because of a manager's email, the product decision really sits with that manager. Seeing that tells you who you need to talk to.

In fixed-date work like a campaign, flex the scope to the date, not the date to the scope. "Whatever is ready by 27 November ships with the campaign" is a product decision, and having that conversation early beats trying to rescue the last week with overtime.

Common Pitfalls

For a developer, the most common pitfall is retreating to "just send me tickets and I'll build them." That position is comfortable: responsibility for the decision lies with someone else and the job is clearly defined. But the price is high. Building a feature that solves the wrong problem as well as possible is more expensive than not building it at all; there is the cost of writing it and years of maintenance. Asking "which problem does this feature solve, and how will we measure it?" is part of a senior developer's job.

The second pitfall is thinking the Product Owner is a backlog writer. The Scrum Guide makes the Product Owner accountable for the product's value; writing stories is only a small part of that and can be delegated to the Developers.

The third is thinking the product manager is a "mini CEO (Chief Executive Officer)." The product manager is nobody's manager and makes decisions through data and persuasion, not authority. The team doesn't report to them; it works with them.

The fourth is treating the three roles as alternatives to each other. In a large organization all three can exist at the same time and answer different questions. In a small company one person may wear all three hats; then knowing which hat you're speaking with matters.

A Small Experiment

★☆☆ Find the biggest request your team received in the last three months. Did it describe a solution ("build a campaign module") or a problem ("new customer acquisition drops in November")? Write the problem behind the request in one sentence.

★★☆ For the last feature your team delivered, write down Cagan's four risks one by one. Which ones were really tested before delivery, and which weren't? Who assessed the feasibility risk, and when?

★★★ Pick three features built in your product in the last year and find usage data for each (events, logs, a database query). How many could you measure? For the ones you couldn't, write down which data is missing.

We said the team should be given a problem and an outcome instead of "a campaign module." In the next post we'll discuss how to do that: we'll unpack the difference between output and outcome, a good problem statement, the hypothesis format and the Jobs to Be Done idea through Bookstore's cart abandonment problem.