Product Discovery Techniques
Strong product teams use a variety of product discovery techniques to identify and address risk. The best teams tackle the biggest risks first.
What is Product Discovery
A key theme in Inspired is that strong product teams practices separate discovery and delivery activities. Because product discovery is such a critical part of modern product management, Cagan provides a number of techniques for each phase of discovery. There are about 30 short chapters on discovery techniques. It’s one of the best sections of the book. You can use it to select a technique based on where you are in the development lifecycle and what type of issue or risk you are addressing.
We need to learn fast, yet also release with confidence.
Many teams adopt the popular minimum viable product (MVP) method but run into problems. The concept of an MVP creates challenges because although the team wants to learn quickly by getting a release out to customers for feedback and learning, sometimes the release causes issues because it is not fully production ready. For most teams, delivering solid products is easier than achieving rapid experimentation and product discovery.
…the purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production-quality product, it won’t be a wasted effort
The goalof product discovery is to address and collect evidence related to four critical risks:
- Will the customer buy the product or use it? (value risk)
- Can the user figure out how to use it? (usability risk)
- Can the engineering team build it? (feasibility risk)
- Does the solution work for our business? (business viability risk)
Product Discovery phases
Cagan categorizes techniques by product discovery phase: framing, planning, ideation, prototyping, and testing.
Framing
Product teams use Discovery framing techniques to identify the issues that need to be addressed during discovery.
When teams believe there are large risks, they use planning and framing to set up the discovery activities. This approach is frequently required on large product initiatives. This first step results in an overall framework for the discovery work. Common framing goals are: 1) making sure the team is aligned on business objectives, customer problems, user profile, and success criteria; 2) identifying the the major risks that will need to be addressed during discovery work.
Opportunity Assessment
The opportunity assessment technique answers four key questions:
- Objective: what are is the business objective this work addresses?
- Key Results: what are the success criteria?
- Customer Problem: what customer problem will be solved?
- Target Market: what type of customers will be served?
Customer Letter
The customer letter technique is Cagan’s variation on the Amazon press release. This document projects you forward in time to a point at which your product has already been released and a customer is writing to your CEO to express their happiness with your product. This is a great tool to use for new feature and product development because it gets you thinking “with the end in mind.”
Startup Canvas
The startup canvas is a lightweight version of a business plan. Cagan doesn’t actually specify which canvas he’s referring to (and there are many), but the most popular is the business model canvas. This is the tool of choice when creating an entirely new product or line of business. Once the high level parameters have been established, more detailed discovery and learning can take place.
Planning
Discover Planning techniques are used to scope and plan solutions.
Story Map
Cagan calls story maps “the most generally useful technique I know.” Story maps arrange user stories in a holistic, prioritized, and organized view. The map allows you to depict release slices as well as organize by user journey phases.
Customer Discovery Program
Cagan says “there are few things more power for a product organization than reference customers.” Reference customers help the sales team understand the target customer. A customer discovery program allows you to discover and develop “a set of reference customers in parallel with discovering and developing the actual product.” Cagan previously wrote about these as charter customer programs.
The basic driver behind this technique is that, with a significant new product, the most common objection is that prospective customers want to see that other customers, like themselves, are already successfully using the product.
A reference customers is a real customer who is running the product in production, has paid money for the product, and is willing to tell other customers about their great experience. The objective of a customer discovery program is to: 1) help the sales team know where the product/market fit exists; and 2) provide your team with direct access to target customers that will help you generate product ideas.
When creating a reference customer program, recruit customers from a single target market or segment. This aligns with Cagan’s view on product strategy: gain success in one vertical market after another. Participation in a reference customer program takes time so you’ll need to screen for customers who actually have the time to help you. These customers also need to acutely be aware of the problem you are solving and have an immediate need for a solution.
…your job as product manager is not to put in the features that all [reference customers] request. While that would be much easier, that would yield an awful product. Your job is to dive deep with each…customer and identify a single solution that works well for all…
Ideation
Discovery ideation techniques are used to generate solutions for key problems. Many teams don’t use ideation techniques. Product teams are frequently handed features from roadmaps, large customers or internal stakeholders.
…if the product team is given actual business problems to solve rather than solutions, and the product team does their job and interacts directly and frequently with actual user and customers, then getting a sufficient quantity and quality of product ideas is not really a problem
Customer Interviews
Cagan recommends having the product manager, designer, and an engineer at every customer interview. Customer interviews should be done on a regular cadence. Key questions to ask:
- Are your customers who you think they are?
- Do your customers have the problems you think they do?
- How does the customer solve the problem now?
- What would it take for a customer to switch to your solution?
Concierge Test
In a concierge test, the product manager visits the customer and performs the customer’s job. This enables the product manager to understand directly the challenges the customer faces in order to devise a solution.
Hack Days
Many tech companies use hack days to generate tangible solutions for customer problems. Cagan says that the best ideas often come from engineers. A directed hack day (where all teams focus on a specific customer issue) is a great way to get the entire team engaged.
Prototyping
Discovery prototyping techniques put a tangible product experience in front of the customer and the team to accelerate learning. Prototypes allow product teams to lower the cost of learning, think about problems more deeply, and collaborate. Also, prototypes result in a tangible solution design that engineering can use to guide development. Teams choose various levels of fidelity for the prototype depending on the risk being addressed. Product teams can use four types of prototypes during discovery.
product discovery is all about coming up with the fastest, cheapest way to test our ideas
Feasibility prototypes
These prototypes are created by engineers to address technical risk such as performance and scalability. The engineers write just enough code to prove out the risk area.
User prototypes
These simulations range from low-fidelity wireframes and paper sketches to high fidelity clickable mockups and live software. User prototypes are good for usability risk, but are not effective for value risk.
Live-data prototypes
Live-data prototypes collect and access live data to prove whether an idea or workflow is the right solution. They can be more expensive than other types of prototypes, but are a good choice if data management and transformation are key to the solution. Live-data prototypes are scaled back products or features that are not fully tested, secure, scalable, or localized.
Hybrid prototypes
A product team working on search and recommendation algorithms might use a hybrid prototype to access live-data sources without sending live network traffic. Another example of hybrid prototype would be a Wizard of Oz prototype in which a person is manually performing what will ultimately be done by software.
Testing
Discovery testing techniques are focused on the four key risks for product teams: usability, value, feasibility, and viability.
In product discovery, we’re essentially trying to quickly separate the good ideas from the bad as we work to try to solve the business problems assigned to us.
Testing usability
Will the customer be able to use the product? Usability tests should include the product manager, designer, and an engineer. These tests use a high fidelity prototype with a set of prescribed user actions. Stay objective, neutral and focus on whether users can achieve the tasks, not whether the product is perfect. Conclude each test with a write-up that is shared across the team.
…you’re trying to get an understanding of how your target users think about this problem and to identify places in your prototype where the model the software presets is inconsistent or incompatible with how the user is thinking about the problem
Testing value
just because someone can use our product doesn’t mean they will choose to use our product
- Testing demand – A fake door demand test uses a button or link in the product to determine how many users are interested in using the feature (which isn’t available yet). When they click, they get a page which tells them you are evaluating demand for the feature. A landing page demand test is the same type of test but uses a full landing page instead of a button or link within the product.
- Testing value qualitatively – Quantitative testing will tell you what is or isn’t happening, but won’t tell you why. Asking people whether they would use your product will likely result in false positives because most people try to be nice during product testing. That’s why Cagan says to ask for non-binding letters of intent to buy, share on social media or write on-line recommendations, commit to spending time with you to improve the product, or whether they would provide you with access to their current solution so that you can begin a migration process.
- Testing value quantitatively – A/B tests, invite-only tests (only showing a new feature or product to a small percentage of customers), and customer discovery programs are examples of quantitative testing techniques.
Testing feasibility
Technical feasibility testing includes asking whether the team: 1) knows how to build the product: 2) has the skills to build the product; and 3) has the time to build the product. Other considerations include architectural changes, dependencies, scale and performance requirements, infrastructure and overall cost.
Testing business viability
You need to help protect your company’s revenue, reputation, employees, and customers you’ve worked so hard to earn
Fundamentally, as a product manager you need to understand the constraints each of your constituents (marketing, sales, customer success, finance, legal, business development, security, CEO/COO/GM) has and ensure each are taken into account when the product is built. It is the product manager’s responsibility to ensure that none of the constraints surface during product launch and prevent the product from reaching the market.
Transformation
Cagan uses the phrase “we need teams of missionaries, not mercenaries” frequently in the book to encapsulate the theme of modern product teams. Missionaries are engaged, motivated, collaborative, and focused on solving business problems.
Transformation techniques enable teams to move from old ways of working to new ways. Key techniques Cagan sees as enabling this transformation are discovery sprints which focus the whole team on discovery for a week, the use of pilot teams to incrementally roll out new practices, reducing or eliminating the use of feature roadmaps, stakeholder management, and communicating product learnings.
