In the delivery of a digital service, a discovery is a short period right at the beginning of the project to determine what the problem is and whether it is worth solving. Discoveries should be short, usually no more than a few weeks and should seek to provide just enough confidence to proceed or not. Discoveries are intense and its important that they focus on the right things to help the team progress. Below are some tactics I use when in Discovery mode.
Make sure the team have a clear problem.
Discoveries generally fall into two shapes:
- We want to explore why a thing is happening?
- We think this tech/process/3rd party tool will help us solve a problem.
Most teams would prefer to be presented with the first type, be given a problem to explore, unfortunately its still prevalent that digital teams are engaged when a ‘digital system’ is already identified for a given problem. As a result teams can end up spending lots of time digging into the problem space and understanding needs when all thats wanted is to deliver the solution. It can also be the case that solutions are proposed without a good understanding of needs, in which case be explicit about this, form the potential solution as a hypothesis to test. Being clear about the sort of things you want to learn is absolutely imperative to success.
There is a 3rd shape, the “We know there is work to be done in this space but we’re not really aligned or clear what it is, or what expectations there are.” This happens more often than you might think, especially in organisations with large stakeholder groups. The need for something results in funding being agreed, but alignment on what the problem is to be solved isn’t there. These can be the most tricky types of discovery to deliver. In my experience its best to be upfront about the lack of clarity and to put people at ease that its ok, and that we’ll use the process to define the problem to be solved as an output of the work.
Bringing stakeholders in to the discovery process and allowing them to see the ways of working that lead to the decisions can be really effective for these types of disco’s. You get a lot more buy in to the process and establish a lot of trust if done right, it requires a LOT of engagement and communication so be sure you factor that in to whats achievable in the time you have available.
Depending on the level of trust you have with stakeholders (and that they have between them) it may be worth considering doing some prep work before introducing the wider team. Leaders may not wish to be seen as not having the answers and so giving them space to be vulnerable before throwing them in with a team may be worthwhile.
Do the prep work.
A discovery should be just enough time to validate the problem is worth solving, to verify this it will be necessary to talk to end user’s (either current or potential) and stakeholders about their pain points, ideas, hopes and fears for the project. Getting time in people’s diaries can be challenging so its worth having a good sense of who needs to be involved and blocking out their time before commissioning a team to start, this will set them up for success and help the team build momentum. If you’re discovery team is made up of lots of external folks, make sure you have at least one person from inside the org who knows how to get things done to help them keep momentum.
Keep the team small.
Because discoveries are short intensive periods, its important to make feedback looks as short as possible. One way to achieve this is to limit the lines of communication with the team. A team of only has 6 lines of communications, as the team grows, this number increases exponentially, a standard team of 7 has 21 lines of communication.
Smaller teams means its important that team members wear ‘many hats’ i.e. they take responsibility for many roles. Because discoveries are research intensive you usually what people with the following skillsets:
- User Research (to discover user needs)
- Service Design (to map the service ecosystem, pain points and potential user journey)
- Product Management (to ask the ‘is this worth doing’ questions)
- Technical (to ask the ‘is this even possible to solve with tech’ questions)
Other skillsets sets such as Delivery Management, Interaction and Content Design, Business Analysis may be needed in discovery. Ideally your core team should be experienced enough to bridge all of these gaps, but if you are working with a junior team, it may be necessary to trade off team size for speed.
Identify your supporters and collaborators.
I’ve already used the term stakeholders in this post but I’m not a massive fan of the name, stakeholders implies someone who sits aloof from the work holding the team ‘to account’ whilst never getting close to the problem space. When setting off on a project I prefer to use the ‘Supporters’ and ‘Collaborators’ these people are here to help the team be successful and have ‘skin in the game’ in making the discovery a success, the small change in naming much closer reflects how most ‘stakeholders’ feel about projects in my experience, and it helps set an expectation that we’re doing this work with not to people. Emily Webber’s Team Onion is an excellent tool to help identify who these people are as a team exercise.
Establishing a Discovery Mindset.
It’s important that you do discoveries, with a learning mindset, its all about taking the time to listen and learn about the challenges and issues your users have, to have idea’s about what could help, but to not be wedded to them, your ideas will be wrong! Mace and Menter do a really excellent set of Discovery cards you can use with the team or stakeholders to help establish good ways of thinking and working together.
It’s important to go into discoveries in ‘optimism mode’ the time to pick apart ideas and play devil’s advocate will come in alpha and beyond. Read this excellent post by Dean Vipond about the dangers of “Devil’s advocates” in discovery phases.
Know what ‘just enough’ looks like.
It’s easy to get drawn into ‘analysis paralysis’ in discovery, I’ve seen some discoveries run for over a year! It’s important to acknowledge that you can’t know all the things by the end of the phase, you should be seeking just enough knowledge that there is a thing worth pursuing.
The aim is to stop working on things early if there’s not enough evidence of benefit (I need to write a post on treating projects like cattle not pets). Knowing all the things up-front is the very definition of a waterfall project, if you need to break the problem down more (i.e you have confidence in some things but not others by end of disco), consider slicing the problem, and moving some work into prototype/build and others into the next phase of disco.
It’s ok to keep discovering in later phases.
Matt Edgar put this much more eloquently than I could, so read his post. Discovery is a culture not a phase, nevertheless it’s worth remembering that the high intensity pace of a discovery isn’t sustainable over the long term, be mindful of this or you’ll burn your team out.
What tactics do you consistently use when approaching discoveries?