At GDS we work through four stages when we design and build services. Discovery is where you explore the problems you are going to solve. Alpha is where you prototype solutions that might work. Beta is where you take what works and turn it into a product with real users. Live is where you run the product for real.
Of these four stages, discovery is always the hardest to do well. Why?
The state of discovery today
We all know deep down that doing a proper discovery is important. You know those projects where you worked your arse off but had that creeping feeling throughout that you were doing the wrong thing? That's why it's important. Yes, it saves money and stuff as well, but deep down it's important to us not to waste our lives.
We also know that doing a proper discovery is surprisingly easy. At least if you compare this to building a product. It doesn't take very long. You don't need many people. And it's not technically difficult because you're not building anything.
Yet teams mangle discoveries. Discoveries are too short. Discoveries start without a user researcher. Discoveries dive straight into prototyping. Discoveries don't keep the human and technological aspects separate. Discoveries fail to highlight the most important of user needs which are screamingly apparent in their absence during later stages. Some discoveries simply never happen.
If it's important and easy to do, why is it so hard to do discovery well? I think it's because discovery is about leadership. And leadership can be terrifying.
Management versus leadership
Brief digression. Peter Drucker has a great quote about leadership.
'Management is doing things right; leadership is doing the right things'
I used to laugh at my old boss for drawing a distinction between management and leadership (sorry DJ!) but this quote makes me regret being so precocious. Peter Drucker's distinction is helpful in thinking about discovery. Here's why.
In the alpha, beta and live stages you are mostly concerned with doing things right. Your user research is about checking whether your solution works with the people who will use it and fixing problems that come up.
This is management territory.
People feel safe in management territory. The overall direction is set. It's relatively predictable where things are going. You think you know how much money you'll spend. And you dream you have some idea of how long things will take. This is familiar ground. This is normal work. This is business as usual. This is how the civil service mostly operates. It manages things that exist. It tries to do them right.
But discovery is different. Here you are concerned with doing the right things. You're hunting around for the right problems to tackle rather than coming up with solutions. Your user research is about digging into people's needs, tasks, motivations and goals rather than finding problems with your design. And you end up having to take a punt on a future direction. A informed gamble, but still a gamble.
This is leadership territory.
Many people don't feel safe in leadership territory. It can be terrifying for all involved:
- user researchers can be more comfortable finding problems with something that exists than making a bet on what to build.
- software teams can be more comfortable making things for the future rather than finding out how things are today.
- senior managers can be more comfortable planning in advance so they can allocate budget and people and resources.
- politicians can be more comfortable creating policies based on their political realities than working out what the constraints are.
This is why discovery is hard. It's not because the work is hard to do. It's because discovery is about leadership and this scares people. And when we're all scared, we're pretty good at silently conspiring to avoid the thing that scares us.
This has changed how I think about doing better discoveries.
It's not about describing the discovery work more clearly (although that helps). It's not about convincing people of the value of discovery (although we could do with more ammunition). And it's not about doing service assessments at the discovery stage (although it would be good to know that all projects at least had a discovery stage!).
Instead, if discovery scares people (it does) then we need to find ways to make a safe space for discoveries to happen. People produce better work when they are not scared. We need to stop putting pressure on discovery teams to validate pre-existing decisions. We need advocates for discovery at a senior level - not people that do the work but the people that set the right conditions - and this is one of the driving reasons behind creating lead user researchers on our programmes at GDS.
And if discovery is about leadership (it is) we need to start giving our most important discovery projects to our best leaders and teams. Too often we start discoveries with a cobbled-together team and only put a 'proper' team together for alpha and beta. We need to stop this because we are setting these teams up to fail at discovery. We need to wait for the right people to be ready to start discovery together. A few weeks here versus a couple of years of wasted effort further down the line. What's the rush?
In the end, discovery is hard because it's about leading our organisations into new futures that are not mapped out in advance. This is scary and it needs good leadership. But better discoveries lead to a better us. And we're worth it.
I wrote this post inspired by Ben Holliday's recent blog output. The question of why discovery is hard has been on my mind a lot in the last year, but these ideas are not fully formed so (as always) I welcome critique and questions at @myddelton.
- @mattedgar (who wrote good things about the culture of discovery) pointed out that we should continue to ask 'are we building the right thing?' through alpha and beta too. I have simplified here to make a point. But he is (of course) right.
- @jukesie reminded me that he wrote this post about decoding discovery which is well worth a read too.