You know the story, your team has been beavering away for months on a new product release. Marketing and PR are on board, the execs are excited, the team is pumped… but low and behold it’s a flop. Customers respond negatively (or not at all), sales dip and front-line teams get hit with cranky feedback from users.
Avoiding this scenario starts with making sure you are building the right thing. And the secret sauce behind this is Product Discovery.
Understanding the why
Product Discovery has been around for a while, in the form of Jobs to be done, Lean start up and Design Sprints just to name a few. But it was really Lean StartUp’s focus on entrepreneurship, the need for evidence and understanding the ‘why’ that was the catalyst for modern product development. Teams need to have a deeper understanding of the problems they are trying to solve before they focus on working the best way to address the problem at scale. Product management is not just about delivery speed, it’s also about learning speed.
As a Product Coach, I regularly see the need to incorporate more discovery into the product development because teams have skipped discovery and are solely focused on delivering new features. The benefits of product discovery are multi-layered but for teams it becomes a lot easier to stay focused on smarter delivery if they have been involved in understanding the why (and why not) of what you are building.
Eliminating the guess-work
Product Discovery really does take the guessing out (and a lot of the opinions) by providing the process to generate evidence in which to make good decisions. Here are some ways to include product discovery into your product development process.
Small bits of research
Get the team into the habit of regularly talking to users so they can directly see the context of how users interact with and experience your product or service. Regularly seeking out fresh learnings and insights means the team continually learns and iterates at speed. The team may use different research methods depending on what they are trying to learn but the point is it should be small research activities that generate sounds and actionable insights.
Week after week
The core discovery team should aim to speak with users each sprint cycle or at least every 2 weeks, with everyone else in the team getting involved for at least 2hrs every 6 weeks. Discovery or build to learn opportunities as we like to call them, should be added to the product backlog just like user stories are. They are typically represented as hypothesis statements and ready for the team to work start working out how to address the problem before investing in development at scale.
By the team building the product
Typically a Product Manager, Design Lead and Technical Lead will form a mini discovery team. If you have a small team, then having everyone focused on discovery activities before moving onto delivery steps can improve the quality of the decisions the team are making. It’s important that team members not involved directly in discovery activities can participate in playback sessions where they can ask questions and understand what was learnt.
Capture the thinking and progress along the way
Critical thinking is hard but an essential skill for teams doing product discovery. By visualising each step, it’s easier for the team to connect the dots between insights and their product decisions. Product Kata Framework by Melissa Perri is a systematic ways to capture evidence and decisions. This technique is a great way of showing progress and helps keep the team focused on the desired outcome.
Frequently share learnings with stakeholders
Showing and discussing your findings helps decision makers or stakeholders better understand and even builds empathy with your product’s users. The aim is to tell a story from the users’ perspective. Explaining how the team has been involved in the discovery activities demonstrates an evidenced-based approach to what’s working and what’s not and help inform the next move.
Rinse and repeat!