Personally, I find mapping a useful tool for determining predictable changes (and manipulating the environment accordingly) and anticipating possible but ultimately uncertain changes by narrowing the range of the likely. Maps are never perfect but they provide a view.
I thought I'd explain this with two past examples - Fotango and Canonical - where I've used mapping. I won't go through the details of mapping (I've covered this many times before) but instead how I used it.
My Fotango Story
Almost a decade ago when I was CEO of Fotango (a profitable and growing company), we had a problem on the horizon. We needed to find new external sources of revenue to rebalance our portfolio. James Duncan and I mapped out the environment on a whiteboard and used this to determine our play. For reference, a copy of that map (which I've simplified and tided up) is provided in figure 1.
Figure 1 - Map of Fotango
By examining the value chains associated with Fotango (the more faded circles and lines in the diagrams), we had determined that:-
1) Platform were going to become ubiquitous and provided through more utility like services.
2) That customers and past vendors would have inertia to the change (black bars) which we could reduce by creating a competitive market of providers and use of an open source play
3) That the marketplace would allow for formation of exchanges, assurance mechanisms (reporting on providers as per a Moody's rating agency) and a u-switch like model.
4) That an ecosystem (the large shaded circle) could be built around the platform play and exploited through an ILC like model to identify new sources of future value.
5) That raw infrastructure (compute) would move to a utility. Though we had already been running our own pre-cursor to a private cloud for some time (known as Borg), we could exploit the movement of a new entrant into this space to reduce our capital expenditure cost. I suspected it was going to be Google who made the first move, the following year we discovered it was Amazon.
We built our model around this and some of the other anticipated effects (change of practices etc) and Zimki, almost certainly the first modern PaaS was launched publicly (2006) as Amazon EC2 revealed its beta. We announced our plans to open source, create competitive markets and focus on building higher order systems. Amazon's move mean't we started to immediately reposition to run on Amazon.
Everything was rosy, it was rapidly growing and the timing was spot on. Alas the parent company had been persuaded that the future wasn't the stuff we were working on - utility computing, 3D printing, impact of mobile phones on cameras - but instead outsourcing IT, big ERP implementations and televisions.
In another universe, if a different route had been taken then Canon might today be a rival to Amazon in the cloud and have sown up the 3D printing industry. But the same "if only" can be said of Xerox, Kodak and many others. We will just never know whether those decisions cost significant future losses of market cap since Fotango and Zimki were killed off and we can't replay the past.
I lost. C'est la vie.
Fortunately a useful lesson in political capital was learned and the mapping technique survived even if Zimki didn't.
My Canonical Story
After leaving Fotango and working on various pet projects, I met with Mark Shuttleworth. Actually, a very smart troublemaking friend of mine introduced us under false pretences. Mark wanted a designer, I said "I know nothing about Design" and so we decided to just have a chat. What I explained to Mark was the principles of evolution and how this applied to the computing industry. Mark asked me to come work with Canonical on strategy and so I joined in 2008.
The first five people I met in Canonical when I told them I was there to work on "Cloud" were pretty dismissive. "It's a fad" etc was actually fairly normal in the industry. Fortunately, I had a great boss in Steve George and quickly met some smart folks in Rick Clark, Soren Hansen, Nic Barcet, Gustavo Niemeyer and John Pugh. They were all open minded to the concept of evolution and change, so we plotted a plan.
The problem for Canonical (and Ubuntu) was that though it was strong on the desktop for a linux based OS, we were fighting RedHat on the server market and they owned it. So, we mapped out the environment (on a huge whiteboard though interspersed with some content intense presentations of mine), had various arguments over how to play the game and roughly settled on an approach. Figure 2 is a simplified summary of that process, a map that I've cleaned up (the original was actually far more complex and messy) and added some modern terms so it makes more sense for today (devops etc).
Figure 2 - Canonical Map
The principle play was:-
1) We accepted that RedHat owned the server OS (for the time being) but that didn't matter, we were going to own the future and let the industry catch up to us.
2) We would focus on being the dominant guest OS on any compute utility by building a cut down version of Ubuntu which anyone could use. Nic just made this happen with his 'just enough' concepts and support of others in the wider community who had led the charge.
3) Companies would have inertia to the change so we would acquire an open source private cloud equivalent which matched the dominant player in a transitional hybrid (public + private) play. Hence our early involvement with Eucalyptus which John Pugh and Mark managed to hook in 2008 and Rick and Soren worked furiously on.
4) We knew that new practices would appear and so we would look at bringing those toolsets into Ubuntu (e.g. Chef) and modify Landscape (our management tool) appropriately. In fact, Gustavo went much further and took this into the whole area of JuJu which is something I had serious doubts at over the time due to education barriers. In retrospect, I think Gustavo was right and I was clearly wrong here.
5) We knew that we needed to own any future platform plays and push application development onto Ubuntu. In fact the latter was already happening, the community was strong and the desktop and community team with people like Jono Bacon were doing an incredible job. However, we needed to get everyone in the cloud building on Ubuntu.
Steve would always (and rightly so) twist my arm over revenue stream. He would certainly give me numerous challenges on my approach to server. As I pointed out there were multiple different revenue streams possible in the future (from support to brokerage to assurance to private cloud installations etc). However, my focus was to own the future, use it as a door opener (opportunities multiply as they are seized) and then build revenue streams. I always take a view it's better to own the future and then monetize it rather than own a route to monetization but not the future. Steve, was always supportive and both him and Mark are exceptional in terms of understanding opportunity and game play. Any inertia that might have been, quickly evaporated when Mark made it clear that we were focused on cloud.
We didn't get every step right (I certainly had some bust ups over my insistence on Chef for example) and I certainly made a bucketful of errors. But today, Ubuntu is without question the dominant OS in cloud. The team at Canonical have done a stirling job in creating that future.
Let us be clear, Canonical (a relatively small company) literally stole the future from RedHat and all the other giants in the field and this was done with very modest investment and barely a shot fired by the competitors. The ability for Canonical to help itself to the prize whilst giants were sleeping around it was stunning but then I've often seen this scenario.
Let us be clear, Canonical (a relatively small company) literally stole the future from RedHat and all the other giants in the field and this was done with very modest investment and barely a shot fired by the competitors. The ability for Canonical to help itself to the prize whilst giants were sleeping around it was stunning but then I've often seen this scenario.
Now, some people seem to think I had a big part in this and so I want to correct that view as my role was minor. I was motivated to do this because of some very kind comments from Jorge Castro at OSCON which though appreciated overstated my influence. My role was providing a way of viewing the landscape, sensing where to attack, exploiting the battlefield and evangelism. Today, I teach all sorts of companies and Government organisations the same sort of techniques for mapping and certainly my maps have become a lot better over time.
However, this is just viewing the board and though it helps in playing the game what matters is how well you play the game and execute. Mark and the group above and many more (which I haven't mentioned) within Canonical made it happen. They are the truly exceptional ones and you should be in no doubt that Canonical is an outstanding place to work with some incredible talent.
As for RedHat. I kindly warned them to buy Novell and force an acquisition by IBM. They didn't. They must by now realise the dangerous threat that Canonical has become and that the cost of reclaiming the future will be huge. But that's not the fault of Red Hat's engineering talent nor their culture nor their community nor inertia nor their ability to execute, it was their executive management team that was outplayed. They might have great engineering skills but in terms of executive management they had poor chess players.
C'est la vie.
Update 25th August 2013
I've been asked two questions. First does culture matter more than strategic play? The answer to this is very complex and I'll have to do a number of posts to explain why. The short answer is that in certain parts of the economic cycle then culture matters vastly more whilst in others strategic play appears to matter more. Where IT is at the moment, then for most companies, strategic play trumps.
The second question was what would I do if I was RedHat? I'll leave that to the reader to make their own suggestions but I would start by thinking about and mapping the landscape. I'm not a great fan of ad-hoc plays without good situational awareness nor am I a fan of relying on "everyone else is doing this" or differentiation plays when not appropriate. As a clue, my first step would be to embrace Cloud Foundry as the platform play.
Update 25th August 2013
I've been asked two questions. First does culture matter more than strategic play? The answer to this is very complex and I'll have to do a number of posts to explain why. The short answer is that in certain parts of the economic cycle then culture matters vastly more whilst in others strategic play appears to matter more. Where IT is at the moment, then for most companies, strategic play trumps.
The second question was what would I do if I was RedHat? I'll leave that to the reader to make their own suggestions but I would start by thinking about and mapping the landscape. I'm not a great fan of ad-hoc plays without good situational awareness nor am I a fan of relying on "everyone else is doing this" or differentiation plays when not appropriate. As a clue, my first step would be to embrace Cloud Foundry as the platform play.
