Last week I participated in a Product Owner course facilitated by Gunther Verheyen. What triggered me was the part where we discussed the difference between having a project- or product focus. I've seen many organizations, Scrum Teams and especially Product Owners struggle with finding the balance. In this blog posts I'll share my thoughts about the difference between having a project or a product mindset.
First of all, there’s nothing wrong with a project. It's a great approach to realize a set of activities over an agreed period of time to achieve a particular purpose. A project can offer the necessary focus and stimulate collaboration and teamwork towards realizing ambitious and appealing goals.
Although project's can be a great approach, they are often used incorrect. Organizations kickstart lots of projects with temporary teams whose main focus is to deliver on time, under budget, and within scope. All these constraints are set in stone. When the earlier made agreements made are accomplished, the project is declared a success.
Other smells that often occur within a project culture is assigning developers based on their availability in the 'resource planning tool' and hereby continuously changing the team composition. Big upfront designs. Project management via Gantt charts. Extensive reporting with lots of irrelevant information, and having developers explain every hour they've spent.
Of course deadlines, budget and scope are important, but in the end it’s all about building the right product for the customer. It's about continuously optimizing the delivered value. A project that meets all the deadlines, within budget and with the original agreed upon scope can still result in a crappy product. Or to put it more bluntly: it will result in a crappy product. It means you haven't learned anything during the project or you haven't responded on gained lessons learned.
I rather focus on the actual product instead of the temporary project. Products also tend to have a longer lifetime than projects. Compose fixed, steady teams. Focus on the outcome teams deliver instead of the output. Give teams the freedom and responsibility to think of a strategy they believe will result in the best product for our clients. Facilitate teams in setting up a process that supports them building these products. Stimulate teams to pull work instead of pushing it. This will result in a clear focus for the Development Team and offers the opportunity for a sustainable pace of continuous delivery.
Using such a product mindset means measuring success with business metrics like user adoption and retention, and the revenue or cost savings generated per feature. This leads to less waste, more creativity, and more releases (from Scrum.org training material).
Great Product Owners understand that although there is value in using a project approach, they prefer a product mindset and thereby:
And most important: building the right product!
In this blog post I've described my take on the difference between having a project or product mindset. Of course the distinction isn't always this clear and for sure there's nothing wrong with projects. However, the often accompanied smells are wrong. Try to prevent or mitigate them.
What's is the mindset that is most common in your organization? What's you own mindset? Do you celebrate the success of a project or a product? Or both? I'm eager to learn from your experiences with this topic!
The Project Mindset
First of all, there’s nothing wrong with a project. It's a great approach to realize a set of activities over an agreed period of time to achieve a particular purpose. A project can offer the necessary focus and stimulate collaboration and teamwork towards realizing ambitious and appealing goals.
Although project's can be a great approach, they are often used incorrect. Organizations kickstart lots of projects with temporary teams whose main focus is to deliver on time, under budget, and within scope. All these constraints are set in stone. When the earlier made agreements made are accomplished, the project is declared a success.
Other smells that often occur within a project culture is assigning developers based on their availability in the 'resource planning tool' and hereby continuously changing the team composition. Big upfront designs. Project management via Gantt charts. Extensive reporting with lots of irrelevant information, and having developers explain every hour they've spent.
Of course deadlines, budget and scope are important, but in the end it’s all about building the right product for the customer. It's about continuously optimizing the delivered value. A project that meets all the deadlines, within budget and with the original agreed upon scope can still result in a crappy product. Or to put it more bluntly: it will result in a crappy product. It means you haven't learned anything during the project or you haven't responded on gained lessons learned.
The result will be "operation succeeded (the project), but the patient died (the product)"
The Product Mindset
I rather focus on the actual product instead of the temporary project. Products also tend to have a longer lifetime than projects. Compose fixed, steady teams. Focus on the outcome teams deliver instead of the output. Give teams the freedom and responsibility to think of a strategy they believe will result in the best product for our clients. Facilitate teams in setting up a process that supports them building these products. Stimulate teams to pull work instead of pushing it. This will result in a clear focus for the Development Team and offers the opportunity for a sustainable pace of continuous delivery.
Using such a product mindset means measuring success with business metrics like user adoption and retention, and the revenue or cost savings generated per feature. This leads to less waste, more creativity, and more releases (from Scrum.org training material).
Great Product Owners understand that although there is value in using a project approach, they prefer a product mindset and thereby:
- Creating and representing the product strategy and vision;
- Focusing on achieving customer delight;
- Continuously balancing priority, risk, value, learning opportunities and dependencies with each other to determine the next steps in building the right product;
- Creating a product roadmap with frequent releases
- Maximizing revenues and Return-on-Investment
And most important: building the right product!
What's Your Mindset?
In this blog post I've described my take on the difference between having a project or product mindset. Of course the distinction isn't always this clear and for sure there's nothing wrong with projects. However, the often accompanied smells are wrong. Try to prevent or mitigate them.
What's is the mindset that is most common in your organization? What's you own mindset? Do you celebrate the success of a project or a product? Or both? I'm eager to learn from your experiences with this topic!