Scrum is in the software industry for decades. It spread around 2002. Product Management practices are in the industry for decades as well, and they are now rapidly being implemented in more and more companies.
And with a new set of practices arrives, the natural question is being asked: “How does Scrum compare to Product Management?”.
The answer is actually clearer than what some might expect.
Scrum, Agile, and their objectives
Scrum, and Agile in a broader approach, are methodologies or frameworks to structure and organize software development teams.
They exist because of challenges the software industry had some decades ago. The entire industry was struggling to deliver software products efficiently.
Yes… I see what you are going to say: we are still kind of struggling with this.
To answer this challenge, the main objective of Scrum (and Agile practices) is to ensure that the technical teams can deliver their output in the most efficient way possible.
They both tend to remove friction as much as possible. And by design, they have a very strong focus on managing uncertainty and risks in the delivery process.
Scrum and Agile have a very clear objective: ensuring the most efficient delivery of outputs.
We can validate this by looking at the metrics available. Focusing on Scrum only, there are very few metrics: team satisfaction (during the Retrospective) and the Velocity of the team (the actual delivery).
However, in the Scrum Guide, there is no measure of the business value, or the user impact – because that’s not the objective of Scrum. Business value and user impact measurement is NOT the problem it is solving.
Once again, the problem solved by Scrum is optimizing the output delivery of a team, by allowing a (re-)prioritization every Sprint.
The limits of Scrum and Agile
The best Scrum training and practitioners out there will tell you that you become an expert in Scrum when you’re available to highlight the limits of the framework.
I am sure you’re seeing me coming after you read the previous part. Scrum has a huge limit: it does not focus on the outcomes.
There is absolutely no guidance for the Product Owner to effectively work on and measure the impact the team is having on their users. And it’s the same for the business impact.
The Scrum Guide for the Product Owner is pretty simple:
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.
All the user feedback, stakeholders management, and prioritization are hidden behind this simple line: “Ordering Product Backlog”.
I think this is exactly where Scrum falls short. And at the same time, it is where all the value of Product Management resides.
If we want to oversimplify and severely criticize Scrum, here we go: Scrum is happy if the team has a stable Velocity. If this Velocity brings 0 value to the business or the customer, Scrum does not care. As soon as the Sprint is ordered, it’s OK.
Don’t get me wrong! I am a HUGE fan of Scrum. I have always been working with it. When it’s not implemented in my team, I am doing everything I can to implement it properly.
But Scrum has its limitations. And it’s even clearer when you are a Product Manager. You definitely have to add things around Scrum to be able to manage a Product efficiently.
One last time: Scrum will only help on the delivery (output) aspects – not the impact you’re having (outcome).
How is Product Management working with Scrum?
This is why Product Management is having such success: it essentially focuses on the impact (outcome).
Being maximizing the impact a Product has on the business (well, it’s obviously often about driving up revenues), or maximizing the impact on the users (which, overall, drives up the revenues…) – Product Management is focused on increasing the outcomes.
Having a full Sprint or not is not a concern: reaching business goals is!
Product Managers and Product Leaders are mainly concerned with measuring the priorities and the impact they are actually having on the key metrics and objectives.
Let use an example: we have a long list of User Stories in our backlog.
Scrum is saying “the Product Owner will prioritize these User Stories before putting them into the Sprint backlog”. Nothing more.
Product Management practices know how to prioritize. The entire profession is working toward consistently controlling and optimizing the prioritization process. This is the real game of Product Management: knowing why to prioritize specific items over others.
User interviews, stakeholder feedback, revenue objectives, acquisition goals… The real prioritization process involves a lot of details and decisions.
However, prioritization, deciding objectives, measuring impact… they all have absolutely no value if you don’t deliver something at the end.
Focusing on the expected outcomes is crucial to prioritize effectively. But the delivery pipeline and the outputs are still a (very important) subset of the Product Management practices.
How Product Management is using Scrum?
Delivery and outputs management is a subset of Product Management practices. It’s exactly for this reason that Product Managers and Product Leaders are often using Scrum: when it’s time to plan for deliveries.
Once the discovery phase happened, the users were interviewed and the stakeholders agreed on the objectives to reach. It’s time to sit down with the Development team and work on the actual delivery phases.
I know, I know… Scrum is not meant to create a roadmap or to plan and commit to multiple Sprints in advance.
But that’s alright. Product Management is all about hypotheses. Scrum is all about reacting to changes. That’s probably the best couple you could create.
Product Management will come with a strong framework for prioritizing user needs and business requirements. It will come with clear outcome objectives and will share a very clear vision of “Why we are building this product”.
Scrum will come with a very reliable framework to deliver as much as possible, in a world full of hypotheses. It will know how to overcome the challenges discovered on the road.
How does it do it? With iterations! Scrum is allowing you to update the requirements very often so that you can adapt to changes and new discoveries.
Technical limitations? Fine, Scrum is ready for that.
Slight changes in the business objectives? Fine, Scrum will adapt.
Discover something new about the users’ needs? Fine! Scrum knows how to adapt.
That’s where Scrum does its magic and why I love working with it as a Product Manager. You can plan just enough to be in control – with the team – of the delivery, but you are also able to adapt to reality very quickly. And as it’s made for that, it does not create frustrations. Everyone knows and is ready for updates!
Scrum is a tool available in the Product Management toolbox, among others. After all, you could use Kanban or even Waterfall to drive your delivery process as a Product Manager.
Final thought: the magical recipe “Product Management + Scrum”
So we are almost reaching the end of this post about Product Management and Scrum. We discussed many topics, so I wanted to make a short and sweet summary 🙂
I do think that Product Management is better done when using Scrum.
These two sets of practices create the perfect couple to run an efficient, smart, and adaptable Product strategy.
If you are a Product Leader, here is my piece of advice: don’t focus on the User Stories right away! In the beginning, you don’t know what you’re building and why you’re building it, so refrain from writing requirements. Scrum won’t help you to discover your objectives. And sharing requirements without objectives won’t help your team build the best product.
Scrum is useful at the end of your process, not at the beginning. This is exactly what we are teaching in our online course, step by step: 80% strategy, 20% tactics.
Here is a typical process I would follow:
-
- Don’t mind about User Stories and Scrum yet
- Follow Product Management practices to understand your users and your business
- Get an agreement on the objectives (outcome) to reach
- Use your favorite tool to “imagine” a scope (often called an MVP for new products) that is making sense
- Start minding about Scrum now!
- Sit down with your team and take the role of a Product Owner
- Write down User Stories
- Plan for a few Sprints (work with a Scrum Master if you need assistance)
- Release block by block.
- Measure.
- Adapt your plans.