Validating the technology, design, and features of a new product is a substantial initiative, so to ensure a return on the investment thoughtbot has developed a sound process which we call Discovery Sprints. We brought together a dream team of thoughtbot Product Managers, Designers & Developers to share with you their experiences facilitating Discovery Sprints to help you lead your own efforts.
Read on for the key takeaways from the discussion.
What are the biggest ways discovery sprints save you time and money (in a single sentence)?
- Figuring out what matters.
- Validated prototype, aligned team and stakeholders, clear go-to-market (GTM) strategy
- Helps you save the money you would have spent building the wrong thing.
How does thoughtbot define Discovery work?
- It combines technical, design and product strategy to determine what architecture exists or is needed, allowing you to assess risk, and get user validation before jumping in.
- Discovery Sprints are more customised and flexible than regular Product Design Sprints. They can vary in scope and length and enable a lot of upfront, real-time validation to make sure an idea is sound.
What outcomes can you expect from Discovery work?
- Validation of your idea through rapid prototyping and documented user testing.
- Uncover and user-test assumptions to reduce risk: assumptions become a clear yes/no.
- Align stakeholders and team around a common goal.
- A prioritised MVP roadmap for the next 6 months to a year, with estimated risk-managed stories.
- Uncovered business insight that goes beyond the product
Are all Discovery Sprints the same?
- Not at all: they are customised to the needs and requirements of a project.
- The focus can pivot to be more heavily on the strategy, development, or design side, depending on the client’s needs. For example, an early stage company will focus on product validation, proving if the idea has market fit, while a more established business might focus on digitising an existing validated business model.
When does it make sense to do a Discovery Sprint? What use cases are good candidates?
- It makes sense to invest time into a Discovery sprint if you are looking to create a risk-assessed, validated roadmap with estimated features.
- Projects very early into the ideation cycle, as it will help you validate the idea, and align key business metrics and stakeholders.
- Whenever project requirements are ambiguous, a Discovery Sprint can align the stakeholders around a concrete plan.
What are common Discovery work mistakes and how do you avoid them?
- One trap that’s really easy to fall into is assuming your idea is the best. Discovery Sprint “understand” exercises can uncover assumptions for testing with real users.
- Adopting the idea from the person that speaks the loudest or has the strongest opinion can be problematic. You can use prioritization exercises to draw input from everyone who’s participating and prioritize the best solution.
- You also need to involve the main stakeholder and decision maker in the room or you’ll get a lot of good ideas but not a lot of action.
- Not thinking of features holistically is a big mistake from a technical perspective, and thinking either too big or too small: there’s a sweet spot in the middle between sharing all your long term ideas and limiting focus to just the MVP.
How does Discovery work inform technical choices?
- Part of the process is discovering the constraints on a project, e.g. time, budget, integrations, these all impact technical strategy
- Having the space for upfront technical discovery allows you to confirm that what you want to build is actually possible with the tools being considered.
- Especially for clients who are building custom software for the first time, it can help surface ideas of varying scale and provide clarity into the level of effort in development. We start getting them comfortable talking about size of features and importance of prioritization in a roadmap
How does Discovery work inform a product roadmap?
- By getting upfront validation of assumptions through user-tested prototypes, you know if you’re heading in the right direction, which is invaluable.
- It helps identify that minimum experience you need to deliver the value you want. A combination of business, technical and user conversations come together to inform the prioritization criteria with the client in real time.
What happens to a client who skips Discovery work?
- They can end up burning time and money by going in the wrong direction.
- The worst case is if you just jumped in on a two-year long software build without doing Discovery work. It might work great technically, but then you discover that your users don’t connect with it. So you have to spend another 18 months and blow the budget rebuilding it. We’re trying to avoid that.
- Working on unvalidated features also demoralizes the product team, because they don’t believe in them. We’ve found a team feels best when working on user-validated products that have a clear, tested strategy.
Get in touch if you want to learn more about Discovery sprints or discuss a potential project.
To stay up to speed on future thoughtbot events subscribe to our blog or follow us on social media. We would love to hear what events and content you find helpful.
