Maybe the more pertinent question is whether the move to product thinking is just fad that will pass in time. In order to examine that we need to first define what we mean by a product to see if it makes more sense than projects ever did.
But what, really, is a project?
The Project Management Institute define a project as “a temporary endeavour undertaken to create a unique product, service or result” which seems a good place to start because right away it highlights all the limitations of the project structure.
First of all it’s temporary, which means all those involved have to understand what’s needed, absorb all the historical information/systems that are changing and, at some point, the whole structure will be abandoned as the change becomes operational (or the objective is met, or the endeavour is abandoned). A project is a structure with a lot of overhead or, in lean terms, waste.
Assume an e-commerce web site needs to be relaunched to meet changes in market demand. The development team will have to assess the existing site, plan how to test and implement change with minimal impact to the business, hire new team members, create operational handover documentation, let teams members go and eventually disband (at least as far as build activities go). The product here is clearly the web estate and it’s purpose (selling goods and services) is equally apparent. Why artificially split the responsibilities of running the site and those of adding new features? Yes, the relative percentage of effort applied to these activities will change over time, but the product objective remains the same.
Products have clear objectives. Projects less so. If a project is created to achieve “a result” how do we make sure everyone involved has the same picture in their mind of what that result is? It’s not always easy and in matrix management organisations where people have to come together from various disciplines it’s made harder because the security team don’t care about features, they care about security. Enterprise Architects care about reuse and integration and points of failure. This is why it’s not unusual for five team members to work to five variations on what a good outcome looks like. But a product endeavour, led by a product manager, makes the outcomes clear. Experts in security or architecture may provide services to the product but the product takes precedence.
Marty Cagan said “the job of the product manager to discover a product that is valuable, usable and feasible” three characteristics that are hard to apply to temporary endeavours where the outcome can be unclear at the start and has a habit of shifting over time. He also says in the same article that “the truth is that many organizations out there are doing too many projects, many of which aren’t worth doing, and the result is that the organization is stretched too thin to do a good job with the good ideas.”
It’s not the lack of good ideas that hold organisations back, nor the abilities of the people who work there. It’s the reliance on delivery vehicles that are too technically biased and not rooted enough in business fundamentals.