Why is it that thinking in terms of projects collide so often with those thinking of products? What is the difference between Project teams vs Product Teams?
Let’s explore this.
Until Agile, most companies had a more or less working product management which was shielding the customers from development team questions.
Historically development teams were embedded in V and waterfall models, which work very well for products where components need to be assembled. In other words you know the whole system upfront and can plan accordingly.
Software development, however, is a creative process which can better be compared to painting a picture. Even a doctor’s visit to check the reason for certain symptoms comes closer than assembling a motor. Software development deals with uncertainty.
Therefore development teams had to adapt. We stepped away from waterfall and project thinking via Agile practices such as SCRUM to DevOps. We made the ability to react to change as quickly as possible to the core of our thought processes.
At the center of this agility is a continuous learning cycle adapted from lean manufacturing namely “build, measure, learn” to ensure continuous, validated learning and to maximize product market fit for our products.
This is why I think it is good practice to clearly distinguish between product and project.
A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.PMI
And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.
Project teams develop specific solutions for specific customers by assembling existing products and filling the gaps with customization and configuration.
The environment of a project is not suited to develop new products. If you do, you are developing customized solutions which do not scale and have an insufficient market fit.
Project thinking is important to get certain products to the customer that need a lot of coordination and integration. Those products are typically to be integrated into a bigger landscape and require lots of customization / engineering.
The main products of a project team are the planning, engineering and commissioning services to manage complexity and risk.
A product team is quite the opposite to a project team. It is an in many regards well-balanced, cross functional, empowered team that stays together and continuously explores opportunities as long as the product is alive. The goals are defined per iteration and base on moving targets, such as KPIs.
A product lives until it is discontinued. It lives! Whereas a project is defined by its uniqueness, scope, timeline and resources.
This is a major difference, and it seems this difference is hard to understand by many. It regularly leads to misunderstandings and awkward opinions / statements about the other side, especially when one side needs something from the other side.
Project folks expects defined scope to be delivered at a certain date whereas product folks is used to explore what is actually needed and maximize product market fit. For them it’s most of the time less important whether it is this or next month. This does not mean product teams live without a sense of urgency for time to market. Actually, it is quite the opposite. It simply does not matter if you get the wrong value to the customer earlier. What counts is maximum value and high scalability which are aligned with the companies’ vision as soon as possible.
As an organization, product thinking is important to identify what the market actually demands and to decide whether the cost is reasonable to address a certain value pool. It often addresses whole customer segments.
To conclude the importance of Project Teams vs Product Teams, both are equally important and it depends on your business where you set the focus but it is important to understand and communicate the differences as well as to make sure one side can leverage the specific value the other side provides.