Did we kill the Disco?
What has happened to the Discovery phase and what can we do?
Last week I attended the brilliant un-conference Product for the People. It was a chance for me to get a couple of things off my chest that I’ve been ruminating on for a while.
Product for the People is for product folks in and around public sector in the UK so my question in this space was directly related to the Discovery phase of the GDS lifecycle. To my surprise (and partial horror!) the topic was popular and with a sea of faces looking back at me I posed my question: “Did we kill the Disco?”
What is Discovery?
I’m potentially going to be a bit controversial here and boil down all the wonderful writings about Discovery down to 3 base questions:
- Its there a problem to solve?
- Can we solve it?
- Should we solve it?
Discovery came about as a way to get user needs front and centre, the problem to solve, of any project that progresses. It also looks at how you might solve the problem including any ‘gotchas’ you could potentially face, technically or otherwise. Finally it looks at if you should solve it, is it financially viable, does it make sense at this time to use the public purse on ‘this’ thing. This happens with a lean team who can find out just enough to answer those questions and make a go/no decision on progressing to the next stag. In theory they are inexpensive, short, pieces of work that help you understand the value, or not, of the idea you have.
There are lots of nuances in this of course and I’ve taken the liberty of a generalised view because fundamentally I believe you can approach any/all Discoveries this way while flexing and adapting to the type of ‘Thing’ you are working on.
All of this was to stop or reduce the number of large expensive projects that get spun up with a full team only to find out months or years down the line that it can’t be achieved. Which, as we can all agree was a terrible use of the public purse.
I used to love “Disco’s”, you get to chat to all sorts of interesting people, get to be nosey about what’s going on around and about and get to make a really valuable decision. Brilliant.
Over the past year or so though I’ve noticed that I dread Discoveries more and more and stakeholders seem more and more disillusioned with them. I’ve been trying to organise some thoughts and consider why this might be. Then, spurred on by this post on LinkedIn from Paul I thought I’d start getting them written down.
Some worrying trends.
Over the past couple of years I’ve noticed a couple of trends that worry me in relation to the Discovery phase.
12 weeks and other ‘rules’.
I’ve heard worrying things like ‘A Discovery is 12 weeks’, ‘these are the outputs you have to have’ or ‘these are the Discovery roles’, non of which are are strictly true, at best they are misinterpretations of what the guides says at worse they don’t appear in the guides at all.
Discovery takes as long as Discovery takes. Sometimes you can gather what you need in a couple of weeks. Other times the problem may be so gnarly and so complex that you need longer to cover enough ground to make an informed decision.
We need to find our way back to this mindset. The guides from GDS are just that. For Discovery it’s suggested that 8–12 weeks is about right, but this isn’t a rule, it’s just asking you to consider that if it’s taking 12+ weeks then maybe it’s 2 Discoveries? Or maybe it’s not, but use your judgement.
You can’t do that in [this] phase.
This is something that worries me at all phases really, the idea that there is a defined ‘output’ of any phase. There are ‘outcomes’ suggested but not outputs. If you need to do a thing to help you get to the outcome, then do it (within reason!).
Everyone is different and comes to understanding in a different way. I am a very visual thinker so I often (to the despair of the designers and/or engineers) cobble together some wireframes/pseudo code/architecture diagrams. They help me think about and then articulate whatever complex thing we’re looking into.
Start. Stop. Delay. Start.
Another thing that worries me is a trend (and this may not be new I may just not have noticed it before) for having a team complete a Discovery and suggest steps for Alpha only for the suggestions to go on a shelf, the team move on and an entirely new team is asked to pick up the Alpha months later
There’s so much more that happens when a team forms and works on something together than you can ever put in a report. The collective memory the team holds is an immeasurable unit of value that the future team won’t have and will need to build for themselves. It also brings some pretty big risks around if the outcome is still valid, are the stakeholders still the same and if they are the same will the appreciate repeating conversations a year later?
I am certain this latter point is a big part of why stakeholders are increasingly skeptical of Discoveries. Their time is usually precious, so to invest time and energy engaging with a team one month, see nothing for a year and then have to repeat yourself must be disillusioning. It also makes it incredibly hard for the incoming Product Manager to successfully engage that stakeholder, something I can definitely attest to.
It’s far more efficient for the team involved, and for the budget, to have the team who completed the Discovery roll straight onto the Alpha. The team may then shuffle around as you bring in other roles as the projects progresses, but you will have some continuity. This continuity enormously increases your chance of success and your ability to get and retain buy in from stakeholders.
It’s a linear process.
There are two ways that this assumed linear path is ‘imposed’. There is the starting of Discovery start with Alpha already scheduled in, like a foregone conclusion. If that’s the case and you're so certain the Alpha will happen then why do the Discovery? I’m being flippant, you do need a Discovery but you can’t assume it will conclude in moving to Alpha.
The other ‘linear process’ problem is when a team that’s working in another phase, particularly Beta, stumbles upon a problem not previously understood. Sometimes in a technical team a spike ticket will do the trick and can just roll on through the teams work. Other times it’s a much bigger piece of work and actually needs a Discovery to understand it.
I’ve seen this situation turn into all kinds of chaos and declarations such as ‘we did Discovery already’, ‘we’ve passed the assessment so don’t need to do Discovery again’ or the horror of ‘we reassigned the User Researchers because….’
I’m here to say that Discovery can happen AT ANY TIME it’s needed.
Also, YOU NEED USER RESEARCH ALWAYS.
Conclusions.
I think I could go on, but I do want to try and wrap this up for now before I write a book of grumbles. I think my conclusions are:
- Let Discovery be what it should be and not a tick box exercise, do what you need to do to get to an outcome
- Aim for continuity
- Know that Discovery can and should happen through the life of a product
I would love to know peoples thoughts on this. Am I dooming? Do I have it all wrong? Does anyone else see the same patterns? Does anyone have the answer.
