The Project Manager is typically concerned with day-to-day progress of the Development Team. They rarely (or never) miss a Daily Scrum, they’re involved during the Daily Scrum and it might just be that they’re asking individual team members what they’ve done, what they’re going to do and if there’s anything blocking them. The Project Manager tends to measure the success of the team in the form of increased Velocity. The Project Manager tends to ‘report’ on Story Points, Burndown Charts and Velocity to the stakeholder during the Sprint Review. And typically, when the Development Team has delivered more Story Points than a previous Sprint, the Project Manager gets really excited!
A project manager is a professional in the field of project management. Project managers have the responsibility of the planning, procurement and execution of a project, in any undertaking that has a defined scope, defined start and a defined finish; regardless of industry. Project managers are first point of contact for any issues or discrepancies arising from within the heads of various departments in an organization before the problem escalates to higher authorities.
— Wikipedia, Oktober 2019 —
The Project Manager is also referred to as the velocity maximizer, resource utilization maximizer, wishlist administrator, sidekick to management and progress reporter.
The Product Owner as a Project Manager
With the many Product Owners and Product Managers we have trained and coached in their daily practice, we’ve observed the following patterns in Product Owners that we would classify as Project Managers:
- The Project Manager is used to, well obviously, to “managing projects”… Projects have a clear start and end. Projects are temporary. And projects are executed by a temporary team/organization. A project manager delivers output, which is then delivered to the line organization for further implementation and the actual realization of the expected outcomes. However, being a Product Owner is not a temporary endeavor! Product Owners are in there for the long run (not just for delivering some outputs) and are (or should be) accountable for the Total Cost of Ownership and Profit & Loss of the product.
- The Project Manager is typically concerned with day-to-day progress of the Development Team. They rarely (or never) miss a Daily Scrum, they’re involved during the Daily Scrum and it might just be that they’re asking individual team members what they’ve done, what they’re going to do and if there’s anything blocking them. Now just to be sure; It is not necessarily bad to know what is going on in/with the Development Team. However, your job as a Product Owner is not to manage the progress the Development Team is making within the Sprint! Your job is to maximize the value delivered by the Development Team, by making sure the (potentially) most valuable (or most risky) work is done first.
- The Project Manager tends to measure the success of the team in the form of increased Velocity. The Project Manager tends to ‘report’ on Story Points, Burndown Charts and Velocity to the stakeholder during the Sprint Review. And typically, when the Development Team has delivered more Story Points than a previous Sprint, the Project Manager gets really excited! Let's put Velocity into a sports context, let's say Soccer. A soccer team (normally) can’t win a match if they don’t have any ball possession (= no Velocity). However, the purpose of the match is not to have the highest ball possession right? The purpose is to win the match by scoring at least one more goal than the opponent. The same goes for Velocity. It’s not a bad thing to have a high(er) Velocity and be excited when the Development Team gets better and delivers more work (value) in a Sprint. However, the goal is to maximize the value, not to increase the Velocity;
- The Project Manager is often used to reporting, mostly on (traditional) measures of progress, such as scope, time and budget. But also about deliverables, progress percentages, risks, milestones and deviations from the original plan. Although it is not bad to keep an eye on the budget and on potential risks as a Product Owner, the way to deal with them is quite different;
- The Project Manager is used to “asking permission/approval” to a Steering Committee and to get projects/assignments with a clear scope, timeline and budget. As a Product Owner, you don’t go to a steering committee. Your don’t go out to get new projects and assignments… You create a product vision and strategy and start maximizing value,. As a Product Owner, you are accountable and responsible for the outcome, on the output that others want or ask for.
- Other associated behaviors with the Project Manager type of Product Owner are: being a micromanager, managing the metrics, setting deadlines, distributing tasks amongst team-members, managing via spreadsheets, being a people utilizer, reducing effort estimates by the Development Team, maximizing output and being a team coordinator.
The results/effects of acting like a Project Manager
Obviously, not al (Product Owner) Project Managers are the same, and not all the results/effects may be visible in your context. That being said though, what we typically observe when Product Owners act like Project Managers is:
- Focus on short term results;
- Little to none focus on long term outcomes (TCO, ROI, P&L, etc);
- Optimizing for delivering more output/story points/resource utilization is not the same as delivering more value for customers, users and the organization. Sometimes, it’s a freaking awesome idea to have someone ‘not produce anything’ on purpose (because it will bring you much more other value);
- The Development Team isn’t learning to be self-organizing their own work, they won’t be taking ownership (over planning, results, quality, etc) and controlling everything will cost you a lot more work and time yourself (which you can’t spend on more important things);
- Reporting progress (such as deliverables, milestones and deviations from the original plan) is not the core of the Product Owner role. Your job is not about creating reports;
- Being the carrier pigeon leads to less initiative taking, not thinking like an entrepreneur, not thinking as if you’re spending your own money or maybe even stopping all development because there is no more value to gain.
What you can do to move away from this stance
If you are a Product Owner or product manager, and you’re experiencing that you’re being held accountable for delivering projects or output (instead of value and outcome), then here’s what you can do (besides giving us a call of course):
- Use existing (governance) structures, such as the Steering Committee meetings, to move towards Scrum. For example, what has worked well for us in the past is to (without telling them) start doing the Sprint Review during the Steerco meetings. At first, you do it yourself and instead of using the traditional Steerco agenda, you start showing the product, showing the roadmap, start talking about the vision, start talking about value delivered and feedback. Later, you can slowly start inviting more people (Scrum Master, Development Team, other stakeholders) to the ‘Steerco’ which has actually become the Sprint Review already. In many organizations, it’s easier to change the governance afterwards, when people got used to the new way of working, instead of changing the governance upfront, when the least is known…
- Start talking about different things with stakeholders. Stop talking about progress percentages, about deliverables and about the expected release dates of new features. Instead, start talking about the goals that you want to achieve. Start talking about the product vision and what you think contributes most to achieving the vision. Take initiative and create your own roadmap for the product, explain why you’ve put goals and features in a certain order. So basically, start taking ownership of the product and create your own plan! If you don’t make your own plan, you will become part of someone else’s plan...
- Make sure to start talking about stuff like Return on Investment, Customer Satisfaction (e.g. NPS) and Total Cost of Ownership. Move away from the temporary characteristics that projects have, and focus on the long term effects and results. In the end, both you and your stakeholders need to change your mindset and let go of project-approach-thinking.
Want to learn more?
This is a blog from the Stances of the Product Owner series, in which Professional Scrum Product Owner Trainers and Consultants Chris Lukassen and Robbin Schuurman explore preferred and misunderstood stances (attitudes) of Product Owners and (Agile) Product Managers. Read more about the Stances of the Product Owner on this page.
Go experience the Stances of the Product Owner!
If you’re a Product Owner, Product Manager, Scrum Master or Agile Coach with about a year (or more) of experience under your belt, go and explore the Stances of the Product Owner in the Professional Scrum Product Owner-Advanced class. Find a trainer to your liking or in your area, and deepen and expand your Product Management knowledge and skills. And let us know what you think about the training! What did you like? What can be improved? Let’s collaborate to take the profession of Product Ownership to the next level.
If you’d like to experience the all-new Professional Scrum Product Owner-Advanced class, go to Scrum.org to find a class in your area. If you’d like to participate in one of our classes, check out our Xebia Academy page for more information or inquire for an in-house class via training@xebia.com.
