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.

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.