A Discovery, and its activities, allows an organisation the chance to explore a problem space in more detail. Typically, this is to identify new product or market opportunities that may deliver customer value and rapidly test these opportunities for their effectiveness. For those new to the process, particularly those of us who don’t come from an Experience Design background, Discovery can appear as an amorphous beast, with no easy connection between the activities and the broader process. Participants are often drawn from across an organisation, and most will have limited, if any, experience of the process. Being a developer, my first experience in Discoveries was as a prototyper, brought in to build and test promising ideas. However, I quickly learned that there is no one-size-fits-all pattern; what, when, or even if, I would be prototyping was also to be discovered, and as such, I would need to participate in unfamiliar activities to support an unfamiliar process.
The short time periods in which Discoveries are conducted mean that there is limited time to familiarise everybody with the process before we hit the ground running. This article aims to help those diving into Discovery by delving into its purpose and its process. It considers who comprises a Discovery project team, draws a broad overview of the process and key stages, and offers some advice for success, as well as highlighting some warning signs for when things may veer off course.
Organisations conduct Discoveries to understand customer needs and to reduce uncertainty and risk. Ideally, these should be regular events in a product life-cycle to allow organisations to rapidly recognise and adapt to changing needs.
Organisations may not know much about their customers’ needs. They may wrongly assume that they know many things about their customers’ needs. They may understand their customers’ needs, but not how they compare to each other. Or they may know all of this, but still be working off out of date knowledge.
By emphasising customer-centred activities, e.g. user research, collaborative design and user feedback, Discoveries ensure that we learn directly from customers. This enables a rich understanding of the problems customers face, what their priorities are, and a vision of product ideas that may solve their most important issues.
An organisation may see an immediate business problem to solve with many potential solutions and implementations. Choosing one solution from the field without understanding its value to customers is likely to result in a long journey in the wrong direction before the mistake is realised.
Discovery activities seek to reduce uncertainty through research, synthesis and high-value, low-cost experiments. Experiments reveal not only the viability of solutions, but also provide further insights and opportunities for experimentation. By conducting Discoveries and testing ideas early with those people who primarily determine success or failure (i.e. customers), organisations help to mitigate the impact of failure.
A Discovery project team is a mix of people, with some members managing the process and coordinating activities, some from the organisation, and others brought in for specific skills such as research.
From the organisation, a diverse set of people from the front-line, those who directly engage with customers - or customers themselves - and those with experience in the domain are highly desirable. They bring a wealth of knowledge, direct experience and ideas. Business sponsors in the team provide very fast feedback loops and help to ensure that the project follows the stated goals. They often advocate for the work, drawing on customer insights learned through their participation in research and activities. Additionally, because Discoveries are conducted in very short time periods, securing somebody who can get the right people in the right places at short notice is essential.
Generally, being in a project team, you are expected to park your job at the door. This has two meanings: firstly, in the team you should be engaged in planning and execution of activities (day to day work while sitting next to the team is not really being part of the team), and secondly, you need to recognise and put aside preconceptions which constrain your thinking and limit your ability to empathise with customers. Be critical, but avoid being opinionated, and be open to a different perspective. For developers, Discoveries also serve to remind us that the systems we design and build are human-centred; what we consider as logical approaches don’t necessarily align with the changing expectations of complex, varied, lovely, human behaviour. We get the opportunity to test our assumptions and modify our patterns to meet customer needs.
The Discovery process aims to transition from a business or customer problem through to one or more potential solutions.
Through research and cycles of design and testing, Discoveries transition from problems to potential solutions.
I have called out the set of stages in this process as Define, Research, Analyse, Design and Test, each stage having different activities and outputs. Stages can often run in parallel, as new discoveries feed back into the process; it is very likely that some parts of the team will continue research while experiments are being conducted.
At the beginning of the Discovery, the project team should take the opportunity to clearly define the problem, the project goals and measures of project success.
It is likely that a problem will have been decided beforehand, but that doesn’t necessarily mean that it’s the right problem to solve. Early stages of a Discovery provide the chance to identify any concerns and possibly redefine the problem and scope.
Defining the scope directs our customer research, our design and our experiments. If the project goals aren't understood early on, it is difficult to structure research properly and to decide which insights are valuable. Ultimately the team may waste people's time with the wrong questions and struggle to deliver a good outcome.
The project team conducts research to understand the problem space in more depth. They draw information from multiple sources such as customer and subject matter expert interviews, call centre data and survey data, with the goal of understanding how customers engage with existing services, and where they supplement or replace with their own systems and workarounds.
Research findings drive customer insights and are the foundation for the rest of the Discovery. Without research, the team is working off gut feel, with no evidence to support them. It should be noted however, that having research data doesn’t mean that stakeholders will agree with it. If they do not, recognise the experience that they bring; start with an assumption that they are correct and question how the data can be explained given their understanding. It may be that the research was not broad enough, or they may have access to information you don’t, which will provide new avenues for research and opportunities for greater insights.
Having stakeholders involved in research, particularly interviews, keeps them engaged and gives them personal insights regarding their customers. This will make them stronger advocates for the work, enabling them to draw from their own experiences when they talk about it.
Having conducted research, the team needs to share their research findings with each other in order to make sense of it. Generally this involves a large space and plenty of post-it notes. The data is synthesised with common themes drawn out and opportunities for further research highlighted.
Identifying the patterns in the research allows the team to see common trends and gives a sense of the significance of issues; for example, where multiple customers are being blocked from achieving their goals. Business stakeholders and customers should be used to validate any patterns that emerge, explore them in more depth and to identify further opportunities for research.
Armed with an understanding of the key problems customers face, the set of customer insights are prioritised with the project team, business stakeholders and ideally, customers. Activities such as impact versus value mapping and group voting can be effective techniques and help to direct the team towards solving those problems which have the most cost.
Starting from the highest priority problems, the team conducts workshops to generate and explore potential ideas. Participants for these workshops should be drawn from a varied set of backgrounds in order to produce a breadth of ideas. It’s critical that participants are aware that their role is purely to be part of a mass of idea generation. Framing the problems as ‘how might we?’ statements can help participants to focus on solutions. A candidate set of ideas will be selected as potential for experimentation based upon those which target the highest priority problem, offer high value insights and are low cost to test.
Until ideas are tested, their effectiveness is only theoretical. The project team would not want to offer solutions that turn out to be useless once delivered. To test ideas, the team designs experiments and a set of measures. Usually this will involve generating a hypothesis and determining the smallest experiment possible to prove or disprove it. As a result, experiments may vary from as simple as a drawing on a card to a functioning prototype. After testing, ideas may be thrown out and new ideas or changes to existing ideas generated. Additionally, further research insights and avenues to pursue may emerge and should be followed.
The results of successful experiments will potentially form part of the solution.
Read any provided documentation and agree upon a candidate set of activities for the project. The activities may change, but a general idea before entering the project will help. When the project begins, the full team should run through the process, activities, and role expectations.
Stakeholders help define the project goals, provide business context and prioritise which insights to target first. Senior stakeholders should be identified up front and engaged early. Ideally, they should be present throughout the project, but in particular at regular showcases to ensure that they are engaged with the work and able to champion the project.
Project goals set the bounds of the project work and define what success is. They should be driven by the business and measurable. A single-sentence mission statement, summarising the goals, displayed at a highly visible space is an effective tool to remind everybody what the team is working towards.
Customer insights carry more weight and stories are more compelling when told by somebody who was actually there. Push for the whole team and stakeholders to be there, particularly for qualitative research. This will strengthen stakeholder engagement and advocacy.
Customer insights lead to great ideas, but when prioritising and selecting for experimentation, the team should make sure that the idea maps to one of the project goals. If not, then the experiment or the goals need to be reviewed.
Get as many people designing as you can. Idea generation is most effective with a large number of people from a broad set of backgrounds. Engage subject matter experts, business stakeholders, the full project team and customers in the design process.
The team will regularly refer to previous research and insights during discussions, showcases and when communicating with stakeholders, so outcomes and insights from activities should be shared, documented and made visible to everybody as soon as possible. Ensure that everything is preserved so that it can be easily found after the project has finished.
The team may get a sense that something is wrong in the project, but not have a clear idea how to manage it. Without a defined leader, these problems may remain unresolved and given the limited amount of time, if not dealt with early, they may significantly impact upon the project. If there isn’t a clear leader in the project the team should stop and choose one immediately.
Subject matter experts may be assigned to the project team who have limited experience in the organisation. The insights they provide may be poor and you will likely need to validate some of them with additional sources.
Project success is contingent on senior stakeholder engagement. Minimal engagement, such as only at showcases, will likely cause course corrections and wasted work. Sending people as fill-ins is of limited value, particularly if they have no clout and no context.
If you are well into a project and you haven’t met the senior stakeholders, you should assume that the project is in trouble. Push for them to be there more frequently, make sure they understand the risk to the project, but be accommodating: keep them in the loop, and if they can’t make it to showcases, offer to walk them through it.
If people in the team have different opinions of scope, it may be because the goals are wrong or not defined enough. Good stakeholder representation in a project should help to identify this, as stakeholders are likely to call out when the goals don’t match their expectations.
If the goals seem to be wrong, validate with a senior stakeholder and, if needed, get the right people in the room to redefine them.
Ideas need to come from a variety of backgrounds. When there isn’t enough diversity in the room, or there are too few people in sessions, the ideas will be similar or scarce, respectively. This should be raised as a project risk, as the result may be very few potential solutions at the end of the project.
The problem being considered may also be difficult to solve in the current scope of the project. In this case it may be worth re-prioritising the problems and selecting a new one.
Discovery requires research drawn from both quantitative and qualitative sources. Without direct access to customers, the team may be limited to analysing existing quantitative data and subject matter expert opinions.
Discoveries cannot be run without talking to customers. If there is no access available, it should be raised as a major project risk, as there will be no way to know if insights are real and if ideas are valuable to customers. If there is limited access, bringing stakeholders along to customer interviews is critical in order to highlight how valuable these insights are, and motivate them to find ways to get the team more access.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.