Having empathy for your stakeholders can mean many things. In our case, it meant taking something highly complex and making it look easy.
Along the way, we realised there was a connection between learning to engage consortium members and learning to read philosophy.
Take Heidegger for example.
Learning to read Heidegger is like learning to chew cement. Heidegger forces you to take something that looks impossible and break it down, one concept at a time. Anyone familiar with an ‘unseen’ Latin translation knows this feeling. Faced with something impenetrable, you use your will power to chew it down into digestible pieces. You then test your understanding by knowing how these pieces interconnect and by being able to talk about them succinctly, in your own words.
When you’ve done this a sufficient number of times, you get addicted. It’s not the complexity you’re addicted to; it’s the feeling of ‘breakthrough’. You become addicted to the process of demystification.
With the first type, effort and time are involved. You are responsible for pushing through and figuring out what this ‘thing’ is and what it means.
The second type happens when a complex picture is simplified for you in a clear and intuitive way. Suddenly, it all makes sense and you didn’t need to hunt for an answer.
The difference between the two is subtle. When something is demystified for you, the fact that it was complex in the first place disappears quickly. When this is done well, your brain absorbs the content easily and hardly registers that demystification has taken place.
Our job is to help clients understand what is going on, while we’re still very much in the process of building the thing that we want to launch. This is called demystifying the process of product creation.
For a single client, this can be done through the standard ceremonies: iteration planning meetings, showcases, retros and the like. But when your client represents a consortium of large industry players, there are problems of scale, structure and divergent interests, which make the process unwieldy.
Some industry players are too big and too busy to get involved in the day-to-day decisions that shape a product over time. Last year, we faced exactly this scenario and learnt a few things along the way.
What we were building had never been done before at this scale. As a world first, the platform involved a high degree of technical and organisational complexity. Part of our job was to demystify the process of onboarding consortium members. We had to onboard them in such a way that their confidence in the solution - and in our partnership - would not be threatened by this complexity.
Each consortium member has a particular locus of control (what they can individually do to implement the common vision). At the same time, we found that members were just as interested in what each other were doing to support the vision.
Over the initial 16 weeks of customer onboarding, certain patterns began to emerge. The better we could demystify the product creation process, the happier our customers became. There were four things we did to simplify the experience and help us to launch on time.
1. Creating DACs: the plan before the plan
The first step was to build a catalogue of open decisions, each of which needed further conversation for us to move forward. Unlike capturing established decisions in a RAID log, this exercise was about anticipating unmade decisions.
An unmade decision is a ‘DAC’: decision awaiting closure. With each DAC, we would follow the steps below. The following example relates to Single-Sign On:
Our catalogue of DACs provided the skeleton for an operational readiness checklist, which we then tailored to each customer.
2. ‘It’s not just a repo’
Once we had defined the onboarding plan for each customer, we then needed to communicate it in a simple way that made the process feel easy and straightforward.
The trap here is to throw everything into a repository. Never expect your customers to go through every document carefully and dutifully. And be wary of creating highly annotated Confluence pages, which make them feel like they’re in labyrinth of hyperlinks.
The customer onboarding process needs to be treated with the same love and attention that we would give to user experience. We avoided jungles of information by using a clear and intuitive content hierarchy, structured beneath a group of coloured buttons on an inviting homepage dashboard.
It’s not just about having all your knowledge and information in one place. The experience of accessing that knowledge needs to be usable and useful.
3. Your backlog is apolitical
When you engage multiple industry players in a consortium, it’s not easy to capture what everyone wants. The end user wants one thing, while their counterpart in another member organisation needs something else. Organisations that are both customers of and investors in the platform have a different perspective from just customers. And your client - who is building the whole thing with you - has its own needs.
If we were to run the project again, we would find an elegant way to keep track of these needs, beyond the creation of user stories that feed into product backlogs. Simply ‘adding something to the backlog’ can strip away crucial details related to organisational preferences and politics. During our project, some of the most important ‘corridor conversations’ could not be easily translated into feature requests.
So, what’s required is a way of capturing the various levels at which needs arise, and then ensuring that we have an adequate forum for digesting these needs and understanding their impact on the project.
To do this, we recommend the following steps:
4. Get a sink strainer
When you are washing potatoes in the kitchen sink, all manner of things can get sucked down the drain: soil, potato peelings, your wedding ring. But if you have a sink strainer, you can catch all these items, even if some are more valuable than others.
When dealing with multiple enterprise customers, having a ‘sink strainer mindset’ is crucial. At a consortium level, the number of inputs that can get lost down the drain grows exponentially.
We needed to show our customers that we were capturing their inputs and acting on them, not merely writing them down to be forgotten in a notebook that we never opened again.
Having a ‘sink strainer mindset’ doesn’t just mean being able to capture all inputs. It also means being able to triage them in a way that makes consortium members feel empowered and shows them they are co-creating the product with us.
We found benefit in the following steps:
That experience can become confusing when our client and customers aren’t entirely sure what’s going on and are left to demystify the process by themselves.
Our job is to make things look easy. The shared experience becomes calm and straightforward when it’s demystified for them. Like Fred Astaire used to say, ‘if it doesn’t look easy, you’re not working hard enough’.
Along the way, we realised there was a connection between learning to engage consortium members and learning to read philosophy.
Take Heidegger for example.
Learning to read Heidegger is like learning to chew cement. Heidegger forces you to take something that looks impossible and break it down, one concept at a time. Anyone familiar with an ‘unseen’ Latin translation knows this feeling. Faced with something impenetrable, you use your will power to chew it down into digestible pieces. You then test your understanding by knowing how these pieces interconnect and by being able to talk about them succinctly, in your own words.
When you’ve done this a sufficient number of times, you get addicted. It’s not the complexity you’re addicted to; it’s the feeling of ‘breakthrough’. You become addicted to the process of demystification.
Two types of demystification
There are two types of demystification. The first is when something is demystified by you. The second is when something is demystified for you.With the first type, effort and time are involved. You are responsible for pushing through and figuring out what this ‘thing’ is and what it means.
The second type happens when a complex picture is simplified for you in a clear and intuitive way. Suddenly, it all makes sense and you didn’t need to hunt for an answer.
The difference between the two is subtle. When something is demystified for you, the fact that it was complex in the first place disappears quickly. When this is done well, your brain absorbs the content easily and hardly registers that demystification has taken place.
Demystifying the process of product creation
Demystification is extremely important for those of us who build software. It’s related to the quality of our client communication and how we tell the story of what we’re doing, while we’re doing it.Our job is to help clients understand what is going on, while we’re still very much in the process of building the thing that we want to launch. This is called demystifying the process of product creation.
For a single client, this can be done through the standard ceremonies: iteration planning meetings, showcases, retros and the like. But when your client represents a consortium of large industry players, there are problems of scale, structure and divergent interests, which make the process unwieldy.
Some industry players are too big and too busy to get involved in the day-to-day decisions that shape a product over time. Last year, we faced exactly this scenario and learnt a few things along the way.
Our task
Last year, we were tasked with onboarding five global companies onto a platform that would go live within four months. At a high level, the companies understood what the platform was supposed to do. However, this wasn’t just a cutting-edge platform with new capabilities. This was a disruptive industry-wide transformation that required organisations to integrate their systems, re-engineer their processes and understand what everyone else was doing.What we were building had never been done before at this scale. As a world first, the platform involved a high degree of technical and organisational complexity. Part of our job was to demystify the process of onboarding consortium members. We had to onboard them in such a way that their confidence in the solution - and in our partnership - would not be threatened by this complexity.
Four lessons
In Latin, the word consortium derives from con (meaning ‘with’) and sors (meaning ‘fate’). Organisations that join a consortium are partnering under a common vision and sharing the fate of that partnership.Each consortium member has a particular locus of control (what they can individually do to implement the common vision). At the same time, we found that members were just as interested in what each other were doing to support the vision.
Over the initial 16 weeks of customer onboarding, certain patterns began to emerge. The better we could demystify the product creation process, the happier our customers became. There were four things we did to simplify the experience and help us to launch on time.
1. Creating DACs: the plan before the plan
The first step was to build a catalogue of open decisions, each of which needed further conversation for us to move forward. Unlike capturing established decisions in a RAID log, this exercise was about anticipating unmade decisions.
An unmade decision is a ‘DAC’: decision awaiting closure. With each DAC, we would follow the steps below. The following example relates to Single-Sign On:
Our catalogue of DACs provided the skeleton for an operational readiness checklist, which we then tailored to each customer.
2. ‘It’s not just a repo’
Once we had defined the onboarding plan for each customer, we then needed to communicate it in a simple way that made the process feel easy and straightforward.
The trap here is to throw everything into a repository. Never expect your customers to go through every document carefully and dutifully. And be wary of creating highly annotated Confluence pages, which make them feel like they’re in labyrinth of hyperlinks.
The customer onboarding process needs to be treated with the same love and attention that we would give to user experience. We avoided jungles of information by using a clear and intuitive content hierarchy, structured beneath a group of coloured buttons on an inviting homepage dashboard.
It’s not just about having all your knowledge and information in one place. The experience of accessing that knowledge needs to be usable and useful.
3. Your backlog is apolitical
When you engage multiple industry players in a consortium, it’s not easy to capture what everyone wants. The end user wants one thing, while their counterpart in another member organisation needs something else. Organisations that are both customers of and investors in the platform have a different perspective from just customers. And your client - who is building the whole thing with you - has its own needs.
If we were to run the project again, we would find an elegant way to keep track of these needs, beyond the creation of user stories that feed into product backlogs. Simply ‘adding something to the backlog’ can strip away crucial details related to organisational preferences and politics. During our project, some of the most important ‘corridor conversations’ could not be easily translated into feature requests.
So, what’s required is a way of capturing the various levels at which needs arise, and then ensuring that we have an adequate forum for digesting these needs and understanding their impact on the project.
To do this, we recommend the following steps:
4. Get a sink strainer
When you are washing potatoes in the kitchen sink, all manner of things can get sucked down the drain: soil, potato peelings, your wedding ring. But if you have a sink strainer, you can catch all these items, even if some are more valuable than others.
When dealing with multiple enterprise customers, having a ‘sink strainer mindset’ is crucial. At a consortium level, the number of inputs that can get lost down the drain grows exponentially.
We needed to show our customers that we were capturing their inputs and acting on them, not merely writing them down to be forgotten in a notebook that we never opened again.
Having a ‘sink strainer mindset’ doesn’t just mean being able to capture all inputs. It also means being able to triage them in a way that makes consortium members feel empowered and shows them they are co-creating the product with us.
We found benefit in the following steps:
Make things look easy
The technology we build for clients isn’t just a means to an end. The way we get to the ‘thing’ we want to launch represents - in itself - a mode of shared experience.That experience can become confusing when our client and customers aren’t entirely sure what’s going on and are left to demystify the process by themselves.
Our job is to make things look easy. The shared experience becomes calm and straightforward when it’s demystified for them. Like Fred Astaire used to say, ‘if it doesn’t look easy, you’re not working hard enough’.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
