Product Owner or Scrum Master

It’s common to run into people certified as both Scrum Master and Product Owner. Confusing as it might be to me, it’s not unusual to talk - in person or on social media - with people who, for whatever reason, got certified in both. Does it even make sense to try to specialize in both roles? This article lays out arguments to help you understand the difference between the roles, and how you can support your own growth as a Product Owner or Scrum Master.

The first and most important thing is figuring out which role is right for you. And the answer is: it depends. Sure, like any good consultant, “it depends” is my most common answer. But if you’ve read my previous articles, you know I don’t like half-measures, and I like giving real guidance to people who are still on the fence or confused about the Scrum Master and Product Owner roles.

Below, I lay out the key information to tell the two roles apart and better understand the potential of each one. Even more so if you’re thinking about strengthening your own skills, or hiring someone for one of these roles - this article will surely be useful.

Scrum Can Do It All

While Scrum is really good, it bothers me a little to see people try to apply it everywhere - a bit of a “for crying out loud” moment, as we’d say in Colombia.

Scrum isn’t new, and it’s very similar to its agile cousins and siblings. It’s an iterative management model that, through certain activities and roles, promotes, among other things:

• Alignment
• Transparency
• Better communication

But these days - like with every trend - Scrum has become our new “Maslow’s Hammer.”

Scrum: The New Maslow’s Hammer

Maslow popularized this idea, also known as “the Law of the Instrument” or “the Golden Hammer,” in his book The Psychology of Science, published in 1966, which said something along these lines:

It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

Abraham Maslow

Scrum Master: The All-Powerful

Following that logic, if Scrum can do it all, then the Scrum Master must be some kind of Dungeon Master with unlimited power.

In my opinion, it’s exactly the opposite. If your dream is to become a Scrum Master, the first and most important thing is to understand the power of the role, the opportunities it opens up for you, and, of course, the box it puts you in.

So let’s break this down piece by piece.

What Does a Scrum Master Do?

While the Scrum Guide is, IMHO, a thin and ambiguous document with little actual content, let’s use it out of respect for the model’s founders - who, unlike their guide, which looks more and more like a pamphlet every year, have genuinely dedicated their lives to interesting things and remarkable projects.

Scrum Master as Ambassador

So let’s take apart the SM’s description in the Scrum Guide:

The Scrum Master is accountable[ref]Translating “accountable” as “responsable” in Spanish feels inappropriate to me, and it can confuse the reader. That’s exactly why it’s worth reflecting on the difference between what “responsible” and “accountable” actually mean[/ref] for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

Taken from the 2020 Scrum Guide - https://scrumguides.org/scrum-guide.html

In short, the SM is an ambassador for the model. Kind of like the PMBOK fanboys of a few years back, going around with their inputs and outputs, their processes and tools, as if there were no tomorrow and nothing beyond the standard.

The SM, then, is scoped to the Scrum Team and the organization that team works within. So if your dream is to run several teams, or large groups, to become an IT director, or something “a bit broader,” being an SM isn’t going to get you there.

Opportunities for the SM as Ambassador

1. There are a lot of job postings for Scrum Master these days - even if it’s not always clear what’s expected of the role, nearly all of them require an active certification.
2. It’s a role where you can develop your people skills and improve your negotiation and conflict management abilities - at a small scale.
3. The Scrum framework - and especially the Scrum Guide - is a simple, innocent read. You don’t need years of study to grasp the role. The agile community is very active worldwide, and you’ll surely be able to join groups where you can debate, learn, and experiment.
4. It’s a broad role, and if you’re passionate about it, you can expand your capabilities beyond Scrum, into managing teams and motivating people.

Risks for the SM as Ambassador

1. The Scrum Master is scoped to the Scrum Team within an organization. If you have ambitions to grow or gain more authority - like running a department or large teams - being an SM won’t give you leverage for those roles. Its small-scale mindset can even become a real obstacle if you want to lead a large team - I mean dozens or hundreds of people here.
2. If you like having control over requirements or the work, you’re definitely going to struggle as a Scrum Master. You’re not a boss - you’re a facilitator, or, as some put it, a “catalyst.”
3. If you need something beyond Scrum - and you surely will - an SM course or certification is barely half of the first step. Unfortunately, a lot of courses and certifications only walk you through the guide, and do little to nothing to help you with actual experience.
4. It’s a broad, somewhat generic role. If facilitating and supporting others isn’t something you’re passionate about, you’re going to learn - through a lot of stumbles - that the guide doesn’t help you at all with the day-to-day of the job.

The Scrum Master Builds on an Open Framework

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Taken from the 2020 Scrum Guide - https://scrumguides.org/scrum-guide.html

Well, the Scrum Guide is, as I’ve said before, simple… bordering on incomplete[ref]And I’m not the only one saying it. The 2020 guide itself says: “The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory”[/ref]. For a lot of people, that’s wonderful. For others, a real headache. Somehow, you need to fill in the blanks. So if you have a lot of experience, Scrum is an excellent base to build on. If you don’t, you’re lost in a space of ambiguity and “nice ideas.”

Opportunities for the SM Within an Incomplete Framework

1. Not having a prescriptive framework is a good thing, and it keeps away the “trolls” who try to do everything “by the book.” At the same time, it expands the framework’s potential reach to projects beyond software - which is where Scrum was originally created.
2. Empirical thinking is powerful when taken seriously. Empiricism isn’t a synonym for “improvisation.”

Risks for the SM Within an Incomplete Framework

1. If you’re just starting out, not having a detailed framework is a headache. The challenges and problems you’ll face will require a lot of study on your part, and, often, support from experienced people.
2. Empiricism gets confused with improvisation very quickly. Don’t let yourself get seduced by that. While radical agilists hate predefined recipes, sometimes, to become a great chef, you first need to learn a few standard recipes, so you can later add your own particular, special touch to them. I’d recommend looking into the concept of Shuhari .

What’s the Product Owner’s Goal?

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.

Taken from the 2020 Scrum Guide - https://scrumguides.org/scrum-guide.html

As you can see, the PO plays a foundational role in delivering value. I’ve always thought people too easily confuse the PO role with a business analyst’s, or even a “documentation writer’s.” And while they share some common ground, they’re not the same.

Maximizing product value means the Scrum Team’s work is clearly oriented toward results and business benefits. And that implies incremental thinking.

The Product Owner’s Responsibilities

The Scrum framework defines the Product Owner role, or PO. This role is a person with business vision - and only one person. This person needs to think in terms of business benefit or value. In that sense, their responsibilities also include listening to the customer or consumer, the organization, and the market at large, in search of “opportunities and threats” to generate value within the context of the product or service being developed.

Beyond the Scrum framework, the PO role serves certain key functions in any initiative.

• Identifying opportunities and threats for the business - within the context of the product or service in development
• Exploring new and/or better features to strengthen the product or service
• Setting the development path for a product or service
• Managing the backlog
• Weighing requirements or needs beyond pure business value, in order to mitigate technical debt[ref]This function has its critics. But in my experience, the PO can’t just prioritize the business over the technology that enables product delivery. Even without being a technical expert, they need to learn to balance product progress in order to avoid ending up, later, with products that are functionally wonderful but unable to scale to exponential demand, or unable to coexist with the company’s other products and services[/ref]

The Power Behind the PO

In my opinion, the PO role is far more strategic and critical to the success of an agile evolution, even more so than the Scrum Master. In other words, a transformation of the work and management model can only be considered successful if a good flow of business value gets established, and therefore, if the chosen base model is Scrum, the PO role is essential. On the other hand, in the absence of a Scrum Master, it’s still possible for the desire or need for change to lead the team and organization to a successful agile model - the SM, in theory, just reduces resistance to change.

The PO manages the Product Backlog and negotiates the Sprint Backlog with the team. According to the 2020 Scrum Guide, they also:

1. Develop and explicitly communicate the product goal
2. Create and clearly communicate Product Backlog items
3. Order - though I prefer “prioritize” - the Product Backlog items, and
4. Ensure the Product Backlog is transparent, visible, and understood by all stakeholders

The PO’s Role in a Project or Organization

The PO is scoped to developing and operating a product or service. If the product is new, we’re probably talking about a “project”; if the product or service is already up and running, the PO is probably tied to an area or unit within the organization.

In that sense, a good Product Owner sees the opportunity to consolidate, unify, prioritize, and flesh out every idea, opportunity, threat, and challenge facing a product or service in development or operation.

Likewise, they understand the importance of keeping technical debt low, even without understanding the technical detail. So here’s a hypothetical example:

Let’s say I’ve decided to build a vacation home. As an engineer from a family of architects, I’d like to have control over the requirements - functional, and even some design ones. But I’m not an architect, and I need to balance my own wishes against the technical constraints set by the architect, a structural engineer, and, of course, the available budget.

As a PO, I can’t just fill the requirements list - the backlog - with ideals or functional wishes, ignoring the real constraints of the context I’m developing the product in. I need to stay focused on value and benefit.

Opportunities for the PO

• If you like designing, defining, and detailing products or services, the PO role is for you.
• Not everyone is good at “structuring products” incrementally, so there’s plenty of opportunity - a good, well-regarded PO will always land great projects.
• You’re the bridge between the business and development. That connects you very well across the organization.
• You see and control the outcome. How successful a product or service is, is largely in your hands.

Risks for the PO

• If you don’t have authority over requirements and other backlog items, you could end up becoming a “documentation writer,” and, along with it, the bottleneck of the whole process.
• If you’re not good at structuring products, the incremental concept can become very painful, and you could end up shipping “incomplete” products that always depend on “something else” to actually be functional.
• If the organization you work for doesn’t see value in your role, your hands will likely always be tied when it comes to proposing or structuring things. Organizational politics can be a real challenge in some conservative business environments.
• Heavy technical debt undermines the PO’s ability to propose valuable features. A lot of the time, your job can turn into “fixing” instead of “proposing.”

Never Merge Scrum Master and Product Owner

If you know agility, you know what you just read makes no sense. But it happens, and a lot. Many organizations don’t understand this system of checks and balances, and don’t see value in giving focus to specific functions and responsibilities.

I’ve never been a fan of a 100%-dedicated Scrum Master, and I truly believe the last thing a mature team needs is a full-time SM or facilitator. A coach who checks in every once in a while is more than enough. Well, that’s what I believe, anyway.

The Product Owner, on the other hand, really is a key role, and a lot of projects stall or slow down because there aren’t good inputs to move the work forward. Priorities aren’t clear, or nobody’s thought through how to deliver value incrementally.

In that sense, I’ve always been a strong defender of the importance of the PO role.

SM vs. PO Comparison

Final Thoughts on the Product Owner and Scrum Master Roles

1. Never try to merge the two roles.
2. They’re different, complementary roles that maintain a natural, healthy tension for organizations.
3. The PO is oriented toward the details of the product or service being developed or maintained. The SM is oriented toward the team and “good practice.”
4. The career path for each role looks different.
5. In some cases, the key skills for succeeding in each role are different too.

If you have comments, experiences, or suggestions, let me know your thoughts in the comments.