How to kick-off Discovery Sprints, reframe a problem and align your team
Empower Agile teams to build the right thing.
In my job as Product & Service Designer at the experience agency Accenture Interactive, I'm working on new product and service innovations for our clients. In some projects I can dedicate several weeks for user research, iterating on a value proposition and test the user interface. However, most project teams are working in an agile process with very limited time to spend on product discovery, which requires the team to work as efficient as possible to still deliver high quality results.
That’s why my colleague Marcello Tanzi and I went on a journey to empower our agile teams to run smoother product discoveries and build the right thing. In these two articles we’ll tell you what we did and how you can apply our tools within your teams, too.
In this article I’l be sharing with you our ways of working to start and run a discovery sprint, which activities to do in the different discovery phases and give you some tips on how to achieve the best results.
Why should we run discoveries?
Discovery sprints create a shared understanding of the problem to solve and validate the core value proposition. Product innovation teams can use this knowledge to make informed decisions on what to build next. It requires a mindset which is open to the unknown, open to recognise the uncertainty around a problem or idea and willing to explore it instead of making opinionated assumptions. While quick time-to-launch can surely be beneficial to a business, taking an idea straight into development requires certainty that it is going to fit the market. Discoveries may take up some time and effort to run, but they will reduce the risk of designing a product or service that either users don’t need, that we can not technically implement or is not viable for our business.
If you are interested in reading more about how to recognize when you need a discovery and how to prioritize and scope discoveries, then please check out the article my colleague Marcello wrote. Discovery Sprints — What they are and why you should run them. It is explaining the definition and benefits of a discovery sprint, which team roles can contribute to it and how they can best overcome some of the challenges around it.
Discovery Kick-off workshop
On the 1st day of discovery it is crucial to align the entire team on the challenge or value proposition to discover and plan which activities each team member will conduct to find answers to the unknowns. We highly recommend a kick-off workshop to let the team hit the ground running. When gathering the team we should ensure that everyone is on the same page. The existing product and all relevant flows should be presented and all problems around the UX, technology or business value should be listed. Ideally, we have a business representative who can answer some questions around why the topic was chosen and what exactly the briefing entails.
🚀 Run the workshop yourself with our free MURAL template of the Discovery Sprint Kick-off workshop!
Reframe the initial problem
In the first step of the kick-off, the team can dissect the brief and analyze the root problem from 3 lenses (desirability/feasibility/viability) to better understand the different issues related to the briefing. Use the tool ‘Abstraction laddering’ to ask 'why?' and 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.
Mapping existing knowledge and assumptions
Flagging assumptions and knowledge gaps is fundamental to a discovery. Use the tool ‘Assumption Smash’ to map out what you do already know as a fact and what you do not know yet. Again these assumptions can be about the user, business or technology. Resist the temptation to go with opinionated assumptions, but plan to validate them by gathering evidence in research experiments. Cluster and vote on the most important and impactful things to focus on during this discovery sprint.
Plan activities and pick tools
First, think about which activities are useful to do in each phase of the discovery, pick just-enough to reach your objectives. Secondly, time-box all of them on a shared sprint plan. Decide who will do what and how to collaborate accross roles. Add important milestone meetings, sprint ceremonies and deadlines into the plan. Revisit this planning frequently to track progress and eventually adjust it.
Phases of a Discovery Sprint
The following phases of a discovery sprint were adapted from Tim Herbig. They can be helpful to structure activities, but do not necessarily need to be followed in a linear process.
Alignment phase
In the first phase the team will share existing knowledge and clarify the most important cornerstones of the discovery — what the product context is, its boundaries, how it fits into the overall strategy and how to measure success. Defining the discovery goal and the problem will ensure that the whole team is on the same page.
Research phase
Answering uncertainties and assumptions around the problem and goal with user and desk research, technical investigation and business analysis. Either starting to understand your users or updating the existing knowledge on them. This phase typically includes the gathering and interpretation of qualitative and quantitative data.
Ideation phase
Based on what you’ve found out about your user’s needs, it’s time to diverge and generate many creative solutions to pursue. We recommend to facilitate ideation sessions with a diverse group to build up on each others concepts.
Creation phase
Ideas are worth nothing if you can’t turn them into tangible products or features. You need to converge from many to one idea and define it more in detail. This phase typically involves lots of prototyping — either in low-fidelity to proof the general concept, or high fidelity to test detailed interactions with end users.
Validation phase
To validate your solutions, you need to get creative in order to get optimal results with investing minimal effort. Categorise your validation experiments into testing the desirability, feasibility or viability. You should also think about ways to avoid biases in the experiments. You might be able to test your prototype through qualitative interviews, or maybe you also need to work with a Concierge or Wizard of Oz Test that demonstrate the product’s capabilities.
Pre-refinement phase
While it’s fun to cycle through different variations of your prototype, you need to put things into order for the transition into delivery. This typically means incorporating the latest user feedback changes, slicing down the concept and maybe even starting to plan the first set of product releases.
How to get best results from a discovery sprint?
Embrace the discovery mindset
Resist the temptation to design your product based on assumptions, but spend most of the discovery time on researching the problem. Be prepared that your findings might differ from what you expected and accept the fact that you’ll have to pivot whenever needed. In the most drastic scenario we should even consider to stop the idea from getting build when there is a lack of user desirability, feasibility difficulties or business value.
Test it in the context of use
Discoveries can not be successful in isolation, we need to get out there and test our assumptions in the real context of the product or service. Through user research and prototype testing we can explore the needs and pain-points directly and gather evidence that we will add value when building this solution for the users.
Think about the entire user journey
Especially in short discovery cycles in which the team focuses on a specific problem or feature, it is important to think holistically about how this feature is embedded in the larger ecosystem. How is it impacting other experiences in the user journey? How will it evolve regarding the long term business strategy?
Work across team silos
Collaborating across roles not only lets us get things done faster, we also check upon each other’s work from multiple perspectives. We need to avoid working in silos where we notice too late that a design is not feasible or a solution is not interesting to users. Therefore we should schedule regular or ad-hoc catch-ups to trigger communication, share our progress and align on next steps.
Document all learnings and outcomes
At the end of a discovery sprint we want to transition the work smoothly to the delivery team. Therefore we should write a report on everything that has been done and found out. This report can also be shared with executive level stakeholders to get their buy-in. A formal approval should document all decisions taken, so they can be referred to in future. We recommend going through the Definition of Done checklist below to ensure the team has fully reached their discovery goals.
🚀And by the way, all the tools I’ve mentioned here are included in our Discovery Kickoff Workshop Template for MURAL, which is free for you to use.
References & further reading about discovery sprints
I’m a Product & Service Designer focussed on user research, UX design and prototyping of meaningful experiences. Currently based in Amsterdam, part of the design team at Accenture Interactive NL.
Hopefully you found this post interesting! Please feel free to share your feedback and thoughts with me, and let's connect on LinkedIn.
