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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s