The Product Playbook — Part 1: Product Discovery
Originally product development, even in the tech industry, was a slow process. You would follow a waterfall process, first doing research, then writing a massive time-consuming product requirement document and then finally handing it over to engineering to be built. Once the product was finally released after many months, what would likely happen was a product that didn’t solve the customer needs and hence not meet business goals.
Fortunately, we have evolved from those days and now we are all familiar with agile and lean development. However, despite the new push towards agile, in the tech industry, we often see and hear about the struggles to see the big picture and creating a data-driven product development process. Therefore, we have created a product series, where we will share one approach that will help you, whether a startup or corporate, to go from discovery to delivery. This also underlines our belief at Sparrow Ventures that, as part of the venture building process, the discovery phase is likely one of the most important elements in the product area, because it is all about experimenting and efficiently finding a way to validate solutions. So, let’s get started and dive into the product discovery phase, which provides the iterative process of identifying problems and testing solutions.
“Data-driven and customer-centric validation of business models play a crucial role in the product development process”
What is the discovery phase
In discovery, we are tackling the various risks before any software code is written. The goal of this phase is to have a validated backlog of solutions, which can be handed over to the developers with some level of confidence that this is worth building and delivers value to customers. It’s recommended to answer these four key risks questions during discovery:
- Value risk (whether customers will buy it or users will choose to use it)
- Usability risk (whether users can figure out how to use it)
- Feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
- Business viability risk (whether this solution also works for the various aspects of our business)
Source: Marty Cagan
With a fundamental understanding of what the discovery phase entails and what the goal is, let’s move into concrete steps that can be taken to achieve this. We have broken down the discovery phase into 4 steps that can be used to validate a new business idea, a feature, or identify a minimum viable product. Each step will be described in detail separately.
Inspired by Teresa Torres
Desired outcomes
Generally, good product discovery starts with a clear goal in mind. This is very important as it helps guide you and your team towards the objective and an understanding of what success would look like. There are different methods to set up your desired outcomes. You can use Objective and Key Results, KPIs or Funnel Metrics (ie. retention), it doesn’t really matter the methodology you use, what is important is that you create concrete objectives for your product team to work towards. Additionally, we can create multiple desired outcomes but generally if it’s a small team better start with one clear desired outcome. The outcomes can also be used as the product roadmap that guides product development.
Identify opportunities
With the team aligned on the desired outcomes, we can now seek opportunities that meet these outcomes. Opportunities can come from many different places, below in the illustration we listed some common ones. It’s critical that you continuously talk to existing customers or target customers to get feedback about how they currently solve their problems, how they engage with your product and what they like/dislike about your product. This will help you identify their needs and pain points, which you can use to frame as opportunities. Additionally, look at your analytics, to see where visitors drop off, what features have low engagement rates, do cohort analysis and so on.
Another place that can provide insights is talking to internal stakeholders. If you have a customer support team, they can share what are the common issues mentioned by customers or visitors, or if you have a sales team, they can likewise give input regarding their observations. To consolidate your learnings and findings, it’s helpful to use UX mapping methods to articulate the user needs and behaviors, and even the component processes involved. It’s important to not stick to one opportunity but be open-minded and branch out to find the best set of opportunities that would solve for the desired outcome.
Design solutions
What often happens naturally is that we jump into a particular solution first, but with these steps, designing solutions only comes as a third step and not to settle on one solution right away but brainstorm multiple solutions that can solve for the related opportunity. A common method to find solutions to a problem is to use the Design Sprint method. At Sparrow Ventures, we typically bring together the team to create solutions at the beginning of a project and test them with potential customers. This allows us to quickly come up with solutions collaboratively and validate the solutions with potential customers. Another helpful method is Wireflows, which combines wireframes with a flowchart-like way of representing interactions. This is on one side helpful to visualize and think through complex interactions and on the other side useful as a collaboration and ideation technique.
Run experiments
It’s not enough to ideate solutions then start implementing them. Before a single line of code is written, decide on solutions that have been validated through some type of experimentation. Use experimentation to evaluate and evolve your solutions and look to test the riskiest assumptions (value, usability, feasibility, or viability). There are different ways to experiment, you can build a design prototype to get user value and UX/UI feedback, create a landing page to see how many clicks you get or client workshops if you work in B2B. It’s important that you try to validate and increase the probability of success before you put in development resources.
Conclusion
The discovery approach starts with creating goals, followed by identifying opportunities, creating solutions, and finally validating the solutions through experimentation. The methods and tools attached to each branch are just examples of good practices, remember to always adapt it to your situation. Despite being a linear tree diagram, it’s important to continuously iterate and loop through each step. Using this approach removes biases in the team and creates a data-driven approach to discovery, through goal setting and validating ideas with potential customers, thus increasing the probability of success.
This post is the first part of our ‘Product Playbook’ Series. Watch this space, as in the next blog post, we will dive into the product delivery phase, the point at which prioritized product specifications are handed over to the development team or engineers to be designed, built, and implemented. Next to outlining how we go about this approach at Sparrow Ventures, our ultimate goal is to equip non-technical individuals with the knowledge and an understanding of the processes that are standing behind launching digital products.
