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
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.
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.
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.
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.
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
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
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.
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.
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.
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