Discovery on discovery

Empowering Agile teams to build the right thing

discovery hero image

Client

Royal Dutch Shell, Accenture Interactive.

Role

Research, interviewing, facilitation, testing, public speaking, together with my colleague Kathrin Höfer.

Introduction

As a designer running product discoveries within projects involving Agile teams, I’m familiar with the struggle of squeezing discovery work into a busy Agile environment. The team is always rushing to build and release something, and in this race there is very little time to stop and think about what you are actually building.

When joining the Shell project I was supposed to coordinate the discovery process for all our Agile teams, but I soon realized that the importance of product discovery was not fully perceived by all teams and roles. Additionally, as many teams needed to work on discoveries independently, a need for an improved and shared workflow was perceived.

The challenge

How might we squeeze discovery into our busy Agile workflow?

Interviewing

To analyze the current situation, we gathered insights from our colleagues by running a brainstorm with the full design team, as well as 1 to 1 interviews with team members in other roles.

The 1 to 1 interviews were intended to capture the point of view of different roles when it comes to discovery and its painpoints. Specifically, we spoke with Business Analysts, Solution Architects, Product Owners and Designers.

The results have been mapped on a journey from proposing a new discovery, through its planning, execution and implementation, to the evaluation of its results.

These are what we found to be the biggest obstacles for people when it came to discovery:

  • Not knowing when a discovery is needed

  • Unclarity on roles and lack of involvement

  • Time and effort concerns

  • Lack of a structured workflow

journey map

Best practices

Over the course of this project, we drew inspiration from several articles, books, templates and resources, and here are a few points emerging from this research.

Discovery phases

We organized our discovery sprint phases as described by Tim Herbig. It’s important to note that the process is rarely linear, and it’s likely to involve taking steps back and reiterating.

phases

Discovery phases

We organized our discovery sprint phases as described by Tim Herbig. It’s important to note that the process is rarely linear, and it’s likely to involve taking steps back and reiterating.

The problem space

According to Tim Herbig, “Product Discovery describes the iterative process of reducing uncertainty around a problem or idea to make sure that the right product gets built for the right audience.

The first two phases, alignment and research, pertain to the problem space, and one major takeaway is that discovery should mostly involve spending time around this problem space rather than jumping to solutions.

It’s important to reverse engineer feature requests from stakeholders to get to the root problem. Similarly, we need to dissect user input and painpoints to find out what’s the real need to be solved and only then think about a solution. Rather than falling in love with early solutions, reframing the problem is crucial.

desirability, viability and feasibility

Three lenses

Great products and features happen at the intersection of desirability, viability and feasibility. In other words, a good solution needs to be appealing and useful for the people it addresses, while being profitable or beneficial for the business as well as achievable with the available technologies and a reasonable amount of effort.

Validation

Validation is another important aspect of discovery. As Teresa Torres puts it, “Continuous discovery teams have a regular cadence of customer interviews, rapid prototyping, and experimentation.

Experiments can be formalized and goals or hypotheses can be set quite easily by using an experiment template.

experiment template

Validation

Validation is another important aspect of discovery. As Teresa Torres puts it, “Continuous discovery teams have a regular cadence of customer interviews, rapid prototyping, and experimentation.

Experiments can be formalized and goals or hypotheses can be set quite easily by using an experiment template.

Workshops

Following our research, we ideated on possible solutions and ran workshops, inviting participants from across all Shell app teams and roles in order to get input from different disciplines.

In one of the workshops we presented our research and proposed solutions. After that, we ran a critique session where our participants could evaluate the proposed solutions, add any potential new idea and then vote on both solutions and new ideas.

In another workshop we focused on ideating definitions for discovery and exploring what our roles and the roles of other team members should be.

workshop

Our solutions

As an outcome of the workshops, we decided to focus at first on implementing definitions, a roles checklist and a kickoff workshop template as these were seen as the most valuable improvements.

definition of needed

Definition of Needed

A discovery can be big or small depending on the uncertainties we have and how big they are but, as a rule of thumb, if there are no uncertainties we may not need a discovery at all. Within this context, assumptions and personal opinions need to be considered uncertainties

We came up with a list of questions to go through when evaluating a new idea and assess whether or not you need some extent of discovery work before you start building it.

Roles checklist

Discovery should be a collaborative effort, since every team member can bring some valuable insights and nobody can possibly consider all the perspectives that are needed in order to assess and solve a problem on their own.

Our roles checklist, which was developed collaboratively, is a guideline to start discussing how much time and effort each individual can contribute to the discovery.

roles checklist

Roles checklist

Discovery should be a collaborative effort, since every team member can bring some valuable insights and nobody can possibly consider all the perspectives that are needed in order to assess and solve a problem on their own.

Our roles checklist, which was developed collaboratively, is a guideline to start discussing how much time and effort each individual can contribute to the discovery.

problem framing

Discovery Kickoff workshop step 1

Problem framing

In this first step of our kickoff workshop, the team has the chance to dissect the brief and go deeper to try and find the root problem.

Use tools such as the Abstraction laddering: ask ‘why?’ to analyze the root cause of the challenge on a more abstract level, ask 'how?' to explore sub-problems to solve on a more specific level.

You can then decide to focus on one of the reframed problem statements, and here our tip is to pick a challenge that is as close as possible to the root problem, but can still be solved by your team.

Discovery Kickoff workshop step 2

Mapping knowledge and assumptions

If Discovery is about solving uncertainties, mapping those uncertainties is fundamental to gain alignment and focus on a shared goal.

The second step in the kickoff workshop is a tool called Assumptions smash. With this exercise, you can ask questions to your team or just brainstorm to map current knowledge, gaps and assumptions.

Resist the temptation to work with opinionated assumptions, but plan to validate them by gathering research. Can you point to some evidence to support your statement? If not, then it’s an assumption.

mapping knowledge

Discovery Kickoff workshop step 2

Mapping knowledge and assumptions

If Discovery is about solving uncertainties, mapping those uncertainties is fundamental to gain alignment and focus on a shared goal.

The second step in the kickoff workshop is a tool called Assumptions smash. With this exercise, you can ask questions to your team or just brainstorm to map current knowledge, gaps and assumptions.

Resist the temptation to work with opinionated assumptions, but plan to validate them by gathering research. Can you point to some evidence to support your statement? If not, then it’s an assumption.

plan activities

Discovery Kickoff workshop step 3

Planning activities and pick tools

Based on the uncertainties and assumptions you mapped, the team should pick relevant tools and activities to be able to solve all uncertainties and design a solution. You can do that in the third step of our kickoff workshop, which is about planning your actual discovery work.

The goal here is to select only the activities that are needed to answer your uncertainties (so that you keep the discovery as short as possible) while at the same time making sure all assumptions and uncertainties will be answered. That way that the waste of time and resources is minimized, the effort is reasonable and it can be time-boxed.

At this point, Roles can also be assigned or claimed for each task.

Promoting and scaling

As the solutions we came up with stood out as potentially helpful to other teams outside of the Shell project, we tested our ways of working and templates in several projects within Accenture with a number of different clients, and we’ve iterated based on the feedback received.

We then decided to share our work even outside Accenture and planned a series of activities to do so. For instance, we ran a webcast involving an audience from across the globe, and we recently released our MURAL template publicly and wrote two articles to support it.

Articles and resources

Key takeaways

  • When redesigning ways of working, team members are your users, so interview them, co-create and test the ways of working with them to get their buy-in and design something that solves their painpoints

  • Embrace the discovery mindset: resist the temptation of jumping to solutions and spend more time in the problem space

  • Time-boxing helps being agile and tackling time concerns, but be ready to adjust the course

  • Setting up regular catch ups and an approval moment helps keeping momentum and focus

  • Document all learnings and outcome from each discovery in a report, in case the implementation is going to be picked up in a long time or by another team

You may also like...