Setting up a discovery to succeed with a small team

Starting a discovery isn’t easy because you’re going into the unknown. If you’re not careful you can dive into the discovery work before you’ve properly set yourself up. This can lead to people heading off in different directions and wasting precious time.

I learned this on a discovery earlier this year. We were looking at whether GDS could do something to help service teams collect information from their users. It took us two and a half weeks to set our team up properly. This was much longer than I expected.

Let me talk you through what I learned about setting up a discovery.

Choose the right goal

For years I thought that the goal of a discovery was to explore a problem. So I asked our team to explore the problem of “how do services without access to a development team collect information from their users?”.

We went around in circles for two weeks. We couldn’t get a grip on what we were aiming to achieve. We didn’t know what work to do. Eventually my colleague Pete Herlihy suggested we had the wrong type of goal. Discovery isn’t about exploring a problem, he said, it’s about making a decision about what to do next.

We reframed our goal in terms of making a decision. “Decide if there is an opportunity for GDS to help services without access to development teams start collecting information from their users online”. We included why GDS was funding our discovery.

This focused our work. It grounded us in our organisational context. I worried this would feel too restrictive, but overnight we started talking about the problems we needed to explore to make that decision. Not every single problem we could imagine.

We should have started with a goal framed in terms of making a decision. We should have done this before the project kicked off.

Run an inception workshop

A couple of days after we’d set our new goal we took the whole team to the park, sat under a tree, and ran an inception workshop.

For 90 minutes we talked about our goal and how to achieve it. What did we need to know to make a decision? As we talked, we wrote post-its for each topic that came up and sorted them into these categories:

Goals (things we wanted to achieve)
Reckons (things we thought we already knew)
Stuff to find out (things we wished we knew)
Rabbit holes (things that would lead to lots of wasted time)
Scope (things we’d do, things we wouldn’t do)
This is not (things that seemed related but weren’t part of this)
Icebox for alpha (ideas for later)

The conversation went all over the place. From users to technology to policy to data to cost savings. Discussions about whether something was a reckon or something to find out, whether something was in or out of scope. Everyone contributed.

There was something magic about having a free-flowing conversation that turned into a bunch of structured notes as we talked. Try this for yourself.

Set “discovery is done when” objectives

We took the notes from the inception workshop and turned these into 20 outcome-focused objectives. Here’s our list of ‘discovery is done when’ objectives:

We understand types of users for end users and service teams
We understand problems end-users have with paper forms
We understand problems service teams have with paper forms
We understand when/where end-users need paper forms
We understand when/where service teams need paper forms
We understand the appetite for process change in service teams
We understand how paper forms are created/updated
We have a picture of the range of complexity across paper forms
We know what proportion of paper forms require evidence
We know the different types of supporting evidence
We understand why signatures are required on paper forms
We have a list of important design patterns used in paper forms
We have a list of important fields/data types used in paper forms
We understand how information collected gets into databases
We understand error rates and their impact on data quality
We understand how and why departments are using form builders
We understand commercial form builders and their benefits/costs
We have a cost model for paper forms
We have an estimate of the number of paper forms in government
We have a prioritised list of alphas, including benefits/costs

Look at this process. We started with a simple team conversation about our goal, and ended with a list of outcome-focused objectives. A list that described where we needed to get to without telling us what we had to do. Perfect for a self-organising team to pick up and run with.

This is my secret to setting up a discovery. Take a clear goal, discuss it as a team, and agree “discovery is done when” objectives.

Divide up the work

We divided our work into four areas of investigation in keeping with the discovery block diagram. This worked surprisingly well. We split the 20 objectives into four areas led by four different people:

Users and their needs - user researcher (objectives 1-6)
Content and design - service designer (objectives 7-12)
Data and technology - technical architect (objectives 13-17)
Cost models - delivery manager (objectives 18-20)

The team worried this meant going off in four different directions. That’s not how we worked. We did things together, whether visiting service teams, analysing data, documenting designs or coming up with cost models. Discovery is a team sport.

Why divide the work then? It made it clear who in the team was responsible for each of the 20 objectives. When we got into the barely-controlled madness of discovering things it was useful to have this to keep us on track. We knew we needed good enough answers to all 20 objectives rather than perfect answers for a few of them.

This gave each person space to develop their own way of telling the story of their bit of the discovery. It preserved the diversity of viewpoints that we brought to the work as individuals. Each of us ended up owning a major slice of the story.

Plan the work against the time you have

Finally, we planned the work. We mapped the 10 weeks down the left hand side, the 4 areas of investigation across the top, and the activities on post-its in the middle.

We didn’t expect to stick to this plan. Instead, we used it to come face-to-face with how little time we had. It’s easy to underestimate the time you have available to do things. This leads to avoidable compromises at the end.

Here’s what we ended up planning:

Weeks 1-2: form as a team, work out goals, and plan the work we’re going to do
Weeks 3-8: do the exploratory work to answer the objectives
Week 9: bring together everything we learn into clear findings
Week 10: come up with alphas and present our work to decision makers

After realising that we had only 6 weeks to do the investigative work, we were able to make better decisions about how many interviews to do, how many services to visit, and how many different systems to assess. You always have less time than you think.

Sit back and watch the team go

Setting up in this way meant that the whole team knew what we were trying to do, and without being told how to do it. This shared understanding about direction is what enables a team to perform as more than the sum of its parts. Watching the team go off and do the work was one of the most amazing experiences of my working life.

This is now my standard advice to teams who are setting up discoveries:

Choose the right goal
Run an inception workshop
Set “discovery is done when” objectives
Divide up the work
Plan the work against the time you have

One final word of warning. This works because it’s a shared process which involves the whole team. The critical ingredient for setting up better discoveries is making sure that the whole team is ready to start on day one. That’s (much) harder than it sounds.

This post is one of three posts about how to run better discoveries. The other two are better discoveries with the discovery block diagram and finishing off a discovery to do justice to your work. Let me know what you think on @myddelton.