The Case for Uncertainty
Marcus Kirsch
Helping organisations to de-risk transformation projects, team processes and services on a local or portfolio and C-level. Director, Fractional CxO, Clients: EY, NHS, BT, HSBC, WPP, Nissan, etc.: hello-twc.youcanbook.me
The theme of this year's Service Design Fringe Festival in London was Uncertainty. Many people believe that we live in uncertain times. I am wondering if a lot of this fear of uncertainty stems from us not understanding the nature and characteristics of the new systems that are shaping every aspect of our lives. I believe that uncertainty will be a default element in everything we are trying to solve from here on. So we need to get used to it with a new mindset and processes.
We exist in an ever-growing market of wicked problems. Wicked problems always include some aspect of uncertainty. One reason for this is that wicked problems are defined by a lack of information needed to create a solution at the start of the project. Another one is the fact that wicked problems have a habit of evolving while one is working on them. A third one is that applying the solution will further affect the problem in the future. This effect is often delayed so that it can be a huge uncertainty factor.
Therefore I think, that to feel more comfortable or safe with this new level of complexity, we need to establish a mindset and processes, that organically include uncertainty on an everyday basis.
How does Service Design as a new practice or Design Thinking as an older mindset contribute to that? How could other practices help achieve it? Could they offer us the right direction and language to make this uncertainty more bearable, maybe even enjoyable as an everyday opportunity?
There are about three aspects of an organisational or business ambition, that contain elements of uncertainty:
Business (Viability) - The business benefit of any effort tends always has uncertainties. It is not only the question if a project can create any benefit, but I would argue that how it can create benefit is often unclear unless options are tested and evaluated. For example, would a service run on a subscription model or a free model with bought upgrades? Is the value created through single-user use or community and network effects? Adoption and usage and its value perception is a wicked problem because it includes customer growing up and getting used to an offer and evolving with it. Sometimes it is the difference between 1,000 or 1 million people using it. Different sizes can have exponentially different behaviours appear in a system. Sometimes it turns out the customers want the peripheral services first.
To tackle these wicked characteristics, testing and experimenting with different models should be part of the scope. This means that a project needs to be able to pivot. Would your organisation be ready for that?
Tame companies start with a fixed idea of how benefits are created. They often have a fixed idea who the target customer is. Tame companies have no chance to be competitive like this.
Service Design has an in-built principle to treat everything as a hypothesis. This means that everything will be validated. If not real, it will affect either the problem scope that the project needs to tackle or it will significantly amend possible solutions. This research into the problem areas is where service design most often collide with organisations. The tamer they are the more they already think they know the problem. This contradictory behaviour sounds especially extreme, given that service design is often brought in, when previous activities have failed or damaged the company, proving that the current approach is flawed at best. All this shows is that a tame organisation, can not even buy into new capabilities unless it has started investing in a new mindset and processes that support them.
Customer (Desirability) – People change. People don't say what they want. Given that everything that happened since the 90s in terms of customer behaviour was largely ignored by many companies, organisations need to spend years of strategic leapfrogging, to catch up with reality. Very few do. Fewer had dug back into their organisational essence and re-invented themselves for a new world. This brings enormous uncertainty to many industries. This explains the rise of startups that serve customers. The new customer behaviours and expectations have not just changed what people want from a product; it has them asking for services that wrap the product and expanded into more significant customer problem-solving expectations. This has inherently changed the relationship between organisation and customer. There is a new contract that requires a re-assessment of trust and emotional engagement between the two parties.
This shift has created considerable uncertainty in the way an organisation's tone-of-voice and communications need to be considered. The inside and cause of an organisation are starting to matter differently. The way a customer expects you to know him or she has changed. Time and level of engagement are different. And all these factors quantitatively contribute to success.
It is easy to label this all as CX or customer experience and think that the problem will be solved as soon as the experience is re-designed. As AirBnB's head of designs said, "it is a journey". Whenever you introduce something new to the experience and solve a problem, a new one pops up. Service Design, just like Agile, has iterative principles built-in. I would be curious to know about any case-studies that have researched beyond the initial level of customer needs. Service Design currently has the most comprehensive set of tools to research customer needs and is in a state of further evolving those.
I tame companies can stop doing the necessary fixes on their experiences, but expand into building a pipeline of aspects they want to understand better about their customers; they would become wicked companies and start seeing the return of investment they are failing to get as a tame company.
Capabilities (Feasibility) – Can we do it? Can we learn something that we don't know yet? Buying tech or people are not building capabilities. Workshops and training tend not to resemble the day-to-day workspace the skills are used in. Do you have the right team, that can get the skills it needs to do the job? Are the skills you are learning on the job the right ones? I learned one or multiple new skills with every project I ever did. It is a skill by itself to assess what it might require to deliver a solution. Today we can google the globe to find what we need.
Procurement is probably one of the tamest silos existing in the business. In my experience, it has more prevented than enabled opportunities and wasted a tremendous amount of budget to make it harder to do easy things. For every project, there are probably about 1,000 ways to execute them. If your capabilities are not flexible or agile enough, then uncertainty can't be tackled easily. At the same time, if you are getting used to learning new ways of doing things continuously, it will become less uncertain to assess if a new skill or tool will work.
This is where startups and their MVPs can teach us a lesson. And this is where the learnings of constant research in service design should inspire us to apply the same principle everywhere.
There is a reason I used business, customer and capabilities as a trifactor as desirability, viability and feasibility are the DVF assessment that every design thinker is using to assess what is worth doing, what should be done and what can be done.
The next time you meet a service designer and think all they care about is the customer, ask them about DVF.
The next time your organisation looks like it could not go anywhere, consider that embracing uncertainty will become more comfortable if you consider some of the above.
1) Be able to adjust and question the problem you think you are solving.
2) Expand on getting to know your customer through an ever-expanding lens.
3) Know that constant learning needs to be part of that process.
I am curious to hear if you had similar insights and case studies that came across these principles or some form of them.
Exciting times ahead!
Check out my book for a first step into the above: https://amzn.to/2moB4qI
Design Thinker | Business Architect | Developmental Coach | Storyteller & Speaker
5 年Thanks for a great article. I can particularly relate to the bottlenecks that can limit an organisation to being 'tame'. Adding a little more depth to your procurement example, I have seen a past CIO attemp to transition delivery from waterfall to agile and at the same time implement a fixed price contract procurement policy for vendors at the same time. Agile is about inspecting and adapting and collaboration over contracts and a fixed price contract does exactly the opposite.