Thinking Beyond Design Thinking

design thinking - pixabay.png

You’ve probably experienced design thinking in any digital project you’ve started or been a part of in the past few months. The tools of design thinking are highly popular in the enterprise today – from ethnographic research, contextual inquiry, and shadowing, as well as delving beneath the surface of user stories for real insight.

For enterprise long used to technology solutions that take aeons to deliver and still turn out clunky and unusable, it’s easy to understand why design thinking is so ubiquitously popular. And I’ve seen it at work in any number of client and internal projects. And I think there’s a danger that design thinking might crumple under the weight of its own expectations. This article is about why we need to use design thinking carefully.

But let’s start by reminding ourselves about why it works? The reasons are fairly obvious design thinking starts from a position of empathy. This by itself should be an obvious thing, but clearly it’s been lost in the ossification of corporate processes and taken over by the lure of experience. So people have been building solutions based on what they ‘think’ they know about what users want and how, rather than asking them. As this piece from the HBR, by Jeanne Liedtka, highlights, design thinking works because it forces us to challenge our assumptions. The more interesting questions we ask, the better the answers are.

Also, design thinking gets past 2 of the biggest barriers in designing solutions. The first is assumptions. We typically have truckloads of assumptions about our users, and design thinking forces us to validate and often counter them. The second is the false comfort and lure of experience. A marketing manager with 20 years of experience thinks she understands her customers really well. Or perhaps we self reference, after all we’re all experts in retail because we shop every week.

So design thinking works, and it delivers by addressing all of these challenges and building a solution around the users needs. But while it is the mythology du jour of defining digital product experiences, it isn’t exactly new. Any product developer will tell you that this is exactly what product designers have done throughout history. My favourite example is that of the Honda engineering and design team that spent a week at Disneyland in the US just observing what families took out and put into the boot of the car.

Steve Jobs was apparently not a big fan of asking his customers what they wanted. Nor according to received wisdom was Henry Ford. But that doesn’t mean they weren’t keen observers of human behaviour and needs. The latter also suffered because he didn’t keep pace with the changes in the needs and expectations of his customers.

My current concerns, working with a number of design thinking based projects and scenarios, stems from 3 key challenges. The first is the dilution of the idea of design thinking. This is when we jump to the rituals of design thinking without actually getting to its key principles. Plenty of so called design thinking workshops are just brainstorming sessions under a different name. If the right questions aren’t asked and the right people aren’t responding, then this is just another workshop. The second is the danger of reinventing the wheel. Design thinking, when applied to a known problem space, should follow after enough secondary research has been done, else you will simply be learning the hard way what others already know. For example, while designing a shopping cart for a new ecommerce business should not be design thinking based from scratch, given that there are hundreds of examples of working shopping cards online to compare and evaluate. The third, follows from the second therefore in knowing what kind of problems to apply design thinking to. And this is typically new areas, and new products, or where there is a belief that current solutions don’t do enough. And you can’t know that unless you’ve done the research.

This article, also from the HBR, by Natasha Iskander, provides a more structured critique of design thinking – as it highlights the gatekeeping role of the designer, the inevitable subjectivity of the process and the problem of a finite and book-ended process of design that ends up preserving status quo, rather than a continuous evolution. Those of you who have been involved in agile projects will know the difficulty of fitting the commonly accepted double diamond design approach into an ongoing agile process. Usually it ends up as an early stage activity that has an end point, while product development becomes an ongoing and open ended activity. One of the most insightful points Iskander makes is the challenges faced by the prescriptive nature of the design thinking process in a world defined by continuous and evolving uncertainty. In other words, a VUCA world.

So the next time you go into a design thinking exercise, ask yourself (1) is this a problem that has been solved before? And by whom? (2) have we first made sure we’ve looked at what’s already been learnt before we go discovering for ourselves? (3) are we really following the design thinking principles, or are we going about gathering requirements in a traditional way, but just calling it something more cool and interesting? And (4) are we keeping the design and ideation process alive, or is it seeking an artificially finite solution? I have a hunch that not all your design thinking projects will pass these tests.

Digi-Tally: Through My Digital Viewfinder, Jan 21, 2015

This is still the week of the CES after-glow, and there’s a lot of reflection in the media about what we saw at CES. In a nutshell, and as summarised in the TWIT podcast, no tablets and more cars. Autonomous vehicles has been one of the areas that has moved forward quicker than most of us had anticipated and may have great positive externalities by way of enabling a sharing economy for transport. In much the same way as the word “television” has been redefined in the past decade, we may be entering a similarly transformative phase for ‘automobiles’. It may well be a reaffirmation of the name – a self driving car is after all truly auto-mobile. But increasingly we may start to see the car as a network, a node on a larger network, or a collection of smart (and inter-changeable) components. On the other hand the broader IOT examples keep mushrooming, and we’ll no doubt be exposed to weird and wonderful examples of the power of Internet of Things – from smart security to home automation, and from wearable health and wellness monitors to self managed environments.

It’s also been the week for spotlighting the great transition of technology eras – as we move from the PC & desktop era into the untethered, wireless, mobile and ubiquitous computing era, the struggles of Intel and IBM amongst the behemoths of the 90s and 00’s are sharply in focus. Intel shipped over 100m chips, but are still dramatically dependent on the shrinking PC market. They’ve made an entry into the wearables, tablets and sensors space (interestingly, by acquiring a Chinese firm), but the numbers are still small and analysts aren’t convinced yet. IBM have just announced a 11th straight quarter of declining revenues. The slowdown is precipitated by the hardware business, with the digital arms, including mobile, security and cloud showing strong growth but very low numbers. Overall, a 16% growth in “digital” is probably not good enough, and the combined weight of 27% is impressive, but you sense that the bits that are big aren’t growing fast enough and that the parts that are growing well, aren’t big enough, to actually create an overall positive outlook for IBM just yet. At Cognizant, we often speak about the shifts of the “S-curves” we are currently in between the Web era S-curve (dominated by fixed wireless and PCs) to a digital S-curve – dominated by ubiqutous, nano-computing and wireless connectivity. Intel and IBM’s challenges are symptomatic of the difficulty of transitioning success from one wave to the next. But to state the blindingly obvious, they will not be alone. How will your business make this jump?

I continue to believe that 2015 will be a year of digital infrastructure. Broadly speaking this should include cloud, middleware and security, for most large enterprises. Of these, security has been much in the spotlight of late, with Sony obviously being the most high-profile victim. But arguably, despite the political intrigue and the alleged involvement of North Korea, the hacking of the US Central Command should be more akward, geopolitically speaking. This list of famous hacks from The Telegraph has some fascinating nuggets. From the unintentional Morris worm (Morris is now a professor at MIT), to the Target and Sony Hacks of the last 12 months. Two trends stand out. The first is the increasingly political colour of the hacks – indicating that this is now a serious form of warfare or international espionage. The second is the simplicity of many of these hacks. DDOS, phishing, these aren’t particularly sophisticated attacks, but they indicate that as humans we often represent the threats and weak links in the security environments of our organisations.

The HBR carried this great example of the success of Nordstrom’s digital strategy. I think all success stories tend to get over-simplified to an impractical level, in our hunt to find an easy formula. Usually there are dozens, if not hundreds of things that need to go right for a major project to work well, and it only takes a few to not work well, for it to be a limited result or an outright failure. This is why we have many more failures than successes of course. So while I agree about the arguments in this piece, I would hesitate to consider this as a necessary and sufficient condition for digital success. Nordstrom’s strategy comprises of a focus on customer experience, and the extensive use of digital (SMACIT) tools across the length and breadth of the business, to effectively create a new business model. As always, both God and the devil lie in the details.

And what should we make about Google’s change of tack on Google glass? It was initially interpreted as Google pulling the plug on a venture with mixed success, which it has a history of doing. But it seems apparent now that Google are taking a leaf out of Apple’s book and going design-first. By handing this product to Tony Faddel, of Nest and iPod fame, Google seem to be acknowledging that the technology (which works) needs to be nested inside a highly usable, and ideally beautiful product. This is hardly a revelation but if this is indeed the thinking, then it’s wonderful to see Google, the spiritual home of engineers, acknowledge the role of design and user experience.

Also, at CES, there was much buzz about more wearables – watches from Sony and HTC, and other devices. Smart watches look like being the wearable de l’annee, but the hunt for the killer app is still on. Any guesses? What would you use a smart watch for? What problem could you solve? Or what wonderful new benefit could you imagine? Like many others now, I don’t wear a watch to being with, so it would have to be a compelling benefit to make me wear a watch again (one more device to manage!).

It would be remiss of to not mention this video from Ola Cabs in India which a colleague kindly sent me. It’s refreshing to see such a stark focus on user experience from an engineering point of view, rather than design alone. Anybody looking to build a product should see this.

And finally, on a lighter note, this set of maps, yet another example of the emotive power of data in our lives, my favourite is the first map, on second languages spoken in the boroughs of London. Amongst other things, it shows you the patterns of immigration and the abundance of Indian and Polish people in London. May be there needs to be a new alliance for the IPOs (people of Indian and Polish Origins) a microcosm of a geo-political shift, a trading block and a platform for cultural enrichment hitherto overlooked. I mean, all this technology, data and understanding should bring us closer, right?

Doing Digital: 10 Starting Points

There is an alluring future that digital enthusiasts like us love to project. It involves the excellent and industry shaping use of analytics and big data, whist getting our customers and consumers to love us on web, mobile and social platforms and willingly offering us their data so we can turn it into ever more gasp-worthy products. In this world, we’ve magic-wanded away the infrastructure challenges, the silos and politics of real businesses, the cultural inertia and significant technological challenges.

Most companies that I know get this picture and they agree with the destination but have no idea about the journey. Most importantly, they don’t know where to start. Here are 10 recommendations / observations for getting your digital show on the road.

(This post comes from an opportunity I had to speak about digital recently. At the time of writing this, I’ve identified at least double this number of recommendations, but for the purpose of this piece, here are 10 basic ones). 

Understanding How Digital Is Different:

  1. Digital is creative and emotional: Traditional IT works from process outwards, building on conformity and compliance, and the focus is on the logic of the solution, and it’s efficiency. Digital starts with the user journey inwards, building on individual creativity and embracing diversity of users and behaviours. The focus is on engagement, and getting users to use your product, over the many viable options available to them. Consequently this is about the emotional connect to the user. The only right solution is the one that engages your users. One of my favourite examples is the “get me home” button on the national rail app. It ticks the boxes for emotional responses while also enabling a context sensitive and customised response all at once. 

  2. Digital is lean. I don’t think it’s a coincidence the digital explosion is synchronous with the widespread adoption of lean and agile thinking. In the way that technology landscape is morphing and changing, it is far more important to be agile than to be right. You can be right once, bur it’s likely you’ll be wrong often. On the other hand, lean methodologies allow us to live with change and learning. This is why Evernote which performs that most basic task of taking notes (and on which I’m actually composing this piece) is able to succeed against a Microsoft, Apple and a hundred other note taking softwares. Most of the digitally successful companies I’ve worked with have started small but innovated fast and often. 

  3. Digital is Di-Phy. An increasingly intermingled amalgam of digital and physical environments. When thinking of solution architecture, we not only have to think about software, OS and hardware, but also of the physical environment in which the solution exists. An excellent and simple example of this is the QR codes on London bus-stops which when scanned, indicate bus times. It’s a highly responsive system which is actually faster than the otherwise excellent bus-timing applications which exist. But one which requires thinking through the solution, user experience, deployment and use, across the physical and digital elements.

How To Do Digital

  1. Start anywhere but start now: Many people I know agonise over which business processes to start with first. While you could certainly spend a few days in shortlisting the most critical user journeys that define your product or service, it’s probably more important that you start soon, rather than start with the right process. Start anywhere, somewhere, but start today. Transform one user journey. This will typically necessitate new processes and changes to existing processes. It might even lead to the creation of new products or services. Most importantly this will create a significant number of new digital touch points which will be sources of new data. 

  2. Digital Infrastructure is critical: The digital tools usually get the most amount of attention – mobile, social, sensors, and more. But you need to consider a stratification within the tools. The three mentioned above and project-level analytics can be considered at a project level. However, you also need to consider the digital infrastructure layer, which should be addressed at an enterprise level. This includes cloud, security and middleware as well as enterprise analytics. The last of these deserve special mention and we’ll come back to it. But cloud, security and middleware are critical to almost every project, yet are best managed as a common, infrastructure layer, where the investment can be shared between a number of projects. Cloud solutions can be used in the enterprise to enable any number of services for projects to consume, so the benefits are more than just the cost savings of scale. Middleware includes both MBaaS products (e.g. Kidozen, Anypresence) and API Management ones (ApiGee), for example. Security needs to be thought end to end, including authentication and identity management, especially in a multi-device, cloud based environment. Most companies still seem to be underinvesting in digital infrastructure. I believe 2015 may be the year that digital infrastructure may become front and centre for CIOs. 

  3. Meaning Making is the promised land: Ultimately this game will boil down to the quality of data you collect, the efficiency and effectiveness of algorithms you can write and the new meanings and insight you can create, to serve customers better. However, starting off with a ‘big data’ project may not be the right approach. You also need to improve the quality and depth of your own data, which is best done through digital touch points. The Code Halo (TM) model recommends that you create an inventory of touchpoints. The Mobile Moments Model from Forrester Analysis suggests identifying those specific points where you can change a customer perception or experience via mobile led experiences. You get the drift. You need to start with simple digital models, but keep at the back of your head that the goal is to feed that meaning machine you’re building. Make sure you identify and collect the right kind of data through each of your digital projects.

What do IT Departments & Vendors have to do differently?

  1. Engineering & Design Culture: This article by Mark Kawano, a former designer at Apple points out that contrary to popular belief, it’s not that Apple always employed the best design talent, but it was more that Apple had an engineering culture that viewed design and user experience. This happy confluence of engineering and user experience design philosophies has very powerful synergies. It means that engineers never build without thinking about user experience, so the bar is already set pretty high. It also means that any inputs from user experience experts is sought proactively, consistently and valued highly, as a part of the engineering and technology development process. Much of traditional IT still treats UX as a necessary evil that must be endured to “beautify” the great work that engineering has already done. This culture is prevalent across the vendor community as well as IT departments. As such it results in the proverbial ‘lipstick on a pig’, in terms of output. It is not a coindence that IBM are among the top recruiters of design talent right now, but it remains to be seen whether the average engineer sees user experience design as core to his or her work. 

  2. Stakeholder Complexity: Typically the stakeholder map of a digital project is very different from that of a traditional IT project. Suddenly you have marketing, communications, sales, LOB associates, and many others around the table, engaged in the minutiae of the execution. Consequently, you need to have project and program management of a very different kind – you need to speak the language of all these different groups of people and not rely on IT jargon. This is a slightly greater challenge for offshore providers as there are a few more linguistic and cultural barriers to cross. 

  3. Rejigging the commercial model: Most businesses work with budgets and ROI calculations. Vendors work with gross and net margin projections for programmes and clients. In digital projects, owing to the the stakeholder complexity as well as the uncertainties, it is imperative that we err on the side of over investment in managing the early stages of projects. Note, this is different from over investing in the solution or technology. It just means creating a stronger, more robust program & project management and user experience layers, to work through those initial hiccups. The project over it’s lifetime will in all probability more than pay back that earlier investment. Don’t look for project margins for the first 3 months. 

  4. Collaboration on steroids? Last, and certainly not the least, in this list, is the heightened need for collaboration. As white space opportunities open up, which don’t sit in the traditional industry vertical or horizontal boxes, there is an increased need for joined up thinking. Consider for example the connected home – part media, part utility, part telecom, it provides opportunities for entirely new value propositions comprising a wide range of technology solutions. The same would apply to Connected Cars, Smart Cities, or Wellness markets. Traditional IT departments and IT Vendors are long used to working in specific sectors and visible reward mechanisms. This kind of fuzzy collaboration with lack of clarity about the outcomes and rewards at an individual level, requires a mind shift from this traditional mode of thinking.

Once again, I can think of at least 10 more areas of difference, either in philosophy or in action, but we’ll save that for a later date!

Digital: Time To Put The Horse Before The Cart?

As somebody who has come into the technology world with an education in economics and business, I have always been the one to argue vociferously, that it’s business first and tech after. You must first sort out the business objective, change, process impact and then select or customise the tool to the business needs.

Of late, in the digital environment, I am learning to question and often invert this logic.

Cart horse

But let’s remind ourselves of what ‘good’ means, in traditional technology projects. The correct flow has always been:

Business need –> Process change –> Define the ‘to be’ stage –> deploy appropriate technology –> impact on user behaviour –> outcome achieved.

As a consultant, I’ve made a living out of fixing this flow. Or specifically, fixing projects that have confused this flow. Many IT projects have historically gone bad because the technology came first, and nobody had thought about the business outcomes, or the desired process change.

But I find myself regularly giving advice in the digital projects which includes putting in the technology early in the game. Why is this?

To start with, traditional technologies were not intuitive. Many long suffering users would argue that they are often the absolute opposite of intuitive. It is definitely true that these technologies and tools are process centric. They are based around a view of a business processes that is deemed the ‘right way’. As such they are based on conformity, and used to drive process adherence.

Digital technologies, on the other hand, are fundamentally based on diversity. This is not diversity as in customising the font and the colour-scheme. Think of a smartphone, which, from the moment you start using it, starts to morph into something that is uniquely yours – in the applications you carry, the way you arrange them, the way you use it, and what you use it for. This is not about selecting from a limited number of pre-defined settings. It is creating enough degrees of freedom and choices so as to enable, mathematically speaking, options which are many orders of magnitude higher in number. A virtually infinite number, since you can’t humanly work through all of them. Or think about any two people’s Facebook or Twitter feeds.

Even the way 2 people use map applications can vary. My wife prefers Apple Maps (yes, and I still love her!). I can’t get away from Google Maps. The way we access the apps differs, how we check directions differs. Even the way we search varies. Both of us use exactly the same model of the iPhone.

Digital technologies are as we all know based on user centric approaches. They are built based around user journeys, not business processes. This philosophy shift, is the second key difference, and is the reason why these tools and technologies far more intuitive. The tech is not being used to corral a diverse user base into standardized work processes, it is in fact liberating them to do things their way, while allowing an underlying process to support a massive variety of users.

The combination of these 2 means that the technology can embrace the diversity of people and behavioural spreads without having to apply blinkers.

So far so good, but that still doesn’t explain why we should put technology and tools first, does it?

Now consider that in enterprises, technology is something that is done to people. Users are essentially recipients of the technology that is planned, designed and implemented by a specific set of people. Digital technology is more of an interplay than a one way street. And while traditional technologies are deterministic, digital is exploratory and discovery driven.

A critical pillar of this is the move to agile methodologies. I met a start up recently which has been self funded, has 6 people, has an excellent product, and has had 28 releases of its app within the past 3 years. The best businesses today tend to talk about a ‘tight development cycle between user feedback and new features’ – this tends to be in the range of a fortnight to a month, between releases. This also implicitly means that your users are now willing participants in the product roadmap and there is very little second guessing of what the users want.

When you pack all of this together, you can now see why in the digital space it makes sense to get technology into the users hands early. To summarise, the technology is intuitive, and digital solutions are typically discovery driven and supportive of huge diversity, and the delivery and continuous improvement is driven through tight agile cycles. So giving something that simple that works, to the user community, engages them, draws them into the development and improvement process and creates outcomes that you possibly couldn’t imagine even with the best product team. Its why Evernote or WhatsApp, which are fundamentally simple, even primitive propositions – note taking and text messaging, respectively – are able to take market share away from Microsoft or even Google, in the case of Evernote, and Vodafone or (earlier) Facebook, in the case of WhatsApp.

I argued earlier that Digital is all about big vision and small action. I’m now going a step further that the small action may well be to get a simple tool or platform to your users in the shortest possible time, rather than spend weeks and months drawing process maps and building complex systems. Now, obviously there are risks here. Simple and quick does not mean poor quality and badly thought out or executed. This isn’t a short cut, it’s a methodology which requires skill. The skill to strip a complex idea to it’s MVP version, and then to elegantly execute it. User experience quality is non-negotiable. And it has to solve a problem, not half a problem. And the best measure of this, is that it has to make the users’ lives a little easier, in however small a way. The challenge is that only the user can assess whether this has actually happened.

I was pleasantly surprised when I flew into the US this time to notice there were self service kiosks at immigration, at Atlanta. Sadly, the output of that processes was only to verify the fingerprints and then stand in another queue to meet a person. In a competitive environment (which I appreciate this isn’t), this would be the equivalent of solving half a problem.

So the way a digital “cart-before-the-horse” process might work is:

Product vision —> User journey understood —> MVP delivered —> engage with feedback —> co-create product roadmap with users —> co-own the outcomes —> deliver the (modified) vision.

So we’re back to the idea of customer journeys, and understanding how to simplify or transform them. If you were creating a new consumer product, such as the next Dropbox or Spotify, you have a certain level of freedom, I would even say simplicity as you have a clean sheet of paper with respect to your back end, processes, service and fulfilment. The challenge for enterprises is that simplifying one customer journey may require cutting across multiple business processes. This is why this is much harder for large businesses. From the earlier world where we built software to replicate our desired view of the process, we are now building tools that are perpendicular to process thinking. This can be messy, politically, operationally and commercially, for large organisations. Offering a transformation of how automobile accident claims are settled by an insurance company may require multiple departments, processes and existing technologies, to be impacted. So it would be a mistake to think of this as a trivial exercise of throwing a bit of technology out.

Also, digital processes typically apply to the systems of engagement – broadly speaking, to those components or aspects of your systems which need to interface with humans – be they customers, partners or employees.

And here’s the catch. Once users start to engage with your MVP technology product or solution, they start to drive the evolution of that platform. You now have the proverbial tiger by the tail. You can’t go halfway down the process and then abandon the needs and feedback that your users prioritise, even if it goes against what your Senior Vice President of Product Development (or other HIPPO) wants you to do.

So while it sounds simple, this is actually quite a profound change for enterprises, and especially for the entire ecosystem of IT teams and traditional IT vendors but one that you need to embrace unless you want to become a victim, rather than a proponent of Digital Transformation.

Digital: Big Vision, Small Action

I’ve been a part of scores of discussions and projects around digital transformation, strategy and innovation. I’ve also been in the trenches trying to make some of this stuff actually happen. Over the years I’ve developed a strong olfactory sense of ideas that aren’t going well and those where there’s clearly a smell of success. 
I’ve spent many moments reflecting on these experiences. Sometimes at airport lounges by myself after day long meetings, nursing a glass of wine. At other times, in heated discussions with colleagues, locked in the deadly embrace of entrenched opinions. 
In a nutshell, in my experience, it boils down to a simple credo – big vision, small action. This is a viewpoint you will see reflected in a lot of contemporary writing and thinking around lean and agile models, but somehow, while thinking big comes naturally, it’s very hard for big companies to act small. But every day I see signs that the smartest companies are recognizing the value of lean teams, working on small outcomes, which create momentum and the building blocks of great change. For most others, fail-fast is something they like to talk about but it stays on the slides rather than finding its way into the program. 
Don’t get me wrong, big ideas are critical. They underscore the vision and direction in which we need to move. The big idea is the north star of our journey. But you cannot negotiate even half a mile of unfriendly terrain with your eyes fixed on the north star. And all too often we fall into the trap of big idea & big action. 
A typical idea of a big action is when a large company goes – ‘we are going to completely re-engineer the way we sell our widgets to our customers, across our 16 divisions and migrate from a direct to indirect sales network whilst improving our net promoter score and digitise our entire sales process while we’re about it’. You’ve all been there I’m sure. 
I’d like to highlight five very specific benefits of small action – those agile, lean projects which we love to quote but seem reticent to undertake. And why, especially in the world of digital change and transformation, they are even less useful than a hippopotamus at a barbecue. 
The first challenge is politics and alignment. If you want to make a big change, in large organisations, you are expecting to get the buy in of a dozen or more senior people, who may well have contradictory expectations and competing ambitions. The time taking process of consensus building is the anathema of change, and often the end product of a consensus is an unwieldy compromise which no longer has the ability to deliver the benefits anticipated. In contrast, the small action looks at creating the smallest viable version of this change, may be in one division and one product line of a less prominent business unit. But however insignificant it is, you can never argue with success or with data, and small change grows quickly on the back of data and proven success. The power of digital is that it IS possible to create successes and gather effective data on a small scale.
Speed is an immediate victim of the big change process. Likely timelines for getting alignment with senior teams can take months. It can even take months just to get the right people into the room, to discuss the key issues. In fact, the small change approach can deliver large transformations faster because once it gathers speed, the change rate is exponential. A few years ago, I was working on a large complex program with half a dozen workstreams, which had gone on for over a year with almost zero success. People were demotivated and change resistent. One of the little things we tried was to take one of the workstreams and just focus on making that work over an 8 week timeframe. In two months, we had a success story, and suddenly everybody wanted to be in on the journey. The entire program was completed in under 8 months. 
The actual implementation of a large scale program can be exponentially complex in terms of detail. This is not to say it can’t be done. If you were building a new airport terminal, you would have to take on and manage the complexity, but in the digital world the number of unknowns is also very high. It may sound simple to say “we’ll combine our CRM data with our transaction system, to create better views of customer history” but in one company where we tried it, we stumbled on firewall access, data structures, speed of response, security issues and user interface design. You can gloss over those challenges in a powerpoint presentation but not in the actual implementation. Will your grand plan survive it’s first brush with reality? In a small action approach, you can break up complexity into much more manageable chunks and solve them one at a time. Whatsapp recently announced that it had added the much awaited blue ticks for message delivery. The service has grown a lot both in features and popularity, but the first version of Whatsapp was launched in 3 months with 4 developers working. Evernote still releases a new version every other week. 
You see, it boils down to learning. In the large change programs, we spend a lot of time discussing with ‘experts’ and owners of expertise areas. We seek advice and inputs and then we expect armed with all that planning, that things will go as per schedule. Small change makes no such assumptions. Small action learns ‘on the job’ and consequently it learns in real time. One is a learning by talking, the other is learning by doing. I think we all know which is more effective. In my experience with digital tools & projects, nobody’s really an expert – everybody has gaps in their understanding. So learning from expertise is immediately limited. 
Finally, the digital landscape itself is changing. From regulatory stances on privacy (Google) or entering new markets (think Uber), to new platforms, tools, models and disruptive players, there is a high change environment in which you need to operate. Given this, the danger of the big change approach is obvious, with it’s slow and complex  approach, it may be outdated by the time the implementation has actually started. And often the fear of going back and re-negotiating the same issues, means that the program just gets shelved. This is probably the single most common outcome of large change programs in the digital environment. It gets put on the shelf and people just stop talking about it. Ultimately, it becomes a symbol in the organisation of project failure. People go ‘rememeber project Orion?’ (nudge! nudge!). The only way to address this is through the calculus of small change. Stick to small agile action which can help to absorb directional change brought about by the environment, and you never have to jettison a very large amount of work, so the risk is never too high. 
A couple of years ago, we were pitching some new and exciting technology led change program to  a client who are a well known Utility company. Our approach involved running programs of change, integrating complex back end systems and creating an agressive 6 month program of work. One of the seniormost execs in the room from the client organisation started the meeting by telling us how he along with a couple of his engineers had just spent the weekend ‘playing around’ with a new location based open source utility which they found to be quite interesting and had built a pilot for replacing their existing clunky routing application and were planning to roll out the change to a small set of service teams within the next 7 days. It suddenly made our 6 month change program look very glacial. 
Think of a snowball that you start rolling down a snowy hillside, and how it gathers pace and bulk as it moves. This is how small change works. Now think of repairing a car by a committee of people with specialised and disparate skills taking the entire car apart, and then putting it back together again. This is how big change works. In the digital world, only one of these approaches is effective. 
So the next time you encounter a digital transformation initiative, remember: politics, speed, learning, scaling and environmental change are the 5 reasons why it makes sense to commit to big vision but small action. 

Thoughts & Lessons – FT Innovate Conf Day 1

The UK is the most digital economy in the G20, measured as contribution of digital industries to GDP, as per Baroness Shields. But it faces a deficit of 750,000 digitally trained people. There are now 18 tech clusters in the UK – including Cambridge and Edinburgh for example.

Yet, according to Marianna Mazzucato, the UK also has below average R&D spends. Gross & Industrial R&D.

I’m sure that Marianna’s book sales spiked during her great talk, since at least 4 people I spoke with bought her book during her talk. I did too!

I heard the phrase “scale up” as distinct from ‘start up’ – to describe companies looking for global scale from a successful start. I think it’s a really useful phrase to keep in mind.

What is the role of the state? To create the conditions under which new businesses can thrive. What’s the balance between nation state thinking and global, post-national mindsets? As always the answer lies in between. You still need national policies to execute in specific areas such as education and infrastructure. (I’m still thinking about this one).

GPs are supposed to be able to give patients their medical data by 2015, according to PWC, and only about 1% are ready yet. I also think that about 1% of patients are actually ready to receive, and take stewardship of their medical data. 

Who owns data? Such as from Nest, or from your smart fridge? Well, you own the raw data as a user, but I would think if the data is used to create specific insights by combining it with other data and/or analysing using somebody else’s models, then the new ‘cooked’ data generated, also known as the insights or the meaning, should be the property of the provider of that insight. It’s a bit like supplying components to a manufacturer.

I learnt about the fascinating world of the slime mould. This is a one celled organism that can concatenate across multiple cells to create a single large cell like structure, with multiple nucleii. It has no brain, but is able to communicate, self organise and optimise. Given a bunch of oats laid out, the slime mould will go after the food, and then build optimal lines between the food points. This has been used to effectively create transport maps for cities.

Retailers such as the newly merged Dixons Carphone are working at a number of levels to combat the threat of Amazon. This includes creating strong digital propositions, but also improving the existing physical store operations, such as linking bonuses of store staff to customer satisfaction, and rewarding stores for digital sales from their catchment area.

To truly create an innovative culture, the leadership has to demonstrate it themselves. This includes being in the frontline, taking risks, demonstrating fast fail, and taking the responsibility for the fail, if and when it happens, as is demonstrated by Nike’s Mark Parker . This sends out the real message to employees – that it’s okay to take risks and fail occasionally. But this need to be backed by celebrating success and even rewarding failure if it’s really a fast fail – where the clear lessons are learnt and new hypotheses are set up.