The more agile software development becomes mainstream, the more often I run into a typical pattern of management mismatch. It comes in several flavors. A recent client CTO who is responsible for the IT of an online store illustrates one example. “We have just raised an additional budget of 1 million Euros for this year to implement this fantastic feature,” he told me. “And now I’d like to talk with you about how to cut the teams.” A management workshop on agile contracts with another client demonstrates a second example. The workshop began with its current situation: “We want to build this platform and already have three Fortune-20 clients on our list. Our mission is to run each client as a single profitable project.”
Statements like these are pretty common, and it may be a little tricky to see where they’re problematic. However, in both cases the managers started to understand the full set of their problems once we had uncovered the root cause: using project management to manage a product.
There are several ways in which product and project management differ. The most striking difference involves time scope. A project is by definition an endeavor to reach specific goals at a certain point in time with limited resources. It is temporary by nature. The goal of product management is not to reach a certain goal or deadline, but simply to keep the product in the market as long and as profitably as possible with limited starting resources. Before these starting resources are gone, the product should earn enough money to feed itself and grow.
Thus the manager responsible for this product — let’s call her the product owner — has more options than a project manager. She can invest into future profits, she can cross-finance between different clients, and she can deliberately choose to run parts of the product at a loss if that pays off in another area. On the other hand, she has additional obligations: she needs to take care that technical debt does not pile up until it strangles the product, she needs to defend long-term decisions even when their pay-off is in doubt, and she needs to balance the interests of many different stakeholders. These considerations are rarely part of project management, and project management techniques do not support the product owner in making these decisions.
This difference is well known in gaming theory. It is the difference between a finite and an infinite game. A finite game has a fixed set of rules and you play it to reach a goal, usually to win the game. In infinite games, the rules change while you’re playing and the goal is to stay within the game — the longer the better. Soccer, school, and projects are examples of finite games. Marriages, companies, and products are examples of infinite games. Playing finite games successfully requires a different set of strategies and tactics than playing infinite games.
Pumping into a product an additional million-Euro budget for one year is a typical project action. Once the new feature is built, there will be no budget (and no developers) to improve it, to support it, and to keep it alive. Building a platform as a result of “a series of profitable projects” leaves no room for investments, for strategic decisions, or for innovative approaches. Both are tactics to win finite games, but they are rarely helpful to stay within an infinite game because they optimize the short-term at the expense of the long-term.
So why is this pattern so common that we hardly recognize it as malfunction? Often you find the answer in the personal history of managers. Many of them started their careers in project-driven enterprises – which is often a great place to gather a broad spectrum of experiences. In addition, the budgeting and reporting structures of many organizations support quarterly or yearly thinking at the expense of long-term thinking. Finally, the predominant command-control structures stemming from our Tayloristic industry culture discourage the idea of a product owner who has full responsibility for product success.
What are your options? A very fundamental solution is to establish a beyond-budgeting system, but that is typically beyond the scope of even very senior executives. However, understanding the difference between a project culture and a product culture and recognizing the problems a mismatch causes is already an important step you can make just inside your head.