Project vs. Product Thinking
I was at the Software Leadership Summit recently, and one of the themes that stuck with me was the difference between project and product thinking. So what is the difference?
In the 1990’s, product releases demanded a schedule. Given the iron triangle, you can’t have everything. Time was fixed, so scope and cost where the levers that were pulled. This is project thinking; the role of IT is to serve the rest of the business and meet their deadline (them/us thinking in a nutshell!).
In project-based thinking, engineering is seen as a cost-centre. Development teams don’t produce value, they cost money. Costs should be minimized as profit comes from following a set of instructions from the rest of the business.
This is bullshit. The team IS the business. The job of a software development team (or any team for that matter!) is to focus on the outcome that matters to the business (be it happy customers, money in the bank or renewals).
So, what’s the alternative?
Enter product thinking, rather than focusing on deliverables and dates, we focus on the outcome we want to achieve, rather than the output. This makes it more difficult to be predictable; we don’t know how we’re going to achieve that outcome. It’s harder for development too, we must continually explore, adapt and check assumptions with customers.
Given that thinking this way is much harder, why on earth would be do it?
Results. Below is a slide from a presentation by Barclays at London DOES 2018. In a project organization development would focus on that small area near the middle “dev”. Optimizing dev makes no sense whatsoever, it’s not the bottleneck and (as Goldratt/TOC says) optimization anywhere other than the bottleneck is an illusion.
In project-based teams the dev teams would celebrating optimizing that small slice of development. By the time it gets to Done, the customer probably doesn’t want it anyway and the whole cycle starts again. Dev might meet their deadlines, but they sure as hell aren’t part of the business!
Jeff Bezos describes the challenge here in a company letter about maintaining their competitive advantage:
“As companies get larger and more complex, there’s a tendency to manage to proxies. (…) A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organisations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.”
In project-based thinking, the process is often the area you look to improve. Think back to Barclays development team. Their process was (probably) awesome but they certainly weren’t owning the outcome.
In contrast, with product-based thinking, the whole team works on achieving an outcome, often taking ownership of a much wider task than writing the code.
By involving the whole development team (and more) in the wider process we get closer to our customers, understand the problems they need solved and iterate to find the solution. In this model, engineering is a profit-centre. The business invests in engineering as it’s identified by the revenue it creates for the organization.
This only scratches the surface in terms of the difference. To find out more I’ve had the following reading recommended to me.
- Mik Kersten has published a book exploring this in more details, and this’ll slowly bubble to the top of my (infinite) reading list.
- Sriram Narayan has written more about Products over Projects on Martin Fowler’s blog.
