Scrum Product Management: Roles, Responsibilities, and Best Practices
Scrum is nothing new in the product management space. Most of us use Scrum in our companies and try to navigate this framework’s roles and principles to achieve our goals.
Unfortunately, it is common for companies to misinterpret the principles of Scrum and use them incorrectly, thereby denying users the many benefits of Scrum.
So this lovely little guide is all about helping you make better use of this framework by explaining what it is about, why there are different Scrum roles, what the product management responsibilities are, and how to excel at cross-functional collaboration.
What Is Scrum In Product Management?
Many of us like to discuss the role of a product manager within the reality of Scrum processes and agile methodology (in other words, what the PM does in a Scrum team). Instead of just explaining it, I think it's easier to simply show you where the PM is in the team org chart.
For this guide, however, I want to approach this topic from the opposite direction and show how Scrum fits into your reality as a product management professional and how it can help you reach your product goals.
I want to begin by discussing the effect of the Scrum framework's core principles on the effectiveness of our work.
Probably the single most valuable Scrum principle for us is the constant delivery of value to users. The quicker people can solve problems, the better your product will perform. Moreover, you get access to early feedback from people who have used the feature in a real-life scenario.
The second advantage you get with Scrum is flexibility. If the market reality changes, you can quickly adapt to it by completely revamping your product backlog and handing over new features to your team in the next sprint.
These two are something that is very hard (or nearly impossible) to do with traditional frameworks like Waterfall, where everything is fixed in scope and users access the product at the very end of the SDLC.
Examples of Product Success Thanks to Scrum Integration
Having worked with Scrum teams for years, I am totally biased towards this agile framework. So, don’t take my word as gospel. Instead, let’s look at real-life cases where switching to Scrum helped product teams succeed faster.
Microsoft Visual Studio: The tech giant’s main code editing tool was infamous for its repeating cycles of production hell, with buggy releases and incredibly infrequent releases. From the moment its product team started taking advantage of Scrum, the company saw a sharp increase in product stability along with much more frequent release cycles—restoring its competitiveness in the market.
Spotify: Our beloved music streaming service’s adoption of Scrum is among the most famous ones in the industry. Spotify struggled to adapt and scale fast enough to solve its process challenges...until the org adopted Scrum. But what sets Spotify apart is the development of their own Scrum project management model, which assumed a group of autonomous agile teams that had access to all the expertise they needed to rapidly experiment and incorporate user feedback.
ING: The Dutch banking giant was among the early financial institutions to realize that the future of banking is digital. They also realized that their very traditional project management processes were not viable for software development. So, they quickly adopted lean and Scrum methodologies and, unsurprisingly, became the leaders in e-banking.
Key Roles In Scrum Product Management
If you, as a PM, decide that Scrum is the way to go, here's a quick overview of the key roles in this framework and help you differentiate between your role as a product manager and Scrum product owner.
Let me begin with the roles. A typical Scrum team consists of the following people:
- Scrum master: This person is helping the team follow Scrum rules and optimize their processes.
- Product Owner: The represents the business and users in the Scrum team. POs own the backlog, and set spring goals and story priorities.
- Scrum team: Your developers, designers, QAs, and other specialists that build the product.
Regarding the Scrum team, you can have many other types of specialists there. The concept of cross-functional teams assumes that the team is independent in terms of access to professional expertise. So, for instance, if your product is analytics-heavy, you might have a data analyst on the team, too.
Product Manager vs. Product Owner: What’s the Difference?
The definition of product owner I gave might confuse you a bit since it sounds a lot like what a product manager typically does.
So, in this case, what’s the difference between product manager vs. product owner?
To understand the difference, let’s first look at the core responsibilities of each.
Product Managers
- Conduct product discovery and understand customer needs and pains.
- Define the product vision and the direction that the team will follow.
- Come up with product solutions that can meet customer needs.
- Lead the product delivery process.
- Refine the product in small increments based on customer feedback and data-driven decision-making.
- Manage the product vision and execution up and across the company.
Product Owners
- Create and maintain the product backlog.
- Serve as a single source of truth in terms of strategy, design, and business logic for the Scrum team.
- Prioritize items on the product backlog and bring clarity to the team in terms of what’s important.
- Define acceptance criteria for features and accept the sprint results based on them.
- Unblock team members by clarifying requirements and fixing the issues related to them.
- Take part in Scrum events and serve as the voice of business and customers in the team.
As we can see, most of us do things that can be found in both lists. That’s pretty normal and common since many of us are acting as product managers and owners at the same time.
The core difference between those two is that product management is a profession and skillset, while product ownership is a role in the Scrum team.
But what does that mean?
It means that the product owner doesn’t need to be a product manager. In a small startup, in which you have the CEO along with three developers, the CEO will take on the role of the product owner by supplying the developers with a prioritized backlog.
The opposite situation is also possible. You can be a product manager and not a product owner. I am a good example of this as one of my old teams was not using Scrum. No Scrum, no product owner in the team. We did follow lean and agile principles though.
To give you a better understanding of the difference between these two, here’s a side-by-side comparison of what they do.
But what was the whole point of having a special role in the Scrum team? Couldn’t they just collaborate with product managers who are not part of the team? I really like how Teresa Torres answers it.
So, the main reason there’s a specific product role in the Scrum team is to contribute internal product knowledge and expertise and further reinforce their cross-functionality.
How the Product Manager Interacts with Scrum Teams
Assuming that you have decided to take the path of the Scrum, you will need to know how to be a member of the team and how to collaborate with your folks. Let me give you a short overview of that for each Scrum event and artifact.
- Daily Scrum (a.k.a. standups): The single most important work you do during these time-boxed meetings is to answer the product-related questions of your development team and remove blockers.
- Sprint Planning Meeting: Here, you are the person setting the goal of the Sprint by clearly defining your expectations in terms of the features you expect to deliver.
- Sprint Retrospective: The processes you use to deliver priorities and requirements to the team can make or break their effectiveness. So, you can use this meeting to gather feedback from the team and improve your processes.
- Sprint Review: Here, your task is to accept the finished features of the Sprint and provide the team with feedback on their work.
- Product Refinement (a.k.a. grooming): You are the owner of this meeting and need to use the time dedicated to you to discuss the priorities and details of the user stories you have for the team. Always encourage the team to challenge your requirements and find “product bugs” that you have left there.
- Product Backlog: It is your responsibility to manage the product backlog and keep it clean and prioritized, as they will build their Sprint based on it.
- Sprint Backlog: You don’t own this one. Your main point of collaboration is to guide the team to take the right stories into the Sprint backlog to make sure that they can achieve your Sprint goal.
Apart from this, you will do other kinds of product work, such as stakeholder management or product discovery. As a member of the Scrum team, your task is to keep the team aware of both stakeholder and user needs after you have clarified them.
For instance, if you have an interview with a user and discover that the user experience of your login flow is generally confusing, it is important to share this information with the team to make sure that they pay attention to that part in subsequent sprints.
Best Practices For Scrum Product Management
While product management seems easy when seen through the lens of Scrum (and Agile development in general), there are a lot of mistakes that we commonly make during our work within our self-organizing teams.
So, here are a couple of Scrum best practices that can help you avoid them:
- Set Clear Expectations: The biggest mistake you can make is providing your team with vague priorities and requirements. Lack of clarity is a leading cause of development delays and tension between you and the team. We’ll have a deep dive on how to achieve this shortly.
- Don't Abuse Adaptability: Having the ability to change course is great, but you can only do that in your product backlog, not the sprint backlog. As soon as the sprint starts, please don’t add or remove stories from it. It messes up your team's plans and progress and leads to unfinished sprints.
- Create an Emotionally Safe Environment: You’re a member of the team, not their boss. So, don’t pressure your team into taking bigger commitments or finishing early. Scrum guides everywhere, including the one from Scrum.org put a heavy emphasis on maintaining healthy relationships with your teammates, as it is one of the cornerstones of effective teamwork.
These three best practices are the most important ones based on my experience. But, if you crave more tips on agile workflows and Scrum best practices for product managers, be sure to check out our separate guide on Agile product management.
Managing the Product Backlog Effectively
As I mentioned earlier, providing your team with clarity is one of the most crucial tasks of a product manager. The good news is that your product backlog is probably the single best tool to achieve it. So, here are a couple of product backlog management tips to help you with that:
Groomings: No matter how well you write your user stories, you will leave “bugs” there and you will want your development team to check and point them out to you. There’s also the fact that you’re not a developer and might write requirements that are hard to implement. Again, your team will tell you about that during the grooming process.
Prioritization Techniques: Take advantage of the numerous prioritization frameworks to understand which features are more equal than others. My personal favorite is MoScoW for its simplicity.
Alignment with Roadmap and Vision: The epics and stories in your backlog should represent the overall product goals and metrics you want to achieve. So, make sure to constantly review your roadmap when adding something to the backlog.
The most obvious sign that an organization lacks clarity is when you go across the organization and ask different people what they think are the success criteria for what needs to be delivered as the next big milestone, and you start hearing different stories.
Aligning Stakeholders in Scrum
The essence of the role of a product manager in Scrum is that you’re essentially the connecting link between the self-organized team and the outside world, be it users, stakeholders, or other teams.
So, apart from doing your regular stakeholder management duties as a PM, you also need to relay that information back to your team, and vice-versa. There will also be cases when you need to relay information from the team back to stakeholders.
A good example is the emergence of technical challenges that can affect the timeline or scope of a given feature. This is something that you need to discuss with the stakeholders and either accept the new timeline/scope or come up with a different solution (e.g. reinforcing the team with more expertise related to that matter).
There are also cases when your team may have come up with an interesting idea for a feature or a solution that is worth adding to the roadmap. Again, you relay this information to the stakeholders and decide if you end up adding it to your plan or not.
The Importance Of Agile Roadmapping In Scrum
While not directly part of Scrum, agile roadmaps are one of the tools that makes Scrum possible. After all, what’s the point of iterative planning if you’re using the Waterfall framework for your product instead of an agile roadmap?
In that case, whatever you call Scrum product strategy would simply be dividing a predefined and fixed plan with classical SDLC into 2-week (or however long your sprints are) parts. So, to make Scrum meaningful for your team, you need to be doing Agile interactive planning and building a roadmap capable of changing over time.
Now, to properly marry your Agile roadmap to your team’s Scrum processes, here’s what I suggest you do:
- Link roadmap items (usually Epics) to user stories on the product backlog. This way, there’s a direct connection between your tactical work (stories) and your strategy (roadmap).
- Present your roadmap to your Scrum team. This way, they will know where the product is going and keep upcoming features in mind when designing frontend or backend architecture.
- Take advantage of specialized tools Like Jira, Monday.com, and Clickup to streamline your road mapping and backlog management process.
Regarding the last point, those three tools are the ones that I have used in practice. However, there are many other product management tools that you can consider using instead.
Challenges In Scrum Product Management
While Scrum is a great framework for achieving your product goals, using this framework comes with its own set of challenges, such as:
- Your team or your stakeholders may not understand what Scrum is about. This can, obviously, lead to significant Scrum adoption issues, such as refusing to use certain artifacts. I recommend getting in front of this by illustrating the desired 'end state' of how the team and workflow will look when the framework is fully implemented.
- People (and you) may get confused about your role in the team and outside the team. Every company I had worked for in my career had its own understanding of what a Scrum PO is about. It's best to establish what it is—and what it isn't—for your team.
- The scope of the features you work on tends to expand endlessly. Not surprisingly, this makes it really easy to get into scope creep territory. Scrum teams need to be ruthless about what to take on and what to say 'no' to.
- The roadmap can get derailed easily. Having a relatively independent team that can choose what to work on, you might end up with them building things that are out of your roadmap. Keeping the end goal clearly in focus is paramount to avoiding this pitfall.
While these challenges are fairly common, the good news is that it only takes the PM a couple of sprints to figure out the Scrum process and overcome the vast majority of them.
Conclusion
Scrum is one of the best gifts to product managers out there. Thanks to the balance between being agile in the long run and strict within short iterations, you can avoid the chaos of a framework-less agile development process, while maintaining the ability to change the course of your product based on market response.
Hope you loved our guide. If so, don't forget to subscribe to our newsletter for more product management resources and guides, plus the latest podcasts, interviews, and other insights from industry leaders and experts.
FAQ:
What is the role of a Product Manager in Scrum?
Product managers, who typically take the role of the product owner in the scrum team, are responsible for providing the team with clarity by sharing with them the product’s plans, priorities, and the necessary feature requirements.
How does Scrum differ from other Agile methodologies in product management?
Unlike Kanban or other agile frameworks, Scrum is more structured and has clear rules on how to organize the work within the team using its events (standups, groomings, etc.) and artifacts (sprint backlog, product backlog, etc.).
What are the common challenges in Scrum product management?
The most common challenge is your team and stakeholders misinterpreting the scrum framework rules and artifacts and trying to modify its rules before the company has tried adapting to this new framework.
Can a Product Manager also be a Product Owner?
Yes. Product Manager is a profession. Product Owner is a role in a scrum team. Most of the time, the product owner in the team is a product manager. Sometimes, especially in small startups, CEOs can take the role of the product owner in the team.
