My new book “Managing Product = Managing Tension”, which is due next month, covers the numerous tensions and challenges that we face when managing products. Below is an excerpt from my book, in which I look at what I call the ‘I love it when a plan comes together’ tension; the frustration caused by a need for certainty on the one hand versus the unpredictable nature of developing products on the other.
‘In preparing for battle I have always found that plans are useless, but planning is indispensable.’ Dwight D. Eisenhower
_______________________________________________________________
My thinking that projects would materialise exactly as planned …
As I mentioned earlier, before I became a product manager, I used to work as a digital project manager. At the beginning I managed a lot of government projects, and I had to create project plans in Microsoft Project. Each time I put together such a plan for, let’s say, the build of a website or an app, the world felt like a better and more certain place. In my project plans, things always happened according to plan within the set timeframes, seamless handovers between different teams, everything according to spec and all within a pre-agreed budget. Any project dependencies would be dealt with smoothly by the various people involved in executing the project …
… sounds of breaking glass.
_______________________________________________________________
I have learned over the years, and the hard way, that working on technology projects or products does not follow a linear or predictable path. Plans are malleable or, as the quote by Fujio Cho, Chairman of Toyota Motor Company, goes: ‘Plans are things that change’. These are just some of the things that I have seen go wrong when working on software products:
Unexpected complexity ‒ The underlying technology or workflows turn out to be way more complex than expected. As a result, thinking about, writing and testing software code takes longer than anticipated.
Altered scope ‒ We all say that we should not be doing it, but it still happens regardless: scope creep. Specific product features are agreed, often complemented with a list of things that are not in scope, upfront. As soon as we start working on a product, a request comes from left field, suggesting: ‘wouldn’t it be nice to have _____.’
Communication breakdown ‒ People responsible for different aspects of the product fail to communicate effectively with each other. The development process thus becomes a relay race where colleagues drop the baton in an effort to pass it on. Think, for instance, of the designer who has spent a lot of time designing an elaborate user interface, which the engineer then says cannot be implemented …
Change in priorities ‒ Whilst the product team has committed to building a specific product or feature, a new commercial opportunity arises for the sales team and a revision of priorities is required. Or your biggest competitor has just launched a similar feature. This often means that teams have gone back to their product roadmaps to discuss whether it makes sense to deviate from the items on the roadmap. This can generate significant friction if the organisation treats the roadmap as a set in stone plan, an artefact that promises certainty and predictability …
Managing products is an uncertain business. It is therefore an illusion to think (1) that we can fully control a successful execution of a plan and (2) that everything will go as planned. However, this does not make planning or roadmaps redundant; a product roadmap is a beneficial communication and collaboration tool, as long as we accept that we might have to deviate from what was initially planned.
