There’s a common and highly destructive pattern I’m seeing time and again (and likely you have too). The leadership team falls in love with a big idea and turns it into a big project. This project becomes the top priority—apparently the future of the company depends on it. Other projects (including yesteryear’s top priorities) are deprioritized or defunded. Competing ideas are squashed like flies.
Experienced middle-managers and employees know there’s no point resisting the oncoming tsunami. The smart option is to ride the wave. So everyone gets spontaneously “excited” about the new thing: middle managers amplify the message, people come up with ways to take part and contribute. The project grows even larger and more important.
All projects turn out to be harder and more costly than we first think. Much more so large projects that span teams and departments. Invariably progress is slow, schedules run late, scope is cut, and it takes an heroic effort to cross the finish line. But when the product finally launches (much later than anyone expected) the results are underwhelming, to say the least. Customers are generally uninterested, key metrics are unaffected.
But this project is too important to fail, so the leaders now rally the troops for a massive rescue operation. Product teams launch supplementary features and redesigns. The marketing team badgers the users with reminders and cross-sells. Sales are on the phone trying to get customers to adopt. It feels like we’re just one feature, one campaign, away from breaking through. But we’re not. The vast majority of these projects end up as a colossal waste of time.
I’ve written about the project death-cycle before. In this article I will talk about some of the deep-rooted causes, and what we can do about them.
Output-focus is a key contributing factor here. In a company where goals and incentives are centered on execution and production, doing becomes more important than achieving. In this sense the big project serves an important purpose: it gives everyone something big and important to work on (and later to boast about in perf reviews.) Left unattended this culture can breed a particular type of manager that uses big projects as springboards for promotion. Here’s what Eric Ries had to say on the subject:
“If you’re charismatic, you can get resources for anything … then you can engage in a ton of what I call “Success Theater”, to try to make it seem like you’re a big success. And so, those people tend to get the celebrations, whether they actually add any value or not. They’re like a cancer in most organizations”The Lean Startup | Eric Ries | Talks at Google
Output matters a lot in factories and in construction sites, where we know what we produce is of value. In most modern businesses we can never make such an assertion—there’s just too much uncertainty, complexity and constant change. There can be many ideas, and most will create little value, if at all. So setting goals for launching one big, unproven, idea is a recipe for tremendous waste.
The alternative is to set goals for outcomes—the benefits we wish deliver to the customers and to the business. Outcomes-based goals can be as bold as we need (US president John F. Kennedy famously asked NASA to land an astronaut on the moon). Thereafter it doesn’t matter if it takes one big idea or ten small ones as long as we achieve the outcomes.
A case in point—In 2011 Google launched Google+, a social network that aimed to compete with Facebook. I worked at Google at the time—it was a massive project that engulfed the entire company. However, despite our hard work, and a product that (in my opinion) was very solid, Google+ failed to gain real traction. People simply didn’t need another social network. Whatsapp, Instagram and Snapchat did much better in the social space (and threatened Facebook much more). They achieved the outcomes that Google+ could not, and they did it with a fraction of the output.
Hierarchical, top-down companies assume that the leaders are able to forecast the future and pick the right ideas. The people in the middle and the bottom are there to figure out the details. This model doesn’t work anymore (and I doubt it ever did). In modern organizations a lot of the knowledge and expertise live at the edges. Top-down ideas often miss the mark because they lack the contribution and buy-in of the people doing the work. In the aftermath of every big failure we learn that people knew the idea was weak, but where not invited to speak up.
There’s even a bigger problem. Smart and creative people tire of constantly chasing someone else’s big ideas. There are only so many “must-have” projects one can get excited about (especially as eventually they turn out not to be a must-have at all). People become distrustful of the leadership and lose passion or leave. The lack of trust goes both ways, as the leaders see the failure in execution rather than in the plans. From there it’s a short and very slippery slope towards a company ruled by command-and-control processes.
Companies such as Toyota and Netflix take a different approach. The key role of the leader is to define the goals (intent, success), and to provide as much context as possible—what people need to know to succeed. Then he/she helps the reports discover the right solutions. It’s a different form of collaboration. No longer a waterfall of planning and execution with distinct “planner” and “implementer” roles. Instead, an iterative and collaborative process of goal setting, idea generation and evaluation, experimentation, and execution. (plug: my GIST framework attempts to do just this.)
Big Opportunities, not Big Ideas
Top-down, big-bet projects happen partly because we think that’s how strategy works. To achieve big things we must chase big, top-down initiatives with high urgency. I’m sorry to say, that’s not strategy, that’s just a roadmap on steroids (or more accurately a crapshoot.) What needs to come from the top are big, ambitious (yet achievable) goals, and major opportunities or threats. Detecting opportunities and threats and setting goals to validate and address them, is really where leadership plays a critical role. Sadly in most organizations that’s also where it comes short, moving people to feel there’s no vision or real strategy.
Let’s look at an example to see the difference between strategic opportunities and strategic ideas. Amazon, from early on, saw a big opportunity in bringing 3rd-party sellers onto its stores. Doing so will help turn the famous Amazon’s flywheel (the core of its business strategy) faster and faster.
Amazon pursued this opportunity with a series of ideas, which all failed, until eventually in the year 2000 it launched Amazon Marketplace. Today 3rd-party items account for 54% of sales. The lesson here is that a strategy is never about chasing particular big ideas, but about the opportunities and threats the company chooses to address.
Thousands of product people have already signed up to my newsletter and get my articles by email, plus free access to eBooks, templates and other resources.
Think Big but Start Small
There’s nothing inherently bad about big projects—sometimes we need them. The problem is with starting big. The classic approach is to jump all-in: allocating resources, creating plans, committing to launch dates, then moving into full-on execution. We invest too much upfront and we lock ourselves to a plan with no agility. Given new information, the sunk cost fallacy makes it very hard to improve on the idea or to let go of it altogether.
It doesn’t have to be this way. Many of the biggest, most important projects didn’t start out big. The iPhone was seeded by at least five smaller projects that eventually merged. Gmail was started as a side project of an engineer. It’s better to start the project with fewer people—a kernel team— that, like a startup, has one clear mission—to find a product/market fit within the opportunity. For bigger opportunities you can divide the work among multiple teams, as Netflix has done with its swimlane model.
When we have an idea that shows genuine traction, it’s time to scale the project. Often this happens organically. People and teams get genuinely excited about impact, and naturally coalesce around the best ideas. Eventually managers will step in to help pick ideas and decide on funding, but that’s much easier to do when there’s lots of evidence. As the project grows larger and more teams join, we strive to break the work in such a way that teams are “highly aligned, loosely coupled”, to use a Netflix principle. When the project progresses towards the finish line it will take on more of the characteristics of a classic delivery-focused project, but that’s ok. At this point we should have validated the opportunity and the core ideas enough to know that we’re making a good investment. Just as important, there’ll be enough shared goals and context to keep people pulling in the same direction without heavy-handed project management.
(In case you’re wondering—yes, this approach may be slower in terms of bits pushed to production, but in terms of value created it can be 10x faster).
Conquering Big Projects
Top-down, big-bet projects do a lot of harm, and can deplete companies of resources, innovation, trust, and good people. They exist because of ingrained beliefs that are no longer valid. I believe these should be our new working guidelines:
- Aim for big outcomes rather than big output
- Begin with opportunities and threats rather than big ideas
- Start small and growing only as we gain evidence
- Allow the project to grow organically
- Let the people doing the work help at all stages
Join one of my public workshops to learn how to use the concepts described in this article.