Happy Mapping Monday! Today’s #mappingmondays video covers an interesting gameplay known as Tower and Moat which can be devastating to a market when executed well. As always, a full transcript is included below the video along with some links to the ILC play. And If you’re interested in finding out how to apply this to your organization, don’t hesitate to reach out via Twitter or email hello at coryfoy dot com!
Links:
- Simon Wardley’s excellent post on the Tower and Moat Gameplay
- Mapping Monday video on Innovate-Leverage-Commoditize
- Simon Wardley’s post on Ecosystems and ILC
Transcript:
Happy Monday, and welcome to another edition of Mapping Mondays! I’m Cory Foy, and in today’s video I want to cover a gameplay known as Tower and Moat – a play which, when executed well, is basically quicksand to a business trapped by a competitor making the play.
First, a quick recap. In our maps we see components go through evolution from Genesis to eventual utility. However, when a component becomes utilized, it enables higher order components to be based off of it. So basically utilization of something – like electricity – enables things to be built which incorporate it – like the internet – which themselves can enable higher order ecosystems like Twitter or Websites.
In this case, let’s pretend we’ve built a business around selling computer servers to customers. We have a large customer base, and we’ve done really well for ourselves. We’re effectively selling productized computing power to our customers. Then, one day, Amazon comes along and offers computing power as a utility. Customers don’t have to think about requisitioning servers, backups, upgrades or anything else. They can basically just turn on more compute power.
Initially this doesn’t have a huge impact. Customers tend to already have contracts, and have to figure out how to incorporate this new model into their thinking. So initially we have the luxury of a runway of market inertia to buoy our revenues.
But now the question comes up of – how do we survive, or even thrive? “Beat Amazon!†becomes our rallying cry. But one of the biggest challenges of utilitized components is the amount of capital and inertia it takes to overcome it. So we start figuring out how we’ll also offer our own set of utility services, and how we’ve got more experience, better customer service, and all the magic thinking of why a customer would want to use us over them if we just offer what they offer.
But Amazon doesn’t care about that. They’re going for market domination, not winning small segments. So in this case they begin building what is known as a Tower and Moat strategy. First, they recognize that utility components are characterized by being embedded in higher order components. So they open up an API and let people start building things on top of them.
See, they know that what will eventually happen is higher order components will emerge that they can than commoditize. This is known as Innovate, Leverage, Commoditize (https://blog.coryfoy.com/2019/08/mapping-mondays-innovate-leverage-commoditize/) because other people do the innovating.
To fund this play, they create a tower of revenue around the utility services. So people pay to use the API, and to harness the compute power. Then, as higher order components emerge, they commoditize them and offer them for free, because they have enough revenues to do that.
Back to us – let’s say that we anticipate a higher order change happening, and so we start looking at the incremental steps that come after the utilitization of server compute. The problem is – people begin building things on top of Amazon’s API, so they can see in real time where people are innovating, while we’re doing it through user surveys or customer exit interviews. And even if we successfully open up a new market, it’s likely Amazon will be able to rapidly commoditize it using a Pricing Policy play of…free.
Unfortunately, by the time we’ve figured this out, more of the market has moved into integrating Amazon deeply into their innovations, making it hard for us to do a counterplay of our own ILC, and potentially sending us into a death spiral of losing market share.
But does that mean that it is all graveyards and tombstones when a competitor utilitizes a product we rely on as a core of our business? Not necessarily – but it does require rapid movement and anticipation that feels unnatural.
As an example, I once took a class on commanding large scale emergency incident operations as my background also includes being the Assistant Fire Chief of a department in Florida. One of our final scenarios was a wood-frame apartment complex under construction. An initial small fire is called in and we found the only way to stop it from destroying the entire complex was to arrive on scene and immediately call for six alarms. For context, each alarm for us is 3 fire engines, a ladder truck, an ambulance and a battalion chief. So we’re effectively calling for 24 fire apparatus and 6 ambulances for what many departments would normally consider a one or two engine response.
That’s because the potential was so high that we had to make a bold, rapid move early in. Since that class I’ve witnessed two major fires with that exact scenario, both of which turned into total losses for the complex under construction – one in Ybor City, FL which burned 4 city blocks, and one in downtown Raleigh, NC just about 2 years ago.
So what’s our equivalent of calling six alarms? First, the recognition that our normal business indicators aren’t going to help us here. Everything is going to seem manageable, but if we’re looking at our landscape, we can see the dangers of the play – especially if our competitor has the revenue streams to be able to execute the moats.
Now we need to be able to anticipate the evolution of the market. We’re now relying on bets which are hopefully based on deep understanding of user needs. We’re looking for ways to leapfrog the evolution and get people building on top of us. As an example, we could commoditize the API by incorporating it in our own APIs to give people access to second or third level order capabilities. If we can pull that play off, then we can begin running our own ILC play – and hopefully our own Tower and Moat strategy while also diversifying the sources of that utilized API so we don’t find ourselves cut off from it suddenly.
All of this requires incredibly astute understanding of the market, user needs and evolution direction, as well as a willingness to make bold bets with high agility and maintaining a great experience of our core product. Which means we want to do this while we have the capital to invest – because once revenue drops start to happen, investing in riskier moves is going to be harder and harder to justify.
So if you find yourself with a business that evolves around core components which are ripe for evolution to utility, start thinking about the plays you have around it and how you can protect yourself from the inevitable sweep that will come – before you find yourself looking up videos on saving yourself from quicksand.
If you have any questions or are interested in mapping your own organization’s challenges, feel free to reach out on Twitter at @Cory_foy or via email at hello at coryfoy dot com. And be sure to check back next Monday for a new Mapping Monday! Have a great week!