Saturday, November 21, 2015

Uber, the not so disrupting disruptor?

A recent HBR article by Christensen on "What Is Disruptive Innovation?" states that Uber is not "genuinely disruptive" and it doesn't fit into his hypothesis of disruptive innovation. Well, he is certainly entitled to modify it anyway he sees fit but the article does raise concerns over post event classification i.e. the original claim that the iPhone wouldn't be disruptive followed by the article's claim that it wasn't in the smartphone market and it was in the PC market. I happen to agree with the basic premises of disruptive innovation though I do note that there appears to be at least two different forms of disruption - one anticipatable and the other not. That said, let us get to the point of this post which is Uber.

First, I'd argue that a case for Uber being disruptive can be made if you look at the right thing (a bit like the above HBR article which compares the iPhone not with the smartphone market but instead the PC market). The area to examine is whether Uber is replacing the human controller. The person who you called, who co-ordinated taxis and who told you the car would be there in five minutes (it never was) has been automated out of existence. I know taxi firms who dismissed the idea of an application doing this citing that people wouldn't trust it, the benefits of talking to a person, of accounts and a more personal service. Uber however took the controller and turned them into an automated bot creating the barest minimal of interaction.

In the process this automation also expanded its reach, there are limitations on how much any human controller can effectively control. So, whilst I agree that Uber is not disrupting taxis per se, it certainly seems to be disrupting the idea of a human taxi controller by first turning this interaction into volume operations of good enough. However, what's interesting in this topic is when people talk about the potential of Uber to disrupt the automotive industry.

To understand why, we first have to look at a map of the automotive industry. I won't start with today's map but one which has been rolled forward to 2025 (see figure 1).

Figure 1 - Automotive Map 2025

The user has two basic needs - status and getting from A to B. The latter has multiple sub needs from comfort (which includes safety and security) to affordability to route management. These are all encapsulated in the concept of the car and there is a pipeline here from the more product / differential focused automotive to the more commodity like vehicles. You can follow the chain down through systems to provide comfort (including entertainment and infotainment) to OEM to component manufacturers. To keep the map reasonable, I'm cutting down whole sections to nodes (e.g. power supply or material).

In this picture of 2025, intelligent agents have become increasingly common and hence most cars have some self driving capabilities. Cars are becoming increasingly immersive (the inside of the car is just one big set of screens, probably printed). What starts to differentiate cars is not the car itself but the design associated with the immersive experience and the connection between status and route management. By this point, cars provided on some sort of utility basis will be increasingly common. This trend of intelligent agents, immersion and design subscription will continue to diffuse. So what does this all mean?

By 2030, in all probability most of us won't own cars. When I leave a meeting then my car will certainly be there to pick me up but that same car will be the one that you were using 30 minutes beforehand. Cars, for most of us, will have become very commodity. What will distinguish our journeys will be the level of digital subscription service that we have. If you are a "platinum" service member then not only will the outside of the vehicle alter (colour, some other affects to show your status) but the immersive experience will be more tailored for you and your journey will be faster. Why? Well the cars driving us "silver" subscription members will get out of the way for your car. We won't even notice because we're inside in our immersive experience which for us "silver" members probably involves a lot more advertisements. 

The cars themselves will monitor their own performance, drive to the repair shop when needed, communicate between each other and re-route constantly based upon not only the journey time but the subscription services of other car users. Of course, human driving will be increasingly outlawed except for super high end status vehicles where the illusion of human driving (safely managed by an intelligent agent) is given. There's all the usual knock on effects to car parking (we don't need as much) to repair shops to traffic signals etc.

Taxis in this world will become a thing of the past except, in a sense, most of the cars are acting like taxis with automated controllers and automated drivers. We don't own these cars, we just subscribe to our service and pay for what we use. By 2045, well the scenarios get even more outlandish. But who will own this new world of vehicles? Will it be Uber or Google or Apple or Ford or even GM?

If you look at the above map, identify the points of war (i.e. the shift from product to more commodity), the impact of technologies undergoing the same change (e.g. immersive, robotics) and then add in the structural advantages (e.g. education, financial and manufacturing scale) and strategic gameplay of companies and nations (e.g. last man standing, creation of centres of gravity, directed investment etc) then a very different picture emerges. Figure 2 provides major impacts from points of 'war' (red boxes) and overlays examples of known gameplay of significant scale in China. Even by 2025 then China should be edging ahead in the automotive industry by building, designing and operating the most advanced forms of these vehicles. Alas, even today Western companies keep on underestimating the speed, agility and entrepreneurial spirit of China.

Figure 2 - China Gameplay in Automotive

The automotive industry seems destined for an immersive, self driving and digital future provided through highly commoditised vehicles. However, I expect the beneficiaries of this change to be Chinese OEMs combined with service companies such as Baidu and Didi Kuaidi. As for Uber then I agree it is disrupting the human controller. I also agree it will have a part to play in this new world for a time. But, I don't expect Uber to be the company disrupting the automotive industry even though it might dream it will.

Friday, November 06, 2015

When to use a Business Model Canvas or a SWOT?

I've been asked for a bit more detail on my post on "Business Model Canvas, the end of a long road" and so I thought I'd use an example.

I was recently looking into the whole area of identity and access management (something I'm mulling over for future LEF tours) and so quickly put together a basic map of the industry. Now, I'm no expert on the subject and so I turned to others to give me input (I find my Wardley maps are useful for collaboration with others). A basic map is shown in figure 1.

Figure 1

The first thing I'd do with this was to look at weak signals (i.e. points where the industry is shifting from product to commodity [+utility]), add in competition forces (i.e. those areas where competition and hence evolution appears strongest) and add in known ecosystem plays such as ILC. This I've shown in figure 2.

Figure 2

At this point, I'm looking for potential. There are two "wheres" that I might attack for example in the above map. One of which is obvious and the other is a combination of components. The two are :-
  • profiling and the development of an ecosystem around this.
  • personal reputation and the development of a relatively novel system that combines components of both trust and profile.
This I've show in figure 3. Of course, there's numerous other points I might wish to attack and a vast array of games (repeatable forms of gameplay applicable to different contexts) that I can use.

Figure 3

I might have spent a few hours mapping out the landscape and collaborating with others but let us say, I push the boat out and go a bit overboard by spending another day and comparing with other players in the space, adding in inertia and constraints where necessary. Lets add another half a day for gameplay. I'll have a pretty extensive map of the landscape, multiple points (WHERE) that I can attack and a good idea of how to play this and the different games available.

By now I'll be looking for my WHY as in WHY here over there. Once I've played with a few scenarios (a few hours) and settled on one or two main points of attack then this is the point that I'd start using the maps to flesh out one or more business model canvas (and yes, I might even use a SWOT). For me, these tools are more an exercise of confirmation and challenge to the idea of my chosen point of attack. And before you ask, yes I could spend a whole three days on this entire analysis prior to embarking on a major effort but in practice I rarely need to.

I find it incredibly useful to understand the landscape, the points where you can attack and the games you can play before embarking on a chosen route. I never start with business model canvas or SWOTs but I often use them further down the line when I've got a good idea of WHERE I'm going to attack and WHY here over there.

Efficiency vs Effectiveness and why flow isn't enough.

Without naming names, I'm going to talk about a rather ridiculous situation that helps highlight the difference between efficiency vs effectiveness and why flow isn't enough. It concerns computing.

In this company, they have their own data centre which is full of custom built racks. These racks exist because that's the way they have done it but rather than being the standard 19" rack, these are a non standard sized and turn out to be slightly smaller. This unfortunately means that normal servers can't be racked but nevertheless the company has a solution. They buy relatively standard servers, they remove the shell and drill new holes into the body in order to fit it into the rack. Now users in the company can request compute resource but what's of interest here is the issue of when capacity is nearly reached. An order is made, new servers arrive in goods in, the shells are removed and new holes are drilled to modify the servers and then they are mounted. I've drawn the process in figure 1.

Figure 1

Now looking at this process, we find the mechanism of removing the shell and drilling holes (i.e. Modify) to be quite time consuming. It is also occasionally imprecise causing issues mounting the servers and waste. It is also bottlenecked by there being a limited number of people who are any good at doing this. Bizarrely metalwork is actually not a core competency of system admins. So we can propose any numbers of mechanisms to improve the efficiency of this process even to the point of automation with robotics if the scale demands it. 

However, I want to take a mapping view and show the same flow. When using maps, on the evolution axis then I tend to use activities (i.e. genesis to commodity) but do remember you can map practices (novel, emerging, good, best) and data (un-modelled, divergent, convergent, modelled) on the same axis. All of these components share the same characteristic changes as they evolve. 

In our process then order components and goods-in are fairly widely understood and established. The modify server (despite there being a guide written on how to do this) is fairly unusual and a newly employed system admin will probably have little idea on how to do this. Of course, even racking a modified server is reasonably straightforward. Hence I've provided a rough map of the above in figure 2. However I've also marked on a view as to where compute, racks and the practice of mounting a server are in the market.

Figure 2

What should be obvious is that we're trying to make Flow 1 efficient when it is in fact an ineffective process. The only reason why we're doing this is because of our use of custom built racks in a world where racks are standardised. If we use standard racks then the modification process goes away and mounting becomes vastly more standard. However, if we look up the value chain then compute has become far more of a utility and if we take advantage of this then flow 1 is simply replaced by an API call (flow 2). 

In the case of the above, the company shouldn't even own compute but should be using a public cloud service. It certainly shouldn't be investing in robotics to automate a process of customising standard servers to fit into custom built racks in order to make an ineffective system more efficient.

A map gives you two main axis. The first is position based upon a chain of needs relative to an anchor of visible user need. The second is movement (i.e. how things change, evolution). Within maps you have flows but mapping makes it much more obvious when you're trying to optimise and make efficient a highly ineffective flow. Of course, many of you are familiar with compute and would claim it would be obvious not to do this. But if I made a map of World Perception Systems or a Trading Ledger then you might not be so familiar. In which case, I suspect you might fall into the trap of optimising and making more efficient the wrong flow. I suspect this because I see it all the time. Endless efforts in corporations to make the wrong thing more efficient.

You can't also just say, well that company should be asking - "how does this process help us?"  - as the executive don't understand the inner workings of systems and the people involved in the process believe it's the right way. They're proud of their environment and have all the usual symbols of inertia. It's not that they're daft but instead they believe that what they're doing is right - it's what they've always done and they've invested considerable personal time and effort making it better. Of course, making it more efficient would help the company hence investing in robotic automation sounds "sensible". I can easily build a case for this as daft as it sounds (and it is daft).

Showing them a map, even with just pointing out the change if you start using more commodity components such as standard racks (see figure 3) rather than focusing on making an existing process efficient exposes the assumptions and workings of a company.

Figure 3.

Once you've explained that, it becomes far easier for people to make the leap towards not having racks at all (i.e. flow 2). I mention this because people often tell me about the importance of removing bottlenecks and ensuring efficient flow. I happen to think such techniques for value stream analysis are reasonably important but you have to be really careful that you're not making the wrong thing efficient. It's not enough to just look at flow (as in figure 1), you need to consider how evolved the components are (e.g. fig 2 and 3).

Which is why I always recommend you start with a map.

Monday, October 26, 2015

Strategy starts with where not why.

It doesn't matter whether you're competing against a foe in a battlefield, or in a game of chess or in business ... strategy always starts with where.

"Where can I move?" is the first question you must ask. To do this then situational awareness (i.e. understanding your environment) is critical. If you cannot visualise (even through mental models) the landscape then you cannot determine "where"Mapping is fundamental to strategy and to organisational learning (e.g. economic lessons and repeatable gameplay in business or battle plans in military history) because situational awareness is. The question of Why is a relative statement as in "why here over there?"

Sun Tzu understood the importance of the landscape and talked extensively about it. Alas, strategy has taken a bit of a downturn in the business world since the art of war was written a few thousand years ago.

"But surely strategy starts with why?" ... no, blind luck and meme copying starts with why. If you cannot see the environment, you'll either do something because others are (backward causality) or you're taking a complete gamble without understanding the landscape. This may pay off but starting with why is anything but strategy.  

"But surely our purpose is why?" ... no, purpose i.e. that which causes others to follow you and provides a moral imperative is an idea. It's either given (as in defence of the realm) or in the world of business it is transient and carved out of past strategic play (e.g. the pivoting of companies through their history). Nokia didn't start out as a telecoms company, it started out as a paper mill then a rubber company ... do you think its purpose hasn't changed because of the choices it made? Today's purpose was a historical heritage of past choices and its future purpose is unlikely to be the same as today. There is no "why" in this sense other than "we arrived here by accident, where next?" and "we wish to survive."

Take Odeo, an MP3 sharing service. Did it stick with its purpose? No, it created Twitter. It created a new purpose.

Take Ludicorp, an online game. Did it stick with its purpose? No, it created Flickr. It created a new purpose.

At some point both groups faced the decision of "why here over there" as in "Odeo or Twitter?" or "Ludicorp or Flickr?" and in both cases that choice was not only a question of different wheres but the answer changed their purpose, it altered their cultural heritage. 

Whilst the art of strategy is deciding "why here over there" and this in turn requires you to understand the possible wheres (i.e. your landscape), the consequence of making a decision can alter your purpose. 

"But they didn't use maps?" ... no, but then again it was more blind luck. They took a gamble in the unknown and it paid off. In military, sometimes things are won by sheer luck. That doesn't mean that maps are abandoned because of some notion that in this case luck worked. In military fields then patterns and repeatable gameplay can be learned - pincer movement etc. The same happens in business, for example the entire cloud field was anticipated long ago and many former giants have lost their position through not understanding the most basic concepts of their landscape. Others have exploited this.

Alas (or maybe this is a good thing depending upon your perspective), most businesses lack any form of situational awareness or mapping. Most don't even know it's possible relying on the pre-map navigational forms of story telling. Whilst there are no sure things in any form of competitive engagement, the understanding of the landscape and improving situational awareness can help swing the odds in your favour. To do this, you have to start by first asking where you can attack and then decide why here over there or there or there or maybe all?

Strategy starts with where not why.

Ten basic rules for dealing with strategy consultants

I'm no fan of strategy consultancy in general because most of what I see lacks any form of situational awareness and much of the field is uncomfortably close to snake oil. During my time as a CEO, I had to wade through endless drivel before I started to realise what the problem was. So, from my earlier post on "why big data won't improve your strategy", I thought I'd just spell out my ten basic rules of dealing with strategy consultants and how to spot and react to a dud.

How to react / deal with strategy consultants.

1) Focus on Why? As soon as someone says this, you should say "Why is a relative statement such as why here over there? How do we determine where?" - any bluster on this should make you point the way to the door. Remember - strategy always starts with "where?" and in their case the where should be the exit.

2) You're asking the wrong question! This is magic thinking, secret arts etc. Ask them "How do I know if I'm asking the right question?" - unless they can provide you with a repeatable method or if there is any bluster on this then you should politely ask them the right question of "Could you manage to close the door on your way out?"

3) Our method works! This should just make you run a mile. At best a method can teach you how to understand the environment, learn to play the game and learn to manipulate it to your advantage. Any mechanism for improving situational awareness will be imperfect. Any "formula" for success is again - magic thinking. Respond with your own formula of "you + exit = happiness".

4) Company X did this and they were successful. If this is a call to implement an activity then this is backward causality. They should show the competitive landscape, how Company X changed that landscape to their favour by the introduction of this act, whether this pattern is repeatable to your competitive landscape and what the underlying mechanisms of change are. If they can't do this then ask them to leave with the statement "Those other consultants successfully left, you should follow them".

5) 67% of companies have an XYZ strategy. This is just meme copying. Call security.

6) The top ten habits of successful ... run a mile AND call security. Unless they can provide a very precise mechanism to understanding the impact of those habits (i.e. understanding the environment and its manipulation by) then it's just backward causality on steroids.

7) The future is ... uncertain. Unless they can demonstrate repeatable and measurable patterns, the limitations of the patterns and the fundamental causes of the patterns in a manner which enables you to see the environment then this is not anticipation but guesswork or pre-existing trends that are so obvious they are of no differential value. Either case, you should explain "I bet you saw this coming but ... Next!"

8) You should align your strategy with your vision! A vision is a set of generalised aspirations. A strategy should be derived from an understanding of the context and the environment. I find throwing heavy books usually helps get them out of the room quickly.

9) You should align your business and IT strategy! Chances are you don't actually have a business strategy (otherwise you wouldn't be asking someone for help). It's also likely that you're suffering from low levels of situational awareness (i.e. an abundance of story telling, meme copying, magic sequences etc). If you did have high levels of situational awareness then you'd know that business and IT is an artificial division. If you've got a lion hidden under the table, now is the time to let it loose or at least tell them you're about to let one loose.

10) The key is to focus on execution! At times like this it is useful to have another door in the office that leads to a room with a table, a sheet of paper on it and a false floor covering a huge tank of sharks with frigging lasers. Say "Through that door is a room with a piece of paper on the table. If you answer the question quickly I'll give you a $100M strategy consultancy gig". As they charge into the room and turn the paper over, the false floor should disappear and the sharks should have their fun. Oh, as for the question on the paper - it should be "Well done on a speedy execution ... in your next life ... do you think situational awareness might help?" 

Final Note
If you need help in improving situational awareness in your organisation, then this CIO post on mapping is a good place to start. It's all creative commons and yes, I'm afraid, you have to learn yourself. Don't try and get some consultancy to do this for you as you're the one playing the game. There is no shortcut other than practice.

If you need help in implementing this into a large organisation then start with this 100 day plan. If you need a book then try the community one written on WardleyMaps, a group I'm not involved with but encourage.

Before you ask. 
No, I don't do consultancy.
Yes, I do teach others in my tribe (i.e. friends, my community in the open source world and members of LEF) and occasionally at other public conferences.
Yes, I could write your strategy but no, I won't. You need to learn to do this yourself.
Yes, I do write extensively on the subject here. No, there is no license fee. Yes, you are completely free to use as long as you honour the spirit of creative commons share alike.
Yes, here is a link to a set of useful posts to get you going.

Wednesday, October 21, 2015

That "cloud' term

IT consists of many components that are evolving. Some, like compute have evolved from being provided as a product (i.e. server) to being provided as a utility service (i.e. IaaS). Unfortunately rather than calling this a compute utility (which it is), we've been lumbered with the term "cloud".

This can create all sorts of confusion. For example, lets look at the figure below (using the form of a Wardley map).


1) This is compute as a utility i.e. compute utility. Unfortunately we call this "cloud".

2) This is a never before invented human to kitten translator. It's something totally novel and new. Is it a utility ... No! But it's built on compute utility. Is it cloud? Well, that's where the confusion starts because some marketing folk know the value of the getting the cloud word in there and hence it'll be called "Human to Kitten translator on cloud" or "Human to Kitten translator cloud" before you know it.

3) This is a custom built intelligent software agent e.g. Siri. Is it a utility? No, hell I can't even buy Siri like capabilities as a product and it certainly doesn't provide you volume operations delivery of a good enough component. It's far from a utility. It might be built on a compute utility. Is it cloud though? Again talk to sales, they'll probably say yes if that helps.

4) This is an ERP product running on a compute utility. Is it a utility itself? No, it's most likely to be a single instance rental model. But is it cloudy ... do you think they're not going to advertise it as "ERP on cloud" or "Cloud ERP" for short?

5) This is a payroll utility i.e. it's one of those services that charges per transaction and in this case is built on a compute utility. Is the the payroll service a utility? Yes. Is it cloudy? Bizarrely in the financial world, some people don't show off their cloudy credentials and have been keeping quiet on this topic.

6) This is an invoicing service charging per invoice produced and it happens to be run on its own servers. It is a utility ... yes. Is it cloudy? Well here arguments start as another salesperson chimes in to say "It's not as cloudy as our cloud ERP which runs on IaaS" etc.

I like things simple e.g. product based ERP running on a compute utility or utility payroll running on a compute utility. A utility simply means volume operations of good enough components for a common and well defined activity charged on a per use basis. 

Cloud means ... oh, hell ... anything you want it to as almost everyone ignores NIST not that it was much of definition in the first place.

Friday, October 16, 2015

Agile vs Lean vs Six Sigma

When you look at a map of any complex environment, you have three domains - the uncharted, the industrialised and the in-between stage of transitional. The techniques you use for each are very different, for example in the uncharted space you cannot plan but as things evolve you can increasingly plan.

In figure 1, I show the changing characteristics and which methods are more applicable. In figure 2, I give an example of use applied to a map from 2005.

Figure 1 - Characteristics & Methods

Figure 2 - Map

Now whilst I've used multiple methods from small scale to huge scale endeavours for a decade, there is a major problem with it. Consultants and method priests hate it. The normal approach that is encouraged within corporations is one size fits all i.e. their method - let's be all agile! let's be all six sigma! etc. These are somewhat quasi religious wars where the believers demand their method is suitable everywhere.

Recently there have been attempts to create bipolar structures (ignoring the all important transition) as though creating two groups of quasi religious extremes will somehow magically solve the problem. Hmmm. Been there, bought the T-Shirt. You alas need (at least) three different methods, three different cultures, three different types of people to cope with any complex environment unless you're willing to give something up such as the creation of novel and new. This, by the way, is not new. I've been doing this for a decade and some of the original models date back to 1993.

In the uncharted space, you don't know where you're going and all you have are vague ideas. You need to explore, you need to discover. The one thing you know is you will need to change course rapidly as change is the one constant in such an environment. You cannot plan (other than set a time limit), you cannot write a specification and agile (which is a list of basic principles often best expressed through a technique like XP but not even needing this level of formality) combined with other tools such as hack days is what I've found to work best here. It requires multiple skills from both development and business but you have an unknown problem space and an unknown solution. You just don't know, you might pretend you do but you don't. You are the pioneers, exploring the uncharted waters and any metrics (not that these are much use) are based around how quickly you're discovering. Your goal is a working prototype. Something which might be of use. Of course that doesn't mean you're discovering everything for the first time. You don't have to build a ship from scratch when setting off to explore, that's already quite an evolved act. That's something you use.

At some point, you'll discover something i.e. Land Ahoy! Of course, your "path" is all over the place and in software this translates to a buggy, incomplete, half working, often overloaded with unnecessary features (artefacts of wrong paths taken) prototype. Don't feel bad about that, this is what exploration is all about. However, at least you have a "target". So, the mentality has to change. You have an identified problem space but you have a less than ideal solution. You're now into building a minimal viable product (i.e. something of use to others) and iterating quickly through this. Techniques like XP & Scrum work well but with added constructs (e.g. MVP, Value Stream Analysis, AARRR, Business Model Canvas) as your focus is now on reducing waste along with learning about a specific space as fast as possible and building something useful & viable. This is the transition and this is where Lean comes into play. The nautical equivalent would be building the first trade routes (i.e. how to get from A to B).

However, the act will continue to evolve, it'll become more complete, more well understood and defined. Eventually it becomes suitable for industrialisation. Here your focus changes again, as you know what is wanted (it's a known problem space) but you now need to build volume operations of good enough. Deviation is your opponent and techniques like six sigma will help stamp this out. You're building the empire of scale, the highly industrialised and automated trading routes where ship deliveries are timed to the week then the day then the hour then the minute. 

The methods and types of people you need for all three domains are different. The mindsets are different. You have to embrace that.

Alas, the method priests always try to make their chosen method applicable everywhere. Ultimately they bolt on more and more to cope with the different characteristics and when it doesn't work they explain it's your fault for not using the right bits. Ultimately the method which was once suitable for a specific domain becomes less suitable as they take agile and turn it into something like lean or they take lean and turn it into something like ITIL. You can call it all "Lean [something]" if you wish but remember, there are three very different domains.

So embrace the difference. Vive le difference!

Friday, October 09, 2015

What path should the CIO take?

I've been asked "What path should the CIO take?"

Many will adapt to the changes and hence there is no significant difference. They can stay where they are.

Others will end up taking a path to Career is Over. By that I mean some non strategic CIOs are under assault from Chief Digital Officers (basically code for a strategic CIO) and Chief Marketing Officers. There is no good reason for past CIOs to lose their position or status but that will happen if they fail to adapt.

Some are destined to become Chief Inertia Officer i.e. fighting a rearguard action to protect the existing estate without adapting. I suspect many are looking for justification, a quick fix answer and a compromise with the CDO / CMO e.g. "you do innovation, we will do operation". I also suspect that's why some like the idea of bimodal. Lipstick on a pig we call it. 

A few will find a path into a more strategic role - the Chief Intelligence Officer. Most companies (and it's not just IT) have little to no situational awareness of their environment. Most "strategy" is meme copying others mixed with gut feel and bias. There's an opportunity to understand the landscape better and by that I mean not only the IT estate but also the business. You can help change how the game is played.  I know as I've not only done this before but I've seen it done by others. There is opportunity here. Most companies I meet have a desperate need to understand their environment.

So, I'll leave you with three posts from Mark Thompson that I find worth reading :-

Once you've finished those, here is a post on how to get started with mapping.

That's enough to get you on your journey. Good luck in whatever path you decide.

What Christensen gets wrong on disruptive innovation.

tl;dr Not a lot.

Once again we have one of those debates raging that is taking a pop at the whole idea of disruptive innovation and once again it questions the whole predictability of it. We have the usual claims of "Is disruptive innovation dead wrong?" and shades of the Jill Lapore debate of 2014.

Alas, this won't stop because there are (at least) two different forms of disruption - one which can be anticipated and one which can't. The problem with the current debates on both sides is they treat disruptive innovation as if there is only one form.

Yes, business builds inertia. Yes, substitution occurs. Yes, the principles of disruptive innovation appear sound and Christensen looks right ... BUT ... and here's the catcha ... when we talk about disruption through product vs product substitution then we can't anticipate this change but when we talk about disruption through product to commodity (+utility) substitution then we can! We can do this because we have a pretty good understanding of how stuff evolves through demand and supply competition.

So, for example with the evolution of smartphones and a product to product substitution (i.e. involving a discontinuity with the past) such as Blackberry or Nokia vs the iPhone then we have no idea which way this would go. Any analysis is post event. It could have been Nokia or the iPhone that succeeded. No-one knew. Christensen didn't know. Just because he called the wrong side doesn't mean the concept of disruptive innovation is wrong. It isn't. It's just almost impossible to anticipate.

However, the smartphone is a value chain (which can be mapped) and it contains a component known as the operating system. The application of competition (supply and demand) means that this component will eventually evolve to a commodity, especially if someone drives it there with an open approach. Be wary of Geeks bearing gifts.

Hence with Android vs iOS then we already know the OS is becoming commodity, that Android is driving it there and we know that Android will dominate. In fact this has already happened but we knew this ages ago. We could anticipate this change and its effects and yes, eventually it means disruption of the past models and systems based upon it. 

This will happen no matter how well Cook plays the supply chain, no matter how much people cheer for Apple. Competitive forces and the Red Queen effect are against Apple on this. They can hold out but eventually they'll end up adapting (i.e. Apple on Android) or they'll corner a niche space.

The principles behind disruptive innovation are sound in my view and I can't see anything that Christensen got wrong bar one thing. The reason why we seem to be having these endless debates is this assumption that there is only one form of disruption. It's either got to be anticipatable (i.e. predictable to a certain degree) or not. Alas there's not one form, there never has been, there never will be. There are two forms - one you can anticipate and one you can't - and the ways in which you need to deal with both forms are different.

For example.

Take an act, A, that is evolving through competition forming many different instances of that act. Let us look at A1 to A2, a product to product substitution (I've shown this in mapping form in figure 1 below). Then yes, past vendors will have inertia to this change due to existing business models, they cannot know that this new instance will disrupt their existing business model, they cannot anticipate that it will happen. This is Apple vs Blackberry. 

However, in the case of something evolving from product to a commodity or more utility (shown as A2 to A3), then yes past vendors will have inertia to this change due to existing business models BUT we can anticipate such a change well in advance and what its impacts will be. It doesn't matter whether it's iOS vs Android or Utility computing (e.g. AWS) vs old product vendors of servers.

Figure 1 - Evolution

These two forms of disruption are different,  they have subtle differences in characteristics (one of which is our ability to anticipate them) and we therefore should react in different ways. I've summarised some of this in figure 2.

Figure 2 - Differences in forms of disruption

Because one form is anticipatable (the change from product to commodity / utility forms is known as a 'war' state)  then I can use a variety of weak signals (related to publication types and changes in behaviour) to identify when these anticipatable forms of disruption are likely to occur. This doesn't mean I can get the date exactly right but I can prepare well in advance (see figure 3).

Figure 3 - Future points of War (from 2014)

[For reference, if you're trying to do this form of analysis with diffusion curves or hype cycles, then you've no hope. Diffusion curves measure diffusion, hype cycles approximate hype - neither can be used to determine evolution. You'll be running down endless dead ends.]

So, let us see this in action. Let us take two things - Big Data and Immersion

Big Data.

From the weak signals we already know that the "war" is upon us (actually, we knew this war was heading our way many years ago). This means new entrants will move into the market providing more commodity / utility forms. This has already happened with the likes of Google, Amazon and Microsoft entering the field. We know the war takes about 10-15 years to work its way through, that it's not a linear change but a punctuated equilibrium, that it involves co-evolution of practice and if those changes are large enough then new forms of organisations will emerge. We also know that existing players will have inertia (there are 16 different forms) and inertia is a killer. There are also a host of repeatable patterns and gameplay including ecosystem models that can be used to spice the fight up. We also know most companies have little to no situational awareness and therefore suck at this.

So, we can say that the new entrants will start to grow exponentially. The existing players and many of their existing customers will dismiss them as not being capable. Within 5-8 years the new players will still represent a fraction of the market (e.g. 3%-5%), the existing players will still dismiss pointing to past data but may graciously state that the systems are ok for test and development (of course, in production they'll claim you'll need the vendor's product ). During this time new methods of working will have co-evolved with the more utility forms. By around 10-15 years panic will have set into the product vendors as they see their entire business dismantled as they have no time to adapt. They will be disrupted by a change which could be anticipated in terms of what and roughly when. See figure 4

Figure 4 - Big Data


Now let us turn our attention to immersive tech (including both virtual and additive reality). Let us consider Oculus Rift and the HoloLens. Will the Hololens disrupt the Oculus Rift and related VR equipment?

Well, it might do but we have no blinking idea. This is a product vs product substitution. It could go either way. It might not even cause disruption. There is nowt we can anticipate about this (see figure 5).

Figure 5 - Oculus Rift vs HoloLens

We have no idea which way this will go - it's like Apple vs Blackberry. Any claims are guesswork or post event analysis. The best you can do (see figure 2) is have an adaptable culture and lots of very tight looped horizon scanning. There's some gameplay available but nothing like what you can do with more anticipatable change.

Of course, let us say HoloLens does disrupt the market. I can say that by 2025-2030 then we're going to see more commodity forms of immersive tech and this will change the market again most likely led by new entrants as the winners of the product wars will have built inertia due to past success.

This is the point, there are two very distinct forms of disruption. It's not all the same despite everyone treating is as such. Alas, people ignore this.

So in the meantime, we will continue to hear this fairly pointless debate rage on with both sides giving examples and counters until someone starts to consider that the reason why disruptive innovation seems to show polar opposite characteristics of predictability is there's more than one form. 

We've covered this many times before over the years, I sound like a stuck record and so I'll stop there.

Tuesday, October 06, 2015

Can I just do Settlers and Town Planners as a Bimodal?

tl;dr : yes ... BUT.

Continuing on from the post on Bimodal, I was asked "Can I just do Settlers and Town Planners?"

Let us understand what that means. You're going to focus on product improvement and the industrialisation of a component but forgo the uncharted exploration of the novel and new. Well, there's no reason why you can't do this but it does means that you going to have to rely on the Settlers extending into the outside ecosystem to discover those novel and new components which at a later stage you will want to turn into products and finally industrialise (see figure 1). If you don't do this then you have no future pipeline.

Figure 1 - Focus on Settlers and Town Planners

For reference, I've given a fuller list of characteristics of the different roles in figure 2.

Figure 2 - Characteristics (you'll have to expand)

Ok, the problem with pushing all the novel and new to the outside market (i.e. taking an outside-in approach) is you'll be in a race with others to discover future patterns of success. This is not necessarily a bad thing unless :-

1) Everyone is trying to do this and there isn't some other system to exploit (see "How Much for a Fountain of Youth")

or more likely

2) Someone is playing an ILC ecosystem game against you (or a variant such as Tower & Moat).

I won't go through the ecosystem game, you'll have to read that post but the net effect is they can use their ecosystem as a future sensing engine and the bigger their ecosystem, the more powerful the effect will be. This means they'll not only have the edge on you but this edge will become larger over time compared to simply trying to scan the market.

So, yes you can just use a Settler & Town Planner structure but you'll need really high levels of situational awareness, ecosystem play, weak signal detection or otherwise you'll be an easy target with nothing in the bag (i.e. novel surprises) and a simple pipeline to choke.

Sunday, October 04, 2015

If you really want bimodal then you'll need to give something up.

Back in 1993, Robert Cringely wrote the excellent book Accidental Empires (I have the 1996 reprint) which talked about the three different type of companies using the metaphors of commando, infantry and police.

During 2004-2006, having discovered a process of technology evolution and a mechanism of understanding the competitive landscape (known as Wardley mapping), I implemented the equivalent three party structure (known as pioneers, settlers and town planners) to mimic evolution within a single company. A description of this three party system can be found here and the importance of the middle for sustainable and competitive advantage. Over the last decade, I've written numerous articles and gave lots of presentations around the world on the three party structure and the importance of the middle.

In 2014, I came across bimodal / dual operating system and twin speed IT. I can't tell you how much this caused me to howl with laughter. I'm no fan of these concepts. I view them as old ideas, poorly thought through and dressed up as new. I've seen two party systems in the past that have degenerated into 'them' vs 'us' and with no consideration of how things evolve they are not sustainable. There is no effective process for how the new (i.e. tomorrow's industrialised components) become industrialised. The idea that somehow the two groups will work together in a 'dance' is fanciful. Brawl would be more like it. Pioneers and Town Planners are polar opposites, they don't get on well.

I'm quite convinced that those undergoing re-organisation into bimodal will be facing a future re-organisation into a more three party or spectrum based structure in the near future. Certainly that means oodles of cash for consultants advising on these multiple re-organisations and be honest, I don't care if it's private companies that I'm not involved with. My concern is this spills over into Government Departments.

There is however a way of creating a workable bimodal structure but it means you need to give something up. To remind readers, the three parts for which you need brilliant people are :-

Pioneers. Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder but they fail a lot. Half the time the thing doesn't work properly. You wouldn't trust what they build. They create 'crazy' ideas. Their type of innovation is what we call core research. They make future success possible. Most of the time we look at them and go "what?", "I don't understand?" and "is that magic?". In the past, we often burnt them at the stake. They built the first ever electric source (the Parthian Battery, 400AD) and the first ever digital computer (Z3, 1943).

Settlers. Settlers are brilliant people. They can turn the half baked thing into something useful for a larger audience. They build trust. They build understanding. They learn and refine the concept. They make the possible future actually happen. They turn the prototype into a product, make it manufacturable, listen to customers and turn it profitable. Their innovation is what we tend to think of as applied research and differentiation. They built the first ever computer products (e.g. IBM 650 and onwards), the first generators (Hippolyte Pixii, Siemens Generators).

Town Planners. Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale. They build the platforms of the future and this requires immense skill. You trust what they build. They find ways to make things faster, better, smaller, more efficient, more economic and good enough. They build the services that pioneers build upon. Their type of innovation is industrial research. They take something that exists and turn it into a commodity or a utility (e.g. with Electricity, then Edison, Tesla and Westinghouse). They are the industrial giants we depend upon.

The process of evolution (see figure 1) causes a change of characteristics which is why you need multiple attitudes and why one size fits all methods don't work (i.e. why agile, lean and six sigma should die and be replaced by agile plus lean plus six sigma). 

Figure 1 - Evolution

If you want to create a bimodal / dual operating system structure out of this then you really have to give up on one part. For example :-

You could focus on Settlers and Town Planners alone i.e. your company could all be about product development and industrialisation. Simply drop the pioneering research function. The best way to do this is with the press release process i.e. force the writing of press release before any project starts because no-one can write a press release for something unexplored. Don't attempt to do any pioneering stuff and instead use ecosystems models such as ILC or some equivalent to do future sensing

You could focus on Pioneers and Settlers alone i.e. your company could develop novel concepts and then create products out of this. Simply drop the town planning function and outsource all industrialised components (including dropping your own products) where appropriate.

You could decide to focus on just one aspect i.e. be Pioneers (develop novel concepts), be Settlers (create great products) or be Town Planners (create highly industrialised commodity and utility services).

However ... 

1) DON'T try and break into Pioneers and Town Planners. These two groups are far apart. You'll create a them vs us culture. None of the novel concepts will ever be industrialised because the Pioneers won't develop them enough and the Town Planners will refuse to accept them for being underdeveloped. Both groups feel they are the most important and both ridicules the other.

2) DON'T bury your Settlers into one of these groups. They won't feel welcome, they will be in conflict with the group becoming second class citizens. Put them in the Pioneer group and they'll be denigrated to documenting the "glorious" inventions of others and fighting a losing battle over user needs. Stick them with Town Planners and they'll be seen as 'lightweights', the people whose job it is to deal with those annoying Pioneers and document what they've done etc.

Either drop one aspect (i.e. Pioneers or Town Planners), or focus solely on one aspect (i.e. Pioneer, Settler or Town Planner) or focus on ALL three. This means the Settlers (the missing middle) need to be recognised.

Create one mode to focus on "core system maintenance, stability, efficiency, traditional & slow moving development cycles" and another mode to focus on "innovation & differentiation with high degree of business involvement, fast turnaround & frequent update" ... wellPioneers and Town Planners don't mix and creating two camps focused on this won't make for a happy environment.

Oh, but isn't Bimodal / Dual better than Unimodal / Single? No, I'm far from convinced that this is the case. In the past many ignored evolution and squashed all three attitudes, cultures and type of people into one group called IT, Finance, Marketing or whatever (yes, evolution impacts everything we do). Those groups would tend to yo-yo in methods between the extremes hence in IT we had Agile vs Six Sigma (ITIL etc) battles. But every now and then the 'middle' would get its chance. Today you're seeing this with Lean, with focus on user needs etc.

If you organise by the extremes e.g. pioneers and town planners or mode 1 and mode 2 or whatever you wish to call it then you're burying the middle. This is not good. This middle group are not mode 1 or mode 2 but they have a vital role to play. They deal with the transition between the extremes. However in a dual structure then you've given the other attitudes a flag to rally around, you've formalised a structure to support this and left the settlers singing in the wind. You've gone from ignoring them (which you did to all attitudes under one group) to actively discouraging them and sending a message that only pioneers and town planners matter.

Well, you've been warned, tread this path carefully. This will be my last post on this subject (I hope) given it's such old hat but I'll come back in a decade and we shall see what has happened to these dual structures.

P.S. The mapping technique, the characteristics, the use of multiple methods, the pioneer / settler / town planner structure and a host of other stuff you'll find in this blog is all ... creative commons share alike. You can do this yourself. You don't need external consultants, license fees etc.

Tuesday, September 15, 2015

How commodity is something?

tl;dr There are a number of different ways you can refine your maps but in most cases, it's rare that you should go beyond aggregated views. Most of the benefit can be gained by a group of people sitting around sharing and discussing the map

Everything (whether activities, practices, data or knowledge) evolves through the application of competition (supply and demand side). Each instance of an evolving act diffuses through a market over time and hence evolution can be seen as a series of diffusion curves (often many hundreds) with each diffusion curve having its own chasm

Those diffusion curves however have different markets and different time spans i.e. diffusion of the first phones was not the same as diffusion of later, more evolved, more mature phones. So when examining an act (A) which is evolving through ever more mature examples of the act (A1 to A5) then you see a diffusion patterns that looks like figure 1.

Figure 1 - Diffusion of an activity A

At any moment in time in the market you may have many examples of the act in existence i.e. older phones to modern phones to the latest phone can all exist in the market at the same time. You cannot simply look at a market and see 50% of households having something and make a claim over how evolved it is. Whilst evolution contains many diffusion curves, evolution does not equal diffusion and you don't know which diffusion curve you're on.

However, there is a pattern to evolution which you can measure by examining the ubiquity and the certainty (i.e. maturity and completeness) of a thing. Unfortunately, the measurement can only be done for the past. Something has to become a commodity before its past can be measured accurately. This means that whilst I know the direction of travel of something (e.g. the genesis of an act becomes custom built becomes product becomes a commodity - see figure 2), I can not directly measure where something is but only where it was.

Figure 2 - Evolution

The reason for this is certainty axis itself and the role of individual actors in the market. I can only say where something is with certainty once it becomes certain. The future unfortunately acts as an information barrier and until something has become certain (and I can therefore measure its past) then I have to guess unless I invoke some form of crystal ball.

Now this evolution curve provides the x-axis used in mapping. So, how do I know where to place something (e.g. activity A) on the x-axis if I can't measure it? (see figure 3).

Figure 3 - Where on the map is it?

There are a number of techniques you can use.

Ask yourself what this thing is.
The first step is to ask yourself is this thing :-
a) rare and poorly understood i.e. genesis?
b) uncommon and somewhat understood, normally provided by custom built examples often built by consultants?
c) quite common and reasonably understood, often provided as product or rental service through product vendors?
d) well understood and ubiquitous provided via utility services or as undifferentiated commodities?

If you take a number of people (say 2-4) with experience of the field then you can get a better answer by asking the group. This is also helps when there's arguments because that usually signals the act consists of several components at different stages of evolution.

Look at the properties of the thing
The second step is to examine the characteristics of the thing. As it evolves its characteristics will change from the uncharted space to the industrialised (with a transitional space in between). See figure 4.

Figure 4 - Characteristics.

Hence look at the activity for example and ask yourself :- Is this rapidly changing? Is this a differential? Is this exciting? Is it stable? Does it seems chaotic? Is this well defined? Am I experimenting? etc.

Look at other maps.
Obviously everyone has bias, hence ideally you should use a group to determine how evolved something is. However, if you have several maps then you can use a aggregated view (i.e. a summary of common points on different maps) to determine how this thing should be treated. You do this by looking for clusters in order to remove bias (see figure 5).

Figure 5 - Aggregated View

The above graphic is a great way of removing duplication in an organisation and stopping groups from custom building the sort of thing which should be a commodity e.g. user registration

Look at publication types.
At this point I'd probably say you're going overboard. You don't need to get maps this accurate in order for them to be useful tools for organisational learning, collaboration, communication, scenario planning and strategic gameplay. However, if you want to go the extra mile then start examining the publication types (see figure 6).

Figure 6 - Publication Types

E.g. examine the frequency of different key publication types to determine roughly where you are. Please note, even this measure is rough until the act has become well defined (i.e. certain) and in which case the volume of publication types can be used to determine where it was (past tense) on the certainty axis. However, you can use this as a weak signal but I mostly use this in anticipating future change. 

NB. You have to be careful when examining publication type because certain words / phrases appear in multiple stages. For example people talk about platforms when describing a product (i.e. you can build on my product) and they also talk about platforms when describing utility services. The two are not the same.

At this point you're definitely going overboard and trying to create a perfect map. Don't bother, your map will change and you shouldn't spend more than a few hours to a day creating it. The only time you should be stepping into weak signals is when you're into anticipating a very specific change and working out when to roughly attack a market. 

There are a number of signals that can be used, for example when crossing a boundary you need to overcome inertia and that requires a number of factors to be in place - concept, suitability, technology and attitude.

For example in figure 7, we have an evolving act and every time it evolves from one stage (e.g. custom) to another (e.g. product) and hence crosses a boundary then there's inertia to the change created by the incumbent group. Hence the originator (for genesis to custom), consultants (for custom to product) and product vendors (for product to commodity) all resist a change that impacts their market. The size of the inertia barrier increases as the act becomes more evolved (and more established). 

Figure 7 - evolution and inertia.

In order to overcome an inertia barrier you need the four factors in place. The concept of providing the act in the next stage must exist. It has to be suitable (i.e. widespread and defined enough). The technology to achieve this must exist and finally there must be an attitude of acceptance for such a change by the customers. The latter is normally represented by the customers being dissatisfied with the existing arrangement.

You can go further into weak signals, for example the rate at which higher order systems can be built from lower components accelerates as the underlying systems become more industrialised. You can even use timing based upon common economic cycles such as peace, war and wonder (see figure 8). However, these are overkill for a simple mapping exercise and are more suitable when directing an attack.

Figure 8 - Economic cycles & speed of building higher order systems.

There are a number of different ways you can refine your maps but in most cases, it's rare that you should go beyond aggregated views. Most of the benefit can be gained by a group of people sitting around sharing and discussing the map.