Tell me if this sounds familiar:
- Well-thought-out strategies change seemingly every other quarter.
- 9-month projects that take two years to complete.
- Disgruntled managers talking about “low velocity”, “lack of ‘can do’ culture”.
- Skeptical employees talking about lack of vision, bad planning, politics.
- Spending lots of time on planning, replanning, scope-downs
- Disappointing launches that customers generally disregard
- Managers and employees quitely blaming each other for failures
- No retrospectives, and no improvement from one project to the next
What’s going on?
Most medium-large projects I see are suffering to some degree from this vicious cycle:
Why is this such a common phenomena? Are all managers clueless? Are all employees incapable?
The answer of course is no. There are actually a number of things at play, but in this post I want to focus on the biggest culprit — our blind and deeply ingrained belief in Plan & Execute.
Plan & Execute
Plan & Execute (P&E) is simply the method by which we start a project by creating a detailed plan and then follow with faithful execution. From the pyramids to jet fighters, P&E is how we’ve been building things and it has served us tremendously well.
20th century business management, starting from Taylor’s Scientific management, embraced Plan & Execute as a core foundation. Managers were given the role of planners and employees the role of implementers. Phase-gate/waterfall, roadmaps, gantt charts, business plans and strategic plans are variations on the theme. Over time detailed plans became a prerequisite for funding and the yardstick for project progress. Success defined as completion of the project as planned, on time and within budget.
Plan & Execute in strategy planning.
Source: Farcaster at English Wikipedia, CC BY-SA 3.0
If you prefer to receive posts like these by email sign up to my newsletter.
Plan & Execute in Tech
In tech we largely inherited business management methodology from predecessor industries and with it came P&E — strategies, roadmaps, project plans, even requirements specs are forms of planning.
But here is where we ran into trouble. P&E that has served us so well for millennia, is running tech projects into the ground. The reason can be summed up in one word: uncertainty. Unlike bridge-building or car manufacture, high-tech is an industry riddled with unknowns — first-of-a-kind products, untested technologies, new markets, unexpected competitors, and fickle customers. Nothing we have built in the past was this unpredictable. To complicate things further, our means of production, software, is itself a type of technology that is infinitely malleable, constantly evolving, and highly prone to generating defects. The bad news — under conditions of high uncertainty our ability to create realistic plans and to execute them accurately drops sharply — in some cases to near zero.
Let’s break this down a little more to understand why:
- It’s virtually impossible to know which ideas are going to succeed — history is full of breakthrough tech ideas (Google Search, Apple I computer, GUI) that were rejected by seasoned executives, and costly money pits (Google+, Microsoft Zune, Apple Newton) that got deep funding. It’s easy to criticize such decisions, but the fact of the matter is that it’s just impossible to say if an idea will have the desired outcome months or years in advance when most things are uncertain. Fuzzy metrics and flexible definitions of success help us stay blissfully unaware of this, but once systematic measurements like A/B experiments are put in place, we get a clear and very sobering picture. Even the best companies discover that at most 1 in 3 ideas will yield any measurable positive impact, and often in projects with higher levels of uncertainty the ratio is far worse.
“It is humbling to see how bad experts are at estimating the value of features (us included). Every feature built by a software team is built because someone believes it will have value, yet many of the benefits fail to materialize.” Microsoft research paper, 2009
Workshops and Keynotes
In my Lean Product Management workshops you’ll learn how to develop product strategy, research your market, set goas, prioritize ideas, experiment, and work effectively with managers, agile teams, and stakeholders. I include unique frameworks and tools such as GIST, the Confidence Meter, and the AFTER framework, which you won’t find anywhere else.
These consistently highly-rated workshops are designed for product managers/owners, product directors/VP/CPO, and for product leadership teams (PM, UX, eng-lead, data, researchers).
Both public workshops and company-specific workshops are available now.
- We’re very bad at planning and estimations — Psychologists Daniel Kahneman and Amos Tversky demonstrated that people and teams tend to be overly optimistic about their plans — underestimating the time, costs, and risks, and at the same time overestimating benefits. This is a cross-industry phenomena, known as the Planning Fallacy, but in tech it can have huge margins of error — plans can easily run over by a factor of 3 or more. We’re also susceptible to other cognitive biases when dealing with high uncertainty, ambiguity and too little or too much information — groupthink, narrow framing, anchoring, halo effects, risk aversion, sunk cost fallacy and hundreds more. Often we give up on finding rational answers and substitute the question “which option is best” with “which option feels best“, falling back to relying on intuition and gut feeling.
- Plans don’t work as expected — There is one big precedence for planning under conditions of high uncertainty — war. Military historian Stephen Bungay observed that battle plans tend to suffer from three types of gaps during war: Information gap — we’re always planning with insufficient information; Execution gap — execution seldom accurately follows the plan; Effects gap — our actions don’t always generate the expected outcomes, and sometimes generate unexpected outcomes. Prussian field marshal Helmuth von Moltke famously summarized this as “No plan survives first contact with the enemy.” Our plans in tech suffer from all three gaps; often they are already outdated the day they are published.
But It Gets Worse
In tech we have also inherited the practice of multi-level planning. Our best practices look something like this:
I call this “the planning waterfall” and it complicates things further:
- Huge time and effort drain — as we have multiple, cascading levels of planning, it’s not uncommon for teams to spend half of the overall duration of the project just in planning and replanning. In large companies the effort involved is immense — just getting all stakeholders to agree is a momentous task.
- It’s a waterfall — As the plans get outdated very quickly, changes are unavoidable. However the waterfall structure is resistant to change, making plan changes expensive and painful and causing cascading replanning effects. Consequently we’re tempted to stick to an obviously out-of sync plan, just to avoid the pain of stopping everything and for a replan.
Losing trust
Plan changes and delays are also a major source of discontent and friction. Employees expect smart, well researched, accurate plans. Managers expect ambitious but achievable schedules, efficient execution, and completion on time and on budget. As neither side is actually capable of delivering on these expectations, mistrust and frustration grow. When projects go sideways, as they often do, toxic cynicism and finger-pointing can ensue, as well as feelings of guilt and hopelessness. The thinking is often that “wrong culture” and personal inaptitude are the root causes, people leave disgruntled or are asked to leave. An outsider view will typically reveal that the no one is directly at fault, but everyone is locked into a bad system.
What can we do about this?
Let’s start with the things that don’t work:
- Trying to plan better
- Trying to execute better (or control the execution better)
- Hiring better people (always a good practice, but here will at best will give marginal improvements)
- Pretending it’s OK (“We launch and iterate”, “We fail fast” and “We learn from our failures”)
- Sweeping the problem under the rug (AKA success theater)
Things that do work
Over the years good methodologies have attacked parts of the problem from different angles, the most important ones being:
- Management by Objectives, OKRs
- Agile development
- Kanban
- Design Thinking and user-centered design
- Lean startup
Done right each one of those should have a major positive effect. However we have found ingenious ways to merge those into what is still essentially top-down Plan & Execute: OKRs that are all about executing the plans, water-scrum-fall projects with no customer input, a pinch of “user research”, and sprinkle of “MVP” that never actually change the plan, and so on. The pain and waste is still there because at its core the planning system hasn’t changed.
GIST — Goals, Ideas, Step-projects and Tasks
GIST is the planning system that I started using while working at Google and later further adapted based on the principles of Lean Startup and Agile Development. I’ve since introduced it to multiple companies.
With GIST we decompose planning into four tiers: Goals, Ideas, Step-projects, and Tasks. Each has a different planning horizon and frequency of change, and may use different tools to track, but together they constitute all the core planning any company and team needs to do.
- Goals — Goals explicitly call out the outcomes we wish to achieve, but not how we achieve them.
- Ideas — Ideas describe hypothetical ways to achieve the goals. Ideas are collected and prioritized and kept in the bank.There can be many ideas how to achieve a given objective, but we don’t pick one upfront and kill all the others.
- Step projects — here we break the bigger project behind the idea into smaller steps, each no more than 10 weeks long, and execute them one at a time. For example: mockup → prototype → MVP → dogfood → beta → Launch. In accordance with Lean-Startup’s Build-Measure-Learn principle, each step-project is actually an experiment that tests the idea.
- Tasks — Finally, each step-project is broken down to bite-size activities which we call here Tasks. This part of the system is well covered by agile planning tools, kanban boards and other modern dev project management techniques.
I first described GIST in this blog post. The response was very positive — people have asked to hear more. I am now writing a condensed book that will explain how to implement GIST in practice, due later this year (sign up to my newsletter to receive updates and a chance to be an early reviewer).
Final Thoughts
Whether you use GIST or something else, the good news is that abolishing Plan & Execute is now a real possibility, one that tech companies are already embracing. It is not a quick and easy transition — core things including mindsets and beliefs have to change , but luckily they don’t have to change all at once. Once the new planning system is put in place the results are very consistent — lightweight plans that are built for change, lower management overhead, improved team velocity and autonomy, better cross-company alignment and ultimately better products and solutions.
Itamar Gilad (itamargilad.com) is a product consultant and speaker helping companies build high-value products. Over the past 15 years he held senior product management roles at Google, Microsoft and a number of startups.
If you prefer to receive posts like these by email sign up to my newsletter.
