Apr 232013
 

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.

Discussion

  8 Responses to “Project Culture, Product Culture, and Gaming Theory”

  1. I have been thinking a very similar issue, in what kinds of software are best suited for agile, and what kinds are not. I separated the software into two types: a software product for sale, and most everything else, like supporting an org’s internal processes; so I look at it as process versus product.

    My thought was that org’s have been developing and selling products for a long time. It may start with a vision (horseless carriage), and work through versions or prototypes before it is introduced (Model T) with an initial set of features (any color you want as long as it is black).

    Sound familiar? When software is not just used by an org, but sold as a product, it should follow a product life-cycle; agile is the appropriate approach, because I see it as the digitization of all product development.

    So don’t use projects for products, and don’t treat products like a process; that leaves the (so far) unstated issue – what approach works best for other types of software. The hopes that agile could eventually supersede all other approaches will be dashed I think.

    • David,
      thanks for your thoughts, to which I mostly agree. The one point I did not understand is why you think that internal org support does not show product characteristics. Except rare cases, such as one-shot BI queries, most of them have a life-span of several years, sometimes decades. The only type of software I’m aware of that has absolutely clear project characteristic is probably spacecraft control systems (but this is rocket science anyhow 😉

      What is important for me: This post is not about agile software development, it is about management thinking. You’re right, agile fits very well to product thinking and provides transparency if you have a misfit. However, agile won’t help you too much to solve the problem. You need to change management thinking if it doesn’t fit.

      • Yes, I see the post is not about software development, but it just struck a chord with me, the closest I have seen to what I have been thinking through.

        To your thought about product characteristics: I suppose there is some common aspects overall, but my view is more on how you decide what to deliver for a product over time is different than a process. The initiation of a process by an event or trigger, its execution, and then completion needs to leave a business in an acceptable state; you can’t (or shouldn’t) implement half a process, that leaves the business hanging in an unresolved state. Maybe it is not that big a difference in the long run, but the needs of the process have to supersede any desired implementation of features. When you are actually planning and defining what needs to be delivered that can be used, to me its a major difference between product and process.

        • David,
          ok, I understand. I usually discourage people from thinking in features and recommend thinking in user/stakeholder benefits. In is thinking a working business process comes quite natural. But that’s probably another blog post on its own…
          Cheers
          Jens

  2. This is gold. Especially as a lens to view management pathologies in the public sector, where election cycles and the budgeting process mean so much that would otherwise be considered an ongoing program (the parallel to a product, if I’ve understood) is managed as a project. You’ve made it clear the issue is so much more than just not having a LT perspective, but in having completely the wrong management approach.

    Thanks for what should prove a useful reference!

  3. Jens,

    Wonderful piece. Spot on. Glad to see someone write about it.

    For 8 years I tried to run an IT app-dev shop like a product shop (my prior 15 years of experience). Luckily, we had a division President who understood multi-year funding and bought into iterative development; but many other’s in the org did not.

    Perhaps just to make me feel better, I used to make a silly analogy to try to convince people of the need for product thinking. Buying custom IT software is like buying a pet, not a piece of custom furniture. The pet demands a chunk of money up front, but then you really start to pay – food, vet, training, replacing chewed up shoes, etc. Custom furniture demands a big up front payment, but then only polish every month. I think the analogy just made me look stupid, but a few people did understand.

    Your hunch that the lack of product thinking is due to the predominance of project-only experience may be true, but I think there are other design forces at work. As a Universal Darwinist, I believe that product thinking would emerge if the system valued its attributes. Other factors that may be at play are:

    – if IT software were funded on total lifecycle cost, few would get funded at all because of the sticker shock. More than a few people have reported “if they knew what the cost was really going to be, they never would have funded it!”

    – without a way to measure real value (as a product company can – either it sells or it doesn’t), knowing when to put on the brakes or step on the gas is hard to calibrate — perhaps, to your point, requiring product experience.

    – the product company must find a market or die. The IT shop only needs to keep the customer sufficiently satisfied not to fire them.

    – the waterfall model of software development is deeply embedded within IT and finance consciousness. Despite repeated admonishments by software experts and substantial evidence to the contrary, leaders persist in funding BIG Waterfall.

    – finally, IT doesn’t appear to be motivated by efficiency. IT dramatically underestimates the cost of software project startup and the cost of knowledge loss. Yet, IT software project funding is the poster child for startup-hire/shutdown-fire work. This is the least efficient way to build and sustain enterprise applications. QED.

    I’m sure there are many other factors. However, this is your column and I’ve written too much already. I thank you for the piece.

    Best, lef

    • Lawrence,

      thanks for your thoughts, I think they add pretty nicely into the discussion. Indeed, there are several other factors sustaining project thinking, financial and legal being some of the most powerful ones. In general I think the crux is that all kind of long-term thinking requires some predicting and as Niels Bohr (or Albert Einstein, depending on the source) said, things are hard to predict, especially if they concern the future. One of the basic problems is our belief that there is something like an “objectively correct decision” in management and people who are smart enough are capable of finding this decision. Hence, if a decision proves to be wrong, its management’s fault, they just were not as smart as their (internal) competitors. This leads to short-sighted (because easier to predict) management actions. But this is yet another advisor to be written…

      I’m glad you managed to convince your org to think more in the long-term. Keep on fighting, its an infinite game!

      Cheers
      Jens

  4. Thanks to Jen and Lawrence for the thoughts. I do agree that the lack of product thinking may not only be due to the predominance of project-only experience but other design forces at work which is socio economic and legal or legislative.

    I also agree that product and project management differ. However I think that market forces can enhance or distract project management plans and as such can impact negatively or positively on the product goals and outcomes.

    Best
    Anneke

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)