A product owner’s guide to product discovery
What is product discovery ?
Product discovery is the process of understanding the customers’ problems and needs, and validating the ideas of the product team for solutions before starting development. Hence, it plays an important role in helping product teams to decide what features to prioritize, what to buy and what should be built, while keeping product excellence intact.
Teams can often find themselves in a dilemma: “should we buy a third-party service to have additional functionalities in our product?” or “should we build the service internally ourselves and avoid additional costs?”
So what should we do: buy or build?
There is no single answer to this, but there are key steps you can follow before coming up with an informed decision for your product during the discovery phase.
- Understand your customer 👩💼
Understand the underlying needs and feelings of customers and create a complete picture by crowdsourcing different perspectives across your team. This will help you understand the customers’ root problem (Problem definition) and before jumping into the first solution, making sure to take the time to meet the customers’ specific needs. Try to define who are the target customers (Customer segment) and what you think customers want to see changed (Customer needs).
2. Collect inputs and feedback ✍️
You could collect customer feedback/insights from various channels such as customer service, analytics and review tools but also internally from different teams working on the same product. You could use templates to retrieve explicit requirements (Product requirements or Product spec templates). This research will help you gather inputs to understand the product background, understanding the key objectives and success metrics (Key initiatives), team members who can play a role to contribute to goals and understand the dependencies (Obstacles) to take into account. Then, you can articulate the impact on the business and the users and what needs to be addressed.
3. Compare buy vs. build
Now that you have defined the problem and gathered the insights you need, you can work out if it makes more sense to buy a 3rd party tool or if you should build the tool internally within your team.
Buy 💰:
Integrating a 3rd party tool usually requires less effort, meaning faster development. But this could bring additional complexities to your existing product. It could create dependencies and limit your full access to the tool. Every product is unique and these tools cannot meet all of your needs. These tools are built to satisfy common needs of many products and serve a large group of people. With the input you gathered, you need to make sure that this additional tool will solve your problem.
Build⚒️:
First, look into the feasibility of building something new. Is your development team experienced enough to build this tool internally with the current tech-stack? If the answer is yes then go for it, but only if building the tool internally will bring value. It doesn’t always mean that what your development team can build will help you achieve your product vision. Ascertain if this will be a single use feature or if it would help across different platforms and channels. Lastly, confirm the effort of building this tool with your development team and align with them if it would be maintenance heavy.
4. Test the solution 🔍
Setup A/B testing with the provided insights and problem statement.
Problem statement: We’ve observed [X], which is causing [Y reaction] for [Z target user]. Our data input suggests this problem is affecting [# of people] and costing our business [$ amount].
Critical assumptions: If the experience results in [X% increase/decrease] of [key metric] compared to our control experience, then it would be a success for addressing the problem.
Hypothesis: We believe that [doing X] will result in [expected outcome] for [target user].
Success metric: If the experience results in [X% increase/decrease] of [key metric] compared to our control experience, then it would be a success for addressing the problem.
Statistical significance: Indicates at least %X statistical significance across the success and kill metrics.
Sample size: We need [sample size] in each experience to have confidence in our results.
Results: Key learnings.
5. Make it part of your product roadmap📝
The final step for product discovery is adding the work into the product roadmap. Check if your expected targets have met with the greater goal for the product, if the team would be on track to deliver it, and if they are working on the most important things first (Prioritization). If this additional feature (either bought or built) will improve the customer experience, lower the maintenance efforts and meet your product vision/strategy, then it means it has met with the product goal and could be part of the product roadmap and prioritized.
Thank you for reading!
