In the past three months, I have been putting the continuous discovery principles into practice, which is strongly influenced by Teresa Torres's insightful book, [Continuous Discovery Habits](https://www.amazon.co.uk/Continuous-Discovery-Habits-Discover-Products/dp/1736633309). Had I been able to apply the lessons earlier in my career, I could have made more informed decisions, avoiding the pitfalls of developing features that failed to deliver the expected value. I have identified three key practices that have notably enhanced my approach to product discovery: a strategic mindset shift, the implementation of an opportunity-solution tree, and a commitment to deepening user engagement. These practices have not only improved our product but have also helped to de-risk project deliveries, instilling greater confidence in the outcome of the features we decide to build. # 1. Run Continuous Discoveries to Fuel Successes Product discovery is defined as "deciding what to build" by Teresa Torres. Treating "What are the next steps beyond what’s been planned” as an important responsibility in our domain helps us to prioritise making time for product discoveries. ![[Pasted image 20240320220155.png]] *(Source: ProductTalk.org)* This sounds pretty generic, but it is a powerful mindset shift. Generally, as a PM, we are responsible (the scale can vary, depending on the size of your organisation) for the output of the team. A lot of the time we have our performance tied to whether we are hitting the promised deadlines and milestones, so we spend a lot of time organising the work and motivating the team to ship on time while managing stakeholders. This is extremely common in a start-up, where Product Managers are most likely 100% responsible for the team's delivery. Meanwhile, in a larger organisation, we might work with a Tech Lead or an engineering manager on project management, so it could be a bit easier to find time to run discoveries and experiments. Carving out time to do this important job can help the team hone in on the right features to move the metrics and drive the business value. We will have a lot more confidence that these features that have run through discovery processed with users and stakeholders are what users need, and would bring the business values it promises. # 2. Use the Opportunity Solution Tree: A Game-Changer in Feedback Management As a PM, I have always struggled with the best way to log users’ feedback. I used to document them on a google doc / notion page / excel sheet, but it always becomes lost in the sea of information over time, especially when there are competing priorities. Based on my experience in the past 3 months, the opportunity-solution tree has helped to streamline and improve my discovery process. I can now log the feedback from users or prospects and look for common themes much easier. You can read more about how to use this framework [here](https://www.producttalk.org/2023/12/opportunity-solution-trees/). ![[Pasted image 20240320220343.png]] *(Source: ProductTalk.org)* This framework is especially useful when you need to identify the ultimate issue causing a problem for our users. For example, users are complaining about not being able to easily add new settings to the product; but when I dig deeper, I realised there is a lack of capability to work on multiple documents at the same time, meaning one needs to always change their settings to suit their context of writing whenever they switch to working on different projects. This led to different discovery pathways to look into how users are integrating our product into their current workflow. **Some of the best practices of using the diagram are key to product discovery:** * Always have more than one node in your opportunity, so you can identify a theme more easily * Always have more than one solution attached to your opportunity node, so you don't fall in love with one solution. Usually, the first solution is not so great! * Make sure it is updated regularly as we collect more feedback to identify themes continuously and drop opportunities that are deadends This tool is also useful for parking the feedback somewhere safe, knowing that the team might not have time to make the changes right now (usually, the important but not urgent bucket). It helps me to manage stakeholders’ expectations, letting them know that I acknowledge the feedback and will be looking into ways to enhance the product. This can help the stakeholders feel heard and respected. You can start building your opportunity-solution tree today with these simple steps: 1. Use a mindmapping tool (I use Miro but other tools would work just as well) 2. Identify the outcome you want to achieve - could be good to start with your North Star 3. Look through the feedback you have received from different sources 4. Write down the opportunities (i.e. pain points). Avoid solutions creeping into your pain points (don't write users want feature x; write what user is unable to do / suffering from at this stage) 5. Brainstorm solutions for the opportunity 6. Suggest solutions 7. Share this with the team and repeat. # 3. Harness The Power of Frequent Interviews with Users "Stay close to your customers" is probably the most repeated advice in the product world, but potentially one that people are not quite practising as much as they should. Naturally, this depends on the product domain we work in or the company dynamics. In my experience, spending time to talk to clients is extremely important in the B2B space. This is because our data collected might be comprehensive but it is unlikely to become statistically significant enough (compared to B2C) to be used in place of qualitative judgement. In the [Continuous Discovery Habits](https://www.amazon.co.uk/Continuous-Discovery-Habits-Discover-Products/dp/1736633309), Teresa has recommended that a product person should run client interviews every week. In practice, it is pretty difficult to conduct proper user interviews every week - but there are lots of things one can do instead to keep the client interaction frequent. These insights can go back to the opportunity tree to verify the opportunity you identified and confirm the assumptions you made with your proposed solution. Ultimately, you would be able to go and check off things that work and don’t work to make a go or no-go decision on whether the feature should be built. Some of the things I found useful: - Make use of calls scheduled for other purposes - like sales demos and client touchpoints so you can do these meetings often - Keep the number of questions you are going to ask small and try to fit what you need to verify in 15 minutes. This type of small interaction could work very well if you want to show a visual, prototyped concept - Ask users to screenshare and walk through their usual workflow. It is a gold mine of information that cannot be simply obtained via data tracking - because you can ask them to explain verbally why they are interacting with the product in certain ways - When a beta rollout of a feature is completed, ask for direct feedback over email. Some users are surprisingly keen and would be doing a lot of the stress-testing of the feature on the product, identifying edge cases that you might not have thought of Some of the things that I found not so useful: - Surveys! People aren’t filling out surveys anymore. This is slightly tragic but I also haven’t been filling out surveys for products either, why should I assume they would be filled out? However, as this action is low-effort, I am still going to send them out because when we do receive responses they are usually of high quality and a lot could be learnt from that. # Conclusion Reframing the importance of continuous discoveries will help the product team to build more confidently and build better. As we work in tech, we receive lots of feedback on the things we build. I would suggest starting small by just applying this framework to the feedback you receive from users. This should help you to navigate the feedback landscape, and ultimately you can use what you learnt from the discovery process to communicate and advocate more effectively for your ideas for the product. Some people might say running continuous discovery is difficult in their organisation. For example, you might work for a feature team, or you are not a PM. I resonated a lot with Teresa's view on how we have agency to work and build the way we want. Continuous discovery is a way of thinking that you can even apply to your day-to-day life even if it is not for product. For example, you could technically manage your career planning using this tree and examine what might work, or what might not work. **3 things to ask ourselves often:** 1. Are you doing the right amount to push for deliveries, but also looking into the future to discover new things to build? 2. Are there any themes emerging in your opportunity tree? 3. Are you speaking with your users or customers? Happy building! Tags: #ProductManagement #ContinuousDiscovery #InnovationStrategy #ProductStrategy #CustomerInsights #BusinessGrowth