How To Make Product Discovery An Integral Part Of Your Scrum Team?
We define product discovery as the proactive behavior of teams to discover new valuable features through experiments, field testing, and research. Often, the insights from these kinds of proactive behaviors lead to more valuable features and avoid unnecessary work. Although research shows that these activities are useful in any Scrum team, we also recognize that teams usually start with this as they become more experienced with Scrum.
So, to what extent does your team actively and continuously discover what it is that users need? That’s a question many teams find difficult to answer. Or, they can answer it, but the answer is they find it difficult to determine. That’s why we created the do-it-yourself workshops. All of the workshops we’ve included in this blog post include a step-by-step approach to use them and help you move in the right direction.
The workshops and experiments are:
- Generate Insights And Ideas For Your Product With “Design The Box”
- Create An Empathy Map To Articulate Your Customer’s Understanding
- Explore The State Of Your Product And Market Conditions
- Discover The Needs Of Your Stakeholders With UX Fishbowl
- Use Ecocycle Planning To Make The State Of Your Product Transparent
- Create Product Strategies Together With Stakeholders
- Determine What Is Valuable With Your Team And Stakeholders
In this blog post, we offer you a short description of these workshops. We hope it inspires you to give them a try. Once you’ve used them, let us know the results, let’s learn and grow, together!
Imagine walking through a supermarket. Hundreds of products are vying for your attention. Often, the only thing you can actually see is the packaging, not the product itself. Unless you know exactly what you need, the packaging is an important part of what draws us to purchase a product. What kind of story does it tell? What benefits does it emphasize? What kind of visuals are used to convince you? What about fonts or the name of the product? How is it described in the packaging?
‘Design The Box’ is a fun, creative exercise to help Scrum teams step into the shoes of their users. Instead of brainstorming the product itself, we instead brainstorm the packaging. What would the box look like? How would it convince potential users? ‘Design The Box’ is a great exercise for idea generation. It helps teams make decisions and choices about features and other aspects of their vision that are otherwise more difficult to articulate. But it also works as a refresher of the user’s perspective when development has been underway for a while.
This variation of ‘Design The Box’ is a simplified version of the one presented in ‘Gamestorming’ by Dave Gray and Sunni Brown.
Building awesome products requires a deep, emphatic understanding of your users. What do they need? What drives them? How do they experience a particular product or process? In this experiment, we explain how to use Empathy Maps and interview users to build this understanding.
Empathy Maps are a simple, powerful tool to build an understanding of your users. It is no wonder that they are the nuts and bolts of UX designers and are commonly used in Design Thinking. The name derives from ‘Empathy’, which refers to the ability to understand what another person feels and thinks. A search on Google yields many different templates, but we find the one by Dave Gray the most practical and complete.
You can create one Empathy Map for all users or multiple maps for different segments or individual users. In any case, the best Empathy Maps are based on real data. Not on conjectures or assumptions that you make as a team. This means that a good Empathy Map requires that we go out there and talk with real users.
The better a Scrum team understands its stakeholders and their product, the more likely they are to build the right things. Otherwise, they may end up wasting a lot of time and money on problems that stakeholders don’t have. This concern for stakeholders is determined by the quality of Sprint Reviews, the amount of collaboration with stakeholders, a strong focus on valuable outcomes, and product discovery.
In order to achieve this, Scrum teams shouldn’t only focus on the product they’re building. Together with their stakeholders, they should also pay attention to the market circumstances and the consequences for the product. What is happening in our field of work? What are our users saying? What are competitors building?
The purpose of this workshop is to invite Scrum teams and their stakeholders to focus on the bigger picture. What is happening outside your organization and how does this influence the product your team is developing?
Give this workshop a try during the next Sprint Review!
When has your Scrum team talked with the stakeholders about the product they’re building? With stakeholders, we don’t mean people with an opinion about the product, but someone that really uses (or will use) it frequently. Or someone that invested significantly in the development of the product and will personally benefit from the challenge your product addresses.
In short, a stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them the product succeeds.
In our work with Scrum teams, we’ve noticed that many of them don’t frequently interact with their real stakeholders. Sure, they occasionally host a Sprint Review but are the attendee’s stakeholders, or just people with an opinion about the product? There are various reasons why they don’t frequently interact with stakeholders. It could be that Scrum teams don’t know who their real stakeholders are, or they don’t know *how* to involve them.
It’s important to frequently engage with your stakeholders. You need their experiences, ideas, and feedback to learn what to build next. Maybe, while using an early version of the product, an important new insight emerged that impacts the roadmap and Product Backlog. Or changed circumstances in the market require a quick release of a specific feature. You’ll only discover this when you closely collaborate with your stakeholders.
If you recognize this situation and want to improve it, consider giving this do-it-yourself workshop a try. For example, during the Sprint Review. You’ll use the Liberating Structure UX Fishbowl to actively listen to your stakeholders and together gain new ideas, insights, and improvements.
Whenever you’re in the middle of developing a product, it’s easy to lose sight of what really matters. Are we spending time on the features that provide the most value? Which features do we need to creatively reinvent or expand in order to move our product forward? What are things we should focus on in the upcoming period?
It’s important to continuously discuss these questions together with your stakeholders. Especially, due to the complex nature of software development, more is unknown than known. No matter how much time you spend with your stakeholders at the start, you’ll always gain new ideas while developing the product. This goes for both the team *and* stakeholders. So it’s important to have a close collaboration and share ideas, insights, and assumptions.
With this workshop, you make the current state of your product transparent, inspect what this means, and identify improvements to give product development a boost. Ideally, you run this workshop together with your stakeholders. For example, during the Sprint Review.
The exercise is built on the powerful Liberating Structure Ecocycle Planning. Ecocycle Planning can look overwhelming, but just give it a try and let the structure do the heavy lifting.
There is little point to Scrum when you don’t involve stakeholders. Yet, many Scrum teams struggle to involve their stakeholders, and that makes this one of the core symptoms of Zombie Scrum. For some, involving one or two internal stakeholders seems to be enough. For others, stakeholders can only be involved when the entire product is done. But without their feedback, how can you be sure that what you’re building is the right thing?
We designed this workshop to help you clarify the success criteria of the product and what the Scrum team and its stakeholders can do to support that success.
With this workshop, you become familiar with the Liberating Structures ‘Nine Whys to clarify the purpose of the product, ‘Critical Uncertainties’ to develop product strategies, ‘1–2–4-ALL’ to define activities for the robust and hedging strategies, and ‘15% Solutions’ to identify personal next steps.
The Scrum framework exists to deliver value to stakeholders sooner. Sounds good, right? But when is something “valuable”? For something that seems so central to Scrum, there is little guidance on what “value” means. And that easily leads to Zombie Scrum, where teams are incredibly busy with work that is of no value and no consequence.
This experiment exists to start a conversation around “value” with your team and its stakeholders. You can embed this into a regular Sprint Planning, a Sprint Review, or a Sprint Retrospective. Or even as a separate workshop.
Product discovery is the proactive behavior of teams to discover new valuable features through experiments, field testing, and research. The insights from these kinds of proactive behaviors can lead to more valuable features and avoid unnecessary work. To help Scrum teams improve product discovery for their team, we created a bunch of do-it-yourself workshops. If you tried the workshops, let us know how they went. Your thoughts, ideas, and experiences are invaluable to us. Only together, we can create even more valuable content, and unleash the superpowers of Scrum teams, all around the world!