3/36 - PD Preparation & Frameworks
3/36 - PD Preparation & Frameworks
Everyone is not your customer.
What is product discovery?
Product discovery is nothing new to the world, as it has always been a part of a product manager’s job. Basically, it’s an initial stage of product development, where we state a problem and a target audience in need of a solution. The goal of product discovery is the creation of a constant learning loop that provides the team with feedback to get a better read of market needs.
The discovery process comprises two big sets of activities: exploration and validation.
Exploration is what most people think of when they hear the “discovery” term. It denotes all activities concerning the research stage of a product, communication with stakeholders, and exploring existing problems, solutions, and customer pains. This phase includes research, ideation, and evaluation activities.
Validation is a set of activities intended to check each assumption made during the exploration process. Before anything is designed, the product should pass a solid test on whether the ideas can generate value for the end user. This is done with the help of prototyping and testing using data and customer feedback. The activities are prototyping, testing, and learning.
The validation stage is similar to user acceptance testing conducted by the QA team but takes place long before any user stories are written. It aims at creating prototypes and tests for each idea to make sure it has to be in a backlog. The testing results either kill the ideas or decrease the level of uncertainty.
Both exploration and validation are iterative processes that precede the delivery stage of product development. So, product discovery can be seen as a scientific method to building software, as it suggests using experiments and tests as a tool. This gives us a more solid base to create an overall product strategy and roadmap the whole development.
Why is product discovery that important?
Product discovery isn’t an exotic practice; it is a traditional part of any project. The way you do it makes a great difference. As a product manager, CTO, or CPO, it will be your direct responsibility to justify why the team should spend more time on the discovery process.
Each company is a unique case, but let’s look at some theoretical basis to understand why product discovery is so important. Marty Cagan, the author of Inspired, suggests four main risk types in product management:
Value risk, bringing zero value to the customer.
Usability risk, building something a user can’t figure out how to use.
Feasibility risk, the risk of lacking technology, skills, or time for the product.
Business viability risk, the risk of not achieving your business goals with the product.
The practice of product discovery first of all deals with bringing as much value as possible. Before the delivery stage, each idea tends to be validated and tested on the real user, mitigating the risk of building the wrong thing. By these means, we can also improve our UX.
The idea field becomes cleaner as we sweep aside unrequired items, which facilitates the feasibility of a product and more efficient resource consumption. Given the outcomes of product discovery, we can define KPIs and concentrate on business viability instead of solving technical tasks. Among the general problems, the practice can help your team avoid opinion wars, because any assumption made will be tested to find proof of its demand.
Product Discovery Preparation
First, you need to understand the purpose of a new feature or a product, and that is the problem it solves. The goal is determined by your specific case: It can be a feature concerning one part of functionality or the whole product. The idea is to present the team with the desired outcome, success criteria, and method to use.
Let’s imagine a travel review site similar to Tripadvisor is planning to implement a booking feature on their website, instead of giving a “View Deal” redirect link. To approach the goal statement, you must define the list of critical questions that challenge your idea and suggest initial assumptions to be tested further. For example:
Does the customer need this feature? (Probably, as customers make purchase decisions on our website.)
What value will it bring? Which problem does it solve? (Travelers won’t have to leave the platform to complete a booking.)
Do customers really experience this problem? (Yes, our partners confirmed that 94 percent of customers abandoned their cart after coming to a third-party page.)
Are there enough customers to target? (15 percent of our visitors click the “View Deal” button.)
How will they use it? (Clicking a book button offers an easier way to check out and purchase tickets right away.)
If we remove this feature, what will change? (Customers will still book through third parties.)
Will the customer pay for it? (According to research, direct bookings have more trust among travelers to make travel purchases.)
Do we have the resource to build it? (Yes, we have expertise in payment gateway integration and our suppliers have well-supported APIs to integrate direct booking.)
Does it help us achieve our business goals? (If we manage to reduce the number of abandoned bookings from 94 to 70 percent by bringing the booking directly to our platform, we’ll reach positive ROI for the booking feature in two years.)
By answering these questions with assumptions and testing these hypotheses later will reduce uncertainty. But it’s important to note that discovery should result in outcomes, not features and technical solutions. In practice, these can be a value understanding, or user personas, or a KPI. In our hypothetical case, the goal is to improve the conversion rate from 6 to 30 percent by bringing booking capabilities to the website.
Exploration & Validation phases
Exploration
Research
The research stage is a general problem overview. Here we’re looking at such aspects as:
Market conditions,
Market gap research,
Existing market problems,
Existing solutions,
Competitor/non-competitor overview,
Audience overview, and
Existing monetization mechanisms.
The gathering of data should result in a solid understanding of the market (customer problems), customer segmentation, and possible solutions you can build for them.
One of the best practices on how to approach problem understanding is recruiting the customer from the market. This way, you can extract valuable insights into the real problem existing in the industry and learn about the pain points. This will also give you a more realistic user persona to generate assumptions.
Ideation
With a given input, now your team can gather to brainstorm the ideas for the future product. Ideas are formed from the user perspective, addressing the existing problems. Basically, we’re forming a roster of “future features.”
Evaluation
The evaluation process begins with the prioritization of the ideas by importance, difficulty, value, and risk factor.
We can put ideas into three categories:
Copying ideas. These are ideas that seem to be nothing new to the market, as they reproduce either approved things in the industry or present a standard solution for a known problem.
Evolution ideas are those suggesting improvements for the existing solutions.
Disruptive ideas describe something completely new to the market.
Every idea is based on the assumption that it will solve a certain problem for a customer.
Ideation risk matrix
The matrix demonstrates the growth of the risk factor and feasibility for disruptive ideas, and vice versa. Considering this, we can determine which ideas we’re going to test, depending on the level of uncertainty.
The loop of exploration closes here. We can generate new ideas endlessly, while the existing ones are evaluated, tested, and weeded out.
Validation phase
The exploration of a problem field should result in the validation of a solution. Once we’ve generated the idea roster and evaluated it, it’s time to validate suggested solutions. Since the product discovery process relies heavily on user feedback, it’s important to engage real users from the market at this point.
Let’s say you’re building an eCommerce platform. You track that user often scroll across the entire category sections to find the products they want to click on rather than using existing filters. Your idea is to add removal filters, so that users can exclude items by keywords from the category view, e.g., laptop category, with the user excluding Dell, Samsung, and Xiaomi to look at the models of other brands. How do we check to determine whether users need this feature?
First of all, we can’t be sure why users scroll through the whole category page instead of using existing filters, so we might ask them first. Maybe they don’t know which products are available and they want to explore the majority of options. But they do know for certain that they won’t buy some brands. This can be done via a user interview to reveal the motives. Second, we can build a prototype and run several tests to see if users prefer to still scroll the category or apply removal filters to narrow down the search.
To approach idea testing, we can use established techniques from product management. The most important thing we need to do to start is idea mapping. You can perform it at the ideation stage or at the validation stage. As a result, we need to outline the “risk” points that will be validated: You can create a visual representation of your ideas that will be tested. Mapping aims at better visibility of how ideas relate to each other, and how testing can be applied to validate multiple ideas. This can be done with the help of story mapping, which is a backlog prioritization technique we discussed in a separate article. Once you’ve mapped the ideas to be tested, you can start with creating prototypes.
Prototyping
Similar to user experience testing, we need to create prototypes for the given ideas. This can be done in a form of wireframes or sketches. The same prototype can be used to test multiple ideas. But it can also be performed through simple questions and answers.
Testing
Testing depends on the case and the risk factor. Just a few points to mention here:
The Nielsen Norman Group suggests running tests with not more than 5 hired customers. Test accuracy is more important than speed, but the results may differ from user to user. That’s why you should focus more on validating the core idea, rather than trying to explore audience usability preferences and peculiarities.
Use prototyping tools. Pen and paper could also work. But for the sake of convenience and shareability, it is better to use some of the well-known tools like Figma, UXPin, Balsamiq, or Sketch.
If you want to learn a bit of theory, here is a nice place to read about user interviews.
Learning
The results of the test then should be analyzed to answer the questions stated on the stage of purpose statement. Once a risk idea is validated, it can be further transformed into a user story or feature.
Product discovery frameworks
Now that you’ve learned the process elements in detail, let’s have a look at some of the prominent frameworks out there.
1) Design thinking
Design thinking became a basic concept and framework for conducting product discovery. It’s a customer-centered approach to analyzing the product requirements. Three primary elements shape the whole idea:
Desirability shows demand for a certain feature by a target audience.
Feasibility, or technical possibilities, as your company’s skills and resources.
Viability, or what makes sense for your business model.
Design thinking is one of the basic concepts and frameworks used during the product discovery phase. It’s often described as a way to solve particular problems through creativity.
IDEO is believed to be the father of design thinking, but they denied this title, claiming that they just popularized this approach:
“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
— Tim Brown, Executive Chair of IDEO
2) Jobs to be done
Jobs to be Done is a popular framework for product discovery. The idea is to look at the requirements not from the exact user persona (or customer) perspective, but from the job perspective of a target persona. In simple words, Jobs to be Done suggests analyzing ideas as a set of activities a user is trying to complete within the app.
There are five clear steps in this framework:
Market identification as a standard exploration phase, definition of the market problems, and understanding of user personas.
Jobs identification. This activity aims at understanding the actions and objectives customers are trying to complete. We’re also figuring out the motives a user is reaching while doing a “job.”
Job categorization. The identification of the main jobs and secondary jobs.
Job statement. The description of the job specifics.
Opportunity prioritization, or simply, developing solutions to the customer problem.
For example: A user of a gambling app is constantly reviewing stats. Their objective is to get the overview of how their actions impact the outcome of the game.
We can make an interface easier to use, add hundreds of filters to enhance flexibility of the app. Or we can automate the data collection of the section a user reviews the most and present them as a customizable dashboard. Both cases help the user reach their goals, but the second one requires less effort.
3) RAT or riskiest assumption test
Those working in software engineering or product management should be familiar with the concept of MVP. Minimum Viable Product is the required functional minimum that can bring the core product value for the end user. MVP is used to prove that a team is building the right thing.
A riskiest assumption test is a similar concept that suggests focusing on testing the assumption that seems to be… well, the riskiest, instead of building an MVP. It doesn’t mean that we no longer need to build a demo product to show and test on. Instead, RAT suggests testing those areas where we have the most uncertainty before moving to the delivery stage.
Additional Reads :