As we noted in our blog post on winning skills, successful micro-battles depend on the ability to translate a company’s most important strategic initiatives into what we call “first failure points.” By that we mean you need to identify the biggest potential problem or hurdle that could derail the initiative and deal with that first by making it the focus of the micro-battle. Readers have been pretty clear in their feedback: This feels like a big idea, but I want to know more. So here is a detailed look at how scale insurgents master the critical skill of identifying first failure points so they can use micro-battles to solve them.
We are all lazy strategists
We said it in the winning skills blog post, but it bears repeating: Most senior leaders sign off on a strategy of “chapter headings” and force their people to write the actual chapters with very little guidance. Many companies seem content to call generalizations like “Win in China” or “Recommit to Customer Excellence in Our Core Markets” statements of strategy. But those are really just chapter headings that say nothing about how you will win in China or how you will recommit to customers. Unsurprisingly, such vague attempts at spelling out the mission lead to vague execution and anemic results.
Robust strategic thinking translates strategy into micro-battle missions
Scale insurgents use micro-battles to turn chapter headings into effective strategy by reducing a vague top-level idea into a specific, executable mission. The act of crafting a micro-battle mission forces senior leaders to create a hypothesis for each initiative that incorporates the following:
- How do I translate the strategic initiative into something I can prototype with real customers?
- How do I take lessons from a winning prototype and create a transferable and, ultimately, a repeatable model that can be scaled across the organization?
- What is the right rollout model, and what behavioral change will we need to put in place to achieve full potential?
The mission starts with identifying first failure points
The reason we focus on first failure points is that we are trying to reverse the usual order of strategic execution. Teams in charge of carrying out an initiative typically create very long lists of things that need to get done. Then they start with the easy stuff. This leads to heavy yield loss when they ultimately get to the hard stuff, and the initiative stalls. We try to get teams to start with the first failure point—or the hardest problem they will likely encounter—so they can get moving fast on prototyping a solution and discover early whether the initiative is, in fact, viable as envisioned. The best reality check is to put something in front of customers right away so you can fail, adapt, retest, fail, adapt, retest and so on until you finally achieve success. Another way to say this is that you need to focus first on the thing that is most likely to make you fail and adapt your way from failure to success.
Identifying the first failure point is one of the hardest acts of leadership
Let’s be clear—there is nothing easy about identifying the first failure point. An accurate assessment of what could go wrong demands huge amounts of industry experience, street smarts, practical thinking and intuition. But think about it this way: Most companies allow strategic execution to go on for years before anyone focuses on these critical points of failure. No wonder there’s so much yield loss. No wonder most strategic initiatives take 18 months to fail. We spend all our time on the easy stuff, while the failure point remains untested and waits unseen like a land mine. By the time we finally address it, the company is 18 months in and very often loses the will to persevere. So let’s step up on this, folks. If we want to call ourselves leaders, we have to take on the burden of helping our teams identify the first failure point at the beginning of a strategic implementation, not at the end.
You’ll get better at it over time
The good news is that finding and confronting failure is a skill. If you become better than your competition at starting all strategies with rapid prototyping of solutions that address the first failure point, you will win. Here are two approaches that work:
- Start with the ideal customer and his or her “preference drivers.” Most failure points fall into two categories: We’re not as good as we think we are with our most important customers and/or we don’t actually have the capabilities to do this new thing we want to do. In terms of customers, you want to start by defining your “design target,” or the ideal customer for this thing you are developing. Yes, you’ll eventually want to expand to multiple customer segments. But right now, you need to focus on just one—the perfect design target for this new proposition. Then ask yourself, how does this person make decisions around this proposition and how do we stack up against the competition in delivering on these preference drivers? Very often, the first failure point is that this initiative isn’t going anywhere unless you can outperform the competition in these areas. So you’d better start prototyping some new propositions that can outperform.
- Then question your own relative capabilities. Designing a solution that appeals to customers is one thing. But delivering it on a sustained basis is another. We tend to love ourselves and massively exaggerate our capabilities compared with our competitors. But a closer look often reveals that your ability to deliver a sustained solution may be severely constrained without substantially upgrading the capabilities that are critical to this new strategic mission. How are you going to boost those skills cost-efficiently? Can you retrain rapidly? Should you bring in new partners? Can you buy or rent these capabilities? You are going to need to start prototyping some homegrown and/or externally sourced solutions to upgrade these critical capabilities pretty early in your strategy.
There’s always a customer and always a prototype
You’re probably ahead of me here and thinking, “Yeah, this all works for customer-oriented initiatives, but what about all the other initiatives we have, starting with cost control?” Well, in our experience, there’s always a customer and it’s always valuable to test a prototype. Consider a couple of examples:
- In one client workshop recently, we discussed a micro-battle to radically simplify corporate reporting. One of the market managers expressed the problem this way: “I am evaluated on 64 KPIs, and yet use only one of these to manage my sales business. I collect information on the rest for my review, but they have nothing to do with increasing sales. I have four other KPIs that I do use to manage sales, and yet corporate asks for none of these. So we were debating how best to launch a micro-battle to simplify reporting. The first failure point is how do we simplify reporting without falling short of the minimum reporting requirements our CFO needs to fulfill his fiduciary responsibility to shareholders?” The first prototype became “we need to create a new report for our GMs that radically reduces KPIs, but still ensures the CFO has what he needs.” So in early prototyping, the CFO will be the customer.
- In another meeting, I was with a consumer goods company that wanted to launch a micro-battle involving one of its most important retail partners. The company’s product team was proposing a very aggressive new category strategy, but the account team that managed that partner was initially opposed. So the product managers defined the customer as this key account team and focused the prototype on addressing their preference drivers.
The first failure point leads to the second failure point
Once you’ve created a successful prototype to solve the first failure point, a well-designed micro-battle will then move to the second failure point. Generally, this means you move from customer to capability or from capability to customer. Two examples:
- In working with a transport company, we ran a micro-battle on eliminating costs, and we defined the customer as the truck driver. We couldn’t move forward on the cost-reduction initiative unless the drivers were fully on board. The solution involved creating software that drivers were expected to execute on a tablet. We developed a solution that the drivers loved, eliminating the first failure point. This immediately triggered the second failure point: Were we capable of training drivers—especially the part-time, third-party drivers, who had different incentive structures than the company’s full-time drivers?
- At a medical device company, we worked on a micro-battle involving a move from product sales to the sale of “solutions.” So the first failure point was all about the salesforce and its capabilities. Could the existing salesforce adopt a “solution development process” that would help individual salespeople identify potential customer needs? Once we created a successful prototype targeting sales capabilities, we moved to the second failure point: Will customers buy into our solution prototypes?
The best micro-battle leaders fail a lot, but keep the cost of failure low
This is really an Agile point, but a point worth making. The best micro-battle leaders are very good at coming up with clear, contained failure points that allow the team to develop targeted prototypes through quick rounds of failure and adaptation. This is a real art. It is very easy to overinvest in the prototype by creating a lot of functionality or complexity that really has nothing to do with the failure point. This creates costs and slows down prototype testing. It also creates a lot of noise in interpreting customer feedback. Are customers reacting positively or negatively because the prototype addresses the failure point, or are they merely reacting to all the bells and whistles you’ve added?
The hurdle of transferability is high and leads to more failure
Remember, a key definition of a successful prototype is that it is transferable to other markets (or next customers, or channels or employees). So not only will you probably fail in testing with the initial design target before you find success, but you will likely have to fail again in the next cycle, as you adapt the prototype to the next market. The more narrowly and precisely you define the design target in the first instance, the more you will fail in testing for transferability. That’s just part of the process.
Facts matter, and so do focus group insights
Every micro-battle mission should define the metric used to measure both the success of the initial prototype and the subsequent repeatable model. It is also important that the micro-battle team understands how to gather data to demonstrate it has hit the metric. Equally critical, however, is that the team learns from each prototype test, which involves rigorous use of both qualitative and quantitative customer feedback. In this context, focus groups matter a lot, and the best micro-battle leaders create the right conversation with customers to get real insight into what is going on. Customer dialogue matters as much as a quantitative survey.
The customer feedback we’re getting on failure points is that this is really helping clients focus their strategic initiatives. The need to identify the right first failure point is leading to very different conversations at their companies. These conversations are improving the quality of the strategic discussion, moving it from an easy, but meaningless, conversation about chapter headings to a very hard, but far more productive, debate about first failure points.