You’re never “done” with Product Discovery

At Codurance, Product Discovery - the process of understanding users needs and validating your hypothesis before building products, is a continual practice we embed with all our customers. 

However, there are many misconceptions of Product Discovery - what it is, when to do it and even why to bother. 

We attempted to answer these questions and many others at a recent in person panel event held at our London HQ and featuring our Co-Founder and Head of Product Mash Badar, our Principal Product Manager Rachel Lyons, plus Sarah Timms Product Leadership & Coaching Expert and David Heath Head of Profession for Software Engineering, UK Government Digital Service.

Here you can watch the full recording of A Whole Team Approach to Effective Product Discovery: Panel Discussion 

In this article we share some key learnings and takeaways shared by our panel of experts that will hopefully provide some helpful insights and best practices for your next product development project. 

  • Having clear goals and KPIs with the whole team aligned behind them (across all roles within the product development lifecycle, not just someone with a “Product” title) is critical for successful Product Discovery and to avoid conflict on the direction of travel.

  • Ensure you interact with your users first-hand to get regular feedback. Embed any third party design agencies into your team so you co-create all user interviews together. Once the agency leaves, you’ll want to be able to have ownership of your user feedback, not the other way around so ensure they work with you, not in a silo.

  • Measure, measure, measure! Use metrics to measure the impact of your product development - across the entire product lifecycle. Align economic variables such revenues, profits, cost of delay, with product and productivity metrics. For example, measure the user adoption of a particular feature, and the impact it has on your business, to focus on the features that matter and stop doing the things that don’t achieve these KPIs you have put in place.

  • According to research, 80% of features built are never used by users. Therefore release early and fail fast so that you work more on the features that move the needle - fight to release any tiny change that gives value to the customer.

  • Always validate your hypothesis through continual feedback - you must always act on the feedback; if you were wrong, move on and try something else. 

  • Engage customers as early as possible in the lifecycle to see how they engage with your product. Don’t run the risk of leaving it too late - you don’t want to risk building something that no-one actually wants. 

  • Move fast, think like a startup, and get stuff done. The faster you move, you’ll be less likely to be told what to build and your team will be more motivated. Busy teams are more harmonious. 

  • Do discovery and delivery continuously together so it becomes your day to day - often described as Dual Track Agile. Remove the silos between discovery and delivery, endeavour to integrate that into one team.

  • User Stories are a “promise of a conversation”. Do not rely on them as the main channel for communicating user needs / features. Having full representation of various roles during discovery means that you will have reams of descriptions in the User Stories. Do not use them as “the place where product handover features to delivery”.

  • Try to avoid working in silos if at all possible; cross-functional teams facilitate a cohesive strategy where each person contributes to the goals and commits to the holistic picture.

  • Consider utilising the Four Big Risks Framework to help you consider what could go wrong, before moving ahead to actually develop a feature. The four risks are: Value risk (users won't buy or want to use it), Usability risk (users won't be able to use it), Feasibility risk (it will be harder to build than thought), and Business Viability risk (it will not fit with our overall business model). 

To conclude, Product Discovery is never complete - you’re never “done”. Instead it should be a continuous process where you’re always questioning, always asking why?

To measure your effectiveness at product discovery, book Codurance’s Product Development Maturity Assessment