Skip to main content

Project Mindset or Product Mindset?

March 23, 2016

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 post, I'll share my thoughts about the difference between having a project or a product mindset.

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 the project's can be a great approach, they are often used incorrectly. 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 has 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 a 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 in 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 your 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!


What did you think about this post?

Comments (7)


Mark Noneman
12:56 pm March 28, 2016

Great post, Barry.
And another typical issue (of many others) is that projects tend to be funded for the specific scope (requirements) of the project only. It's pretty common for project-oriented cultures to have a separate "maintenance" team that fixes defects and makes small enhancements in between projects.
The problem in that environment, is that the project development team doesn't get to learn from the production problems they created. Not only does quality often suffer because the project deadline is looming, the same people that take shortcuts do not have to pay for the consequences of those decisions.
In my experience, quality is often better in product-oriented cultures.
Scrum on!


Monika Kirdorf
09:56 am March 29, 2016

I think it is important to have a product mindset. That's what I love in the Product Owners idea even if I didn't get yet the chance to practice it in a job.
The product and customer empathie is very important. You have to love and understand your product to make it the best and satisfying for all the stakeholders according to the business value.
This mindset brings me so much joy and energy.
So product first, project next.


tushar
07:38 pm April 6, 2016

I like to track middle path. In my experience PO need to keep a balance between product and project mindset depending upon context. This context even changes during an engagement (I do not want to use word project or product).


kristofvbn
04:13 pm September 22, 2016

It's a fundamental choice when you want to scale agile and have to consider rebuilding your delivery teams. Do you create scrum teams from a project or product point of view. Obviously you have a roadmap in mind including hopefully some results on short term that you want to achieve. If the project is big in parallel activity, you are enforced to split the teams. Subsequently you need to decide whether you split by product (or technology) or by 'end to end' subproject delivery. I have mostly seen organisations that split by product and where integrator roles are created above the scrum teams to ensure synchronized delivery. You have all experts together for a certain domain, but when it comes to ensuring the synchronized delivery as the inter-team communication it is more difficult. If you have part of your product or an older version of your product already in production, I believe that you will find it more easy to treat your incidents as backlog items in a product based team than a project based team.


Stefan A. Feldmann
07:59 am April 16, 2018

True. What I also experienced often is that external resources join for the period of the project and leave at the end taking most oft the knowledge with them.
The maintenance team is then left alone trying to figure out how that thing works.


Philip Brands
03:22 am December 7, 2018

But then perhaps the self-organizing quality of the development team is not fully functional. They should have a focus to embrace and adopt this 'external' knowledge in their process.


Sujit
04:11 pm May 6, 2021

How to shift from a Project mindset to a Product mindset? Especially, when the development is mid-way and the team or organization wants to have this shift? Won't it affect the cost incurred, the scope, the short term and long term timelines, resource allocations, resource constraints, budget prepositions and many other variables?