Before you commit to building a service, you need to understand the problem that needs to be solved. To do this you’re likely to have some form of discovery.
A discovery is a user-centric way of understanding a problem. It helps us recognise constraints and the policy or strategic intent behind our work. It should also find ways to share learnings. Sounds sensible enough, so why can it often be difficult?
When a discovery doesn’t go to ‘plan’
A discovery phase doesn’t always go the way you expect. Here are some of the challenges you may have come across.
When you start asking questions, it’s common to find your problem is much bigger and far more complex than you first anticipated. You can end up with more questions than answers and react by doing more discovery – the disco death spiral. And this leads to discovery getting a bad reputation of being a never-ending activity and can cause projects to stall.
The cost of a discovery can also be hard to justify. There’s often no ‘thing’ delivered at the end of it and the outcome can be perceived as ‘telling me what I already know’. You might be even less popular with the sponsor if your discovery finds that their problem is not worth solving!
So how can you avoid a discovery that’s never done – or never delivers value? The answer is to recognise the type of discovery you’re facing and be prepared to bend some rules.
Breaking rule 1: You should understand the user’s whole context
The Service Manual is guidance from the Government Digital Service on how to deliver effective public services. It reminds us to set a clear goal for our discovery. It also urges us to understand the user’s wider context which is likely to span other services and even offline interactions.
It’s tempting to pull all the threads and get drawn deeper across different teams or departments. This takes time, and often those other teams and departments won’t fully understand their piece of the puzzle either.
Instead of trying to understand everything about your users and their context, set a limit on how much you need to know and accept that you won’t understand everything straight away. You might have to make the uncomfortable decision to intentionally not talk to some users or leave out sections of a user journey.
Limit your discovery to understanding the parts of the problem that you will have the power to solve, the biggest pains or the most valuable parts of a journey – that’s where you can deliver real value!
An example of where we’ve done this on a live project was making the difficult call to exclude submission authors from our discovery into new software for processing policy submissions. Instead we just focused on what happens once a completed submission lands on a Private Secretary’s desk.
On paper, this left a gap in our knowledge of the problem. But crucially it kept us focused on the area that we could influence. This helped us build confidence with the client, get to the build phase sooner and get something useful into the hands of users as quickly as possible.
And remember, once you’ve demonstrated tangible progress it can be easier to get approval for another focused discovery into the next part of a problem.
Breaking rule 2: You shouldn’t start building your service in discovery
It’s common to be tasked with a discovery when a solution has already been chosen. The Service Manual warns us that we might be presented with a pre-defined solution or told to build a specific thing.
We’re trained to step back, reframe the problem and ask ‘why?’ as much as possible. This can lead to frustration if the solution isn’t a good fit for all of the user needs. If the solution has buy-in and funding, it can be painful to try and change direction, putting a strain on relationships. So tread with caution. In this scenario, instead of pushing back it could be a good idea to lean in and use your discovery time to do a little building to validate what the predetermined solution can do.
Let me give another example. We were once asked to run a discovery for a compliance monitoring solution where the sponsor had already decided they wanted a dashboard to visualise performance metrics. Rather than trying to understand if a dashboard was the right thing, we used some of our 4 week discovery time to build a prototype. This allowed us to test assumptions on how well a dashboard solved the problem and play with different technology. This also meant we had working software to move forward into Alpha, saving time and keeping up momentum.
Don’t be afraid to adapt the process
While these are just a couple of examples, I hope they show how shaking up the rules can sometimes be the right thing to do. This phase of a project can have a poor reputation and taking a fresh approach can get clients on board with the idea of discovery again.
So the next time you’re planning a discovery, take a moment to adapt your approach to the environment and don’t be afraid to bend the rules a little bit to get the most out of your disco time.
Interested in what else the team has to say on digital service delivery? Take a look at our latest posts.
About the Author
David Weston
Lead Delivery Manager
A consultant with Made Tech since 2021, David works primarily in central government and healthcare. David specialises in early stage delivery from Discovery to rapidly iterating new services. David has a background in delivering tech solutions for non-profits.
