Product Manager vs. Product Owner [and the Product-minded Software Engineer]

In this article, I clarify the differences and similarities between Product Manager and Product Owner. Also, I take the chance to briefly talk about the importance of the product mindset in software engineers.

All right, let's jump into the first part.

Product Manager vs. Product Owner

Product Owner (PO) is one of the process roles in Scrum. Scrum is a process framework for developing and sustaining complex products. Let's look at how Scrum defines the PO role:

A Product Owner orders the work for a complex problem into a Product Backlog.

Typically, only one person is playing the PO role at a time in a Scrum team. The concept of a "complex problem" is vaguely defined in the sentence above from the Scrum Guide and I think this is intentional since the Scrum framework can be applied to all sorts of problems. And they go on:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;

• Creating and clearly communicating Product Backlog items;

• Ordering Product Backlog items; and,

• Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

In summary, as many people say, the PO is the voice of the stakeholder. The PO is supposed to bridge the gap between the problem domain and the rest of the Scrum team working on a solution. That's the only way they can maximize the value of the product (as the definition suggests).

Well... All of it is in the context of the Scrum framework. The PO role is a particular Scrum terminology. Strictly speaking, outside Scrum, people do not use this term very often. And my hypothesis is that his happens for two main reasons. First, there has been more emphasis on the backlog management and grooming pieces of the PO role rather than the "maximize the value of the product" piece of the PO responsibility. Second, in order to maximize the value of the product, people need to go way beyond the team backlog scope. And that's when the concept of Product Management comes into play.

Product management is a career, not just a role you play on a team. The product manager deeply understands both the business and the customer to identify the right opportunities to produce value -- Escaping the Build Trap by Melissa Perri.

Generally, a Product Manager talks to customers to understand their crucial pain points, gather requirements, and test ideas to further explore potential solutions. PMs may also collect and analyze telemetry data to draw conclusions about existing products and features. PMs also communicate "in different languages" with various people such as engineers, UI/UX designers, researchers, marketing, sales, etc. PMs create product roadmaps and manage backlog items together with engineering teams. PMs work with business and engineering counterparts to define metrics, analyze data, and assess whether the product is going in the right direction by delivering value to the organization. Another essential skill in PMs is the capacity to drive conversations and influence others without authority. Ultimately, PMs should keep the team focused on the why (Why are we building this product, and what outcome will it produce?).

The above paragraph summarizes some of the most important PM responsibilities, and there is probably more depending on the organization. As you may have noticed, these responsibilities associated with the product management job are not explicitly defined as the PO role in the Scrum framework. Indeed, PM is a full-time job, whereas PO is specifically a role in a Scrum team.

If you are a Product Manager and your team follows the Scrum framework, we can tell you play the PO role in the team. But not all PMs are POs, simply because not everyone follows the Scrum framework.

Here's the confusion now.

Hey, Bruno, I've heard someone saying they're a PO in a team that does not follow Scrum. They follow whatever agile practices they find applicable to their context. Are they mistakenly applying the terminology?

My short answer is Yes, they are applying the wrong terminology. As discussed, PO emerged as a Scrum term and with a scope clearly defined in the Scrum framework.

Bruno, in this new project, the other developers working with me will continue as developers while I volunteered to be a PO, since we don't have anyone else in the company to be a PO in this project and I know the domain well. Can I consider myself a PM, too?

Tricky question. Without much additional context, I'd say No, you're not a PM. In this case, you're a developer working temporarily as PO in a project. You may be a developer at times and switch to play the PO role at other times. Still, your job is not a full-time Product Manager. This experience may lead you to become a full-time PM, though.

All in all, we cannot control how people apply those terms in the field. At the end of the day, people are not committing a crime by calling PMs as POs and vice-versa. Moreover, some buzzwords come and go over time, and we never know to what extent practitioners will adhere to specific terms in the field. Some years from now, the chances are that new terms will apply to the Product Management area, and this article may even become obsolete. For now, you can consider the general term as PM, while PO is the specific terminology for the "product person" in the specific context of a Scrum team. That's also why you see Product Manager as the job title in many job ads when organizations look for "product people."

Well... And if you are a software engineer, and you want to stand out in the crowd and deliver significant value to your users, try to develop the product mindset in you.

The Product-minded Software Engineer

While you can simply define PMs as those responsible for defining the "what" and the "why" in software products, software engineers are sometimes defined as the deeply technical people that are specialized in hacking out solutions (the "how") to solve end-user problems. And this is not largely wrong. Many successful software engineers, in their careers, do not develop a product mindset that makes them connect well with the value proposition of the solutions they implement. However, more and more, the industry needs engineers capable of reducing the gap between the problem domain and the solution domain and understanding the impact of their solutions and fine-grained design decisions on the business as a whole.

This is what we call "Product-minded Software Engineers." These are engineers that work close to the product vision and give inputs to the roadmap. They also make an effort to understand why product decisions are made, how people use the product and often endeavor to actively make product decisions.

Throughout their career, product-minded engineers find more flexibility in either switching to a product management career or moving up on the engineering career ladder by showing the product-awareness capacity in their work. Whether in big tech-companies building world-class products or startups developing highly innovative ideas, product-minded engineers usually help organizations take teams to a new level of impact.

From a management perspective, these are the engineers you like to work with to shorten the gap between the problem and solution spaces and ultimately deliver value to users and businesses in a more productive fashion at a lower friction.

If you want to read more about product-minded engineers, check this article from an experienced ex-engineering manager at Uber.

If you want to discuss anything related to this content, please drop me a line on Twitter (@BrunoDaSilvaSE) or a comment below.

I welcome your feedback!