Inspired gives companies and entrepreneurs a two-step plan for creating and sustaining successful technology products:
Inspired also explains how important product managers are in product development, teaches them how to be successful, and explains some of the biggest pitfalls that most tech companies fall into when designing products.
Author Marty Cagan, a Silicon Valley product executive, also details how product designers and engineers should function in a team and how company executives should treat their product teams. Originally published in 2008, the book was updated in 2018 to further address evolving concepts such as lean and agile techniques. This summary begins with a discussion of how to set up teams, then explains how to “discover” products.
Before companies can develop new products, they must first organize and structure their product teams for success. Key structuring steps are to:
A successful product development team has three key roles—a product manager, designer, and engineers—plus supporting players including marketers and analysts. The most critical role is the product manager, who must understand what ideas will succeed and what ideas will fail. A product manager is knowledgeable about:
The second key team member is the product designer or UX designer, who is responsible for designing the product with the customer and user experience in mind. Product designers ask some of the following questions when designing a product:
While product managers have a holistic understanding of how the product functions, product designers may better understand how the product’s target audience will use it, given that they are primarily concerned with user experience. This means that they are strategic partners with the product manager, and they help the product manager make decisions about all user-related questions, such as where to place a home button or whether to develop new charging technology.
The product designer can answer the questions by working with the rest of the team to develop prototypes of the product and to test them. We’ll discuss the development and testing of prototypes when we discuss product discovery.
The third key part of the team is the engineers. Engineers are responsible for the coding and any other building that is necessary to create the product. While there is one product manager per team and generally one product designer, there are usually between two and 10 engineers per team.
Engineers are useful beyond pure coding, though. Because they’re intimately familiar with the way the code and machinery work, they often have the best understanding of how to expand the product (and the limitations on doing so).
Engineers and the product manager need a good relationship so they can share ideas and solutions. This will benefit the team because engineers are often knowledgeable about the inner workings of the product in a way that product managers are not, and so they can often contribute unique ideas about how to build products.
It’s largely up to the product manager to build this relationship. Every day, product managers solicit engineers’ ideas, and engineers ask product managers for clarification on the goals of the product. By being knowledgeable but also soliciting feedback, product managers can turn engineers into true missionaries, or product advocates.
In addition to the three key players, product teams, especially at bigger companies, have other supporting members, including marketing professionals, researchers, analysts, or engineers who test products.
Now that we’ve explained team roles, we’ll discuss how teams build products. Many companies start with a product idea, then create a roadmap, which sets specific deadlines for when parts of the product must be finished. However, this strategy doesn’t account for the fact that at the beginning of building a product, it’s unclear what will take a lot of time and what will take little.
Companies would be better served to adopt a method of product discovery, a process of discovering the optimal product by separating good ideas from bad. It begins with defining a vision. A product vision is the overall goal of the company (or, in a large company, a component of the company). It can be achieved only far in the future—somewhere between two and 10 years. Here are 10 principles for creating a product vision:
The product vision method is better than the roadmap because it provides stakeholders within the company the ability to give their perspective on the product and is generally a more flexible method of building products than setting arbitrary deadlines.
Once companies have a clear vision, they can move on to building products. We’ll go through the steps of product discovery to explain how to build products.
Framing helps you identify underlying issues with your ideas. There are two steps:
Once you’ve established the parameters, the next step is figuring out solutions. The planning process can help to identify significant challenges. A planning technique companies often use is customer discovery.
This is the process of finding and retaining loyal customers—the lifeblood of any company. The best way to do this is to look for reference customers—people who would pay for a final version of your product and like it enough to recommend it to friends.As few as six reference customers can help your company grow by helping you develop and market your product . Before fully launching, a company should recruit between six and eight of these people. The best reference customers share these characteristics:
Recruit these customers either from existing users who still have a problem they need to have solved, or from surveys that determine whether potential customers could use your product. Once you find these people, treat them like your colleague or partner rather than a test subject. You both need one another equally.
The next step in the discovery process after framing and planning is prototyping. People often think of prototypes as nearly complete products, but less elaborate prototypes are more useful and less expensive to produce.
While prototypes do take much less time, money, and energy than the final product to create, they still force teams to take the ideas in their heads and put them to work. They are a good balance between putting too much effort and too little effort into an idea.
There are four basic prototypes:
Sometimes engineers aren’t sure whether they can build a tech product—for instance, because of concerns like scale or whether it is possible to successfully code the version of the product they have in mind. The way to answer the question is to build a feasibility prototype.
In creating a feasibility prototype, engineers typically write just enough code for the project to know that they can complete it. The code doesn’t need to be perfect—it’s unlikely that it will go in the final build.
The feasibility type is done by the engineers and is for the engineers. The product manager needs to concern herself with it only insofar as she ultimately decides whether to move forward with it.
While feasibility prototypes involve writing a minimal amount of working code, user prototypes are simulations of the final product. They’re not actually functional—for example, a customer wouldn’t actually be able to buy anything via a user prototype for an online marketplace like eBay.
The simplest user prototypes often don’t look anything like the final product and serve only as the skeleton. Generally, simple user prototypes are for internal use only—to help the team visualize the product.
In contrast, more complex user prototypes called high-fidelity user prototypes look and feel like the final product. They take longer to create, and they can be used both internally and externally on test subjects. However, high-fidelity user prototypes aren’t live, and can still be fairly basic—for example, a search function, might generate only a few results, or an algorithm still needs building.
A company pursuing a risky idea, can get real data on whether a product will sell while in the discovery phase by creating a live-data prototype.
This prototype is a pared-down version of the final product—it’s not scalable, can’t take much traffic, and doesn’t have any SEO or analytics associated with it, but it does function. Test users can use the product and provide qualitative data on how they felt and quantitative data on how they used it and how well it worked.
Remember though, that at this point, the product still has a long way to go—the engineers have likely done less than 10% of the work needed for success.
The final prototype is the hybrid, which is a combination of the first three types. A “Wizard of Oz” prototype is an example of a hybrid prototype—the name comes from what’s behind the curtain. Behind the product’s front-end user experience, an engineer manually performs the tasks that the front-end says it can do. This saves time on automation, and can provide a sense of what people think of the product.
Most hybrid prototypes are the least scalable of the four types, as they’re meant to be built quickly and provide customer feedback without requiring unnecessary engineering work.
Throughout the product discovery process, companies address four risks:
Testing for these four risks is meant to once and for all separate the good ideas from the bad. In the following sections, we’ll discuss each of the four areas of risk and how to test for them.
Determining whether a product has value or a market niche (commercial viability) is one of the most important tests. Customers will generally only buy a new product if it’s significantly more valuable than what they’re currently using.
There are three ways to test for value:
Generally, this type of testing is straightforward. You’re making sure that users understand how to use your product and find it fairly easy to do so.
Recruit a group of test subjects and prepare a usability test. Here are some steps in a good test:
The third risk to be explored by testing is feasibility, or whether engineers can actually build a product. Feasibility testing asks engineers to determine whether it is possible for a product to be built either by building a feasibility prototype or by building enough of the product that they are confident they can build the rest. Feasibility testing is also asking whether the current engineers on the team have the skills to do so, whether the company has enough time and resources to build the product, whether the product can be scaled, and even whether the company has the raw materials to build the product if it’s hardware.
At this stage in discovery, most engineers will decide that the answer to the above is “yes, this is feasible.” Occasionally, though, if engineers are not sure if something is feasible, they need time to investigate it. In this instance, engineers build a feasibility prototype to answer any outstanding questions. As we’ve learned, these prototypes don’t take much time or energy generally, but the product manager still has to decide whether it’s worth the effort. Generally, the answer will be yes, and often, while considering the question of feasibility and dealing directly with the product without other distractions for a day or two, engineers come back not only saying it’s feasible, but offering ideas to make the product better.
The fourth risk that testing explores is business viability, or whether the product will be profitable. This is the final hurdle before moving on with product creation. The product manager shows departments throughout the company the business model they have created of the product, and these departments in turn analyze the business model for any potential problems. If they don’t see any, they will sign off on the project. There are many stakeholders who need to sign off before a product has business viability—here are some of the most common.
Once you’ve completed each of these steps, you can go to work on the product. Don’t be discouraged if many of your ideas fail in this process. The ideas that do pass through the process will likely be successful.
Inspired gives companies and entrepreneurs a two-step process for creating and sustaining successful technology products: 1) organize and structure effective teams, and 2) develop products using a flexible “discovery” process. In particular, it explains how important product managers are in product development, teaches them how to be successful, and explains some of the biggest pitfalls that most tech companies fall into when designing products.
Author Marty Cagan, a Silicon Valley product executive, also details how product designers and engineers should function in a team and how company executives should treat their product teams. Originally published in 2008, the book was updated in 2018 to further address evolving concepts such as lean and agile techniques. This summary begins by discussing how to set up teams, then explains how to “discover” or develop products.
(Shortform note: In this summary, we’ve mostly maintained the structure of the book, but we’ve reorganized and combined many of the 67 chapters for clarity and coherence.)
There’s a huge difference between the way most companies develop new products and the way that the best ones do. In Part 1, we’ll examine why many products fail and then explain how products can succeed. Finally, we’ll discuss the structure of teams and companies. You’ll leave this section with an introduction into how product teams can succeed and pitfalls to avoid.
To understand the pitfalls for products, teams, and companies, let’s examine how companies typically develop new products:
This process, though, is filled with pitfalls. Some of the most salient are:
Now that we’ve examined the usual way of creating products and the reasons that they fail, there are three ways we can do better.
We’ll return to these three major concepts throughout the book.
Product teams that are following the rules laid out above engage in a continuous process of discovery and delivery. Think of these two concepts as parallel lines—good teams work on discovery and delivery separately but concurrently.
Product managers consider what the product needs (discovery). The discovery process, which the summary will discuss in Part 4, attempts to answer the following four questions:
To answer these questions, companies should build quick and fairly simple prototypes to test on focus groups.
Engineers consider how to implement product needs (delivery). As we stated before, engineers can also be useful in the discovery process, but their primary role is on the delivery front. If the prototypes are popular and working well, and we’ve answered ‘yes’ to all of the four questions above, engineers should concern themselves with questions of how to get the product or feature to market, scaling up production, making sure performance is good across the board, and doing the necessary safety checks on questions of privacy and security.
There’s a big difference between a product being impressive and its being successful. And no matter how good your engineering team, if they’re building a product that people don’t want, it won’t sell.
There are three types of tech companies, each with their own advantages and disadvantages when it comes to product development:
As a young engineer at Hewlett-Packard in the 1980s, author Cagan was tasked with building a huge workstation that wound up costing over $100,000. Product reviewers were wildly impressed with the outcome, but it didn’t sell at all.
He realized that the engineering team had done all that they could to deliver on their task, but that their product manager, who should have had a better handle on the marketing of the product (and whether there was a market for it at all), had failed. Cagan decided he would no longer work for teams where he wasn’t sure whether there was a market for the product they were building.
Since then, he’s helped to build many products, and while they’ve had varying degrees of success, none has been the abject failure that the HP machine was.
For a product to be successful, it needs a good team working on it. Part 2 explains how to create an effective team, and thus give a product the best chance of success.
Every team needs to be filled with missionaries rather than mercenaries. In other words, employers should look for and cultivate those who truly believe in the product and advocate for it rather than people who only do what they’re told.
First, we’ll discuss team organization and then describe the three key positions and their responsibilities:
In structuring a product development team:
Among the three key product development roles, the product manager is the most critical to the success of a product team. At a smaller company, the product manager could be the president/CEO as well.
The product manager must understand what ideas will succeed and what ideas will fail. A product manager must be knowledgeable about:
A product manager at a poorly functioning team works in one of two ways:
Both of these approaches devalue the role of the product manager.
Even the best product managers take a few months to learn the job, so make good hires or you’ll waste months of effort and training.
Great product managers have five important qualities:
Finally, every good product manager at a tech company has a basic understanding of computer programming and business. Computer programming helps them to understand their engineers, and business knowledge helps them to understand the industry. They take additional classes in these two fields if they didn’t have an introduction to them in college or graduate school.
Large companies developing multiple products under multiple managers have a lead product manager who coordinates department efforts. This manager is a senior executive, and has all of the same skills as the other product managers, but their primary role is to maintain a holistic view of the company and see how all of the products are fitting together (or not).
They also know how to develop teams, have a clear vision of the overall mission of the company, understand the company culture, and can execute on many disparate ideas.
Finally, the person in this role builds good relationships with both the product managers and the CEO/CFO. They’re capable of explaining their overall vision to the product managers, while also making them feel as if they are in charge of their own products. Lead product managers are also good at taking feedback from product managers, implementing it, and explaining it to the CEO/CFO.
Most companies’ products have poor designs because they don’t worry about design as much as they think about the engineering. This is a mistake because, as Apple has proven, having a product with an interface that is visually appealing to customers is a huge competitive advantage.
The product designer or UX (user experience) designer is responsible for designing the product with the customer and user experience in mind. Product designers ask some of the following questions when designing a product:
The product designer is also a strategic partner of the product manager. While product managers have a holistic understanding of how the product functions, designers may better understand how its target audience will use it. As a result, the designer can help the product manager make decisions about all user-related questions, such as where to place a home button or whether to develop new charging technology..
Product designers answer user experience questions by working with the team to develop prototypes of the product and to test them. We’ll explore testing in detail in Part 4.
Product designers focus on two types of design: interaction design and visual design.
Most product designers have some experience with both of these types of design.
When a company gets big enough it needs a lead product designer, just as it needs a lead product manager. The lead designer is responsible for making sure that visually, every project looks the same. Having different fonts on different products within one company, unless it is obviously intentional, just looks disorganized.
We’ve already touched on why the product designer is so important, but now let’s consider what would happen if the product designer didn’t exist. The product manager would either take on all of the design herself, delegate the design to her engineers, or do the interaction design herself while delegating the visual design to a graphic designer.
None of these situations is tenable because, beyond how busy the product manager already is, it takes a specific skill set and understanding of a visual language to succeed as a designer. Bringing in a professional graphic designer might help with some of this, but they won’t have access to the consumer data from the surveys, nor will they be likely to understand the product well.
Therefore, product managers should do a few things to encourage the work of the product designer:
Many companies think of engineers as simply cogs in their larger machinery. They are there to fix bugs and follow specific directions on how to build products. However, engineers can significantly contribute to the success of a product beyond applying their technical skills.
Engineers are responsible for the coding and any other building that is necessary to create the product. While there is one product manager per team and generally one product designer, there are usually between two and 10 engineers per team.
Engineers are useful beyond pure coding, though. Because they’re intimately familiar with the way the code and machinery work, they often have the best understanding of how to expand the product (and the limitations on doing so).
The Chief Technology Officer (CTO) heads the engineering department. The CTO is similar to the lead product manager and product designer, but is responsible for making sure that all of the code written and other engineering done over the various products fits together. This person understands the greater strategic goals of the organization and how engineering can contribute to those goals. The CTO has six duties:
Engineers and the product manager need a good relationship so they can share ideas and solutions. This will benefit the team because engineers are often knowledgeable about the inner workings of the product in a way that product managers are not, and so they can often contribute unique ideas about how to build products.
It’s largely up to the product manager to build this relationship. Every day, product managers solicit engineers’ ideas, and engineers ask product managers for clarification on the goals of the product. By being knowledgeable but also soliciting feedback, product managers can turn engineers into true missionaries.
Too often, though, product managers don’t have any experience with or understanding of what engineers are working on, and so the relationship breaks down before it can even get started. This is a big reason why the product manager should understand some computer science as well as some business.
Additionally, if, as a product manager, you don’t know something, it’s better to ask for an explanation than to guess your way through. Engineers will spot the latter strategy, and you’ll lose credibility.
Now that we have discussed how product managers, UX designers, and engineers build a product, we will examine how to market a product.
Marketers are responsible for turning a good product into a commercial success. They are meant to show the best side of the product to potential customers. Some of their responsibilities are:
The marketer is important to the product manager because she knows how to package the product manager’s ideas. Ultimately, the product is only successful if it sells well, and the marketer helps to turn a good idea into a commercial success. This is why product managers have to explain the product in depth to the marketing team. The product manager and the marketer should communicate frequently.
There are several other important people that a product manager might interact with. These interactions depend on the size of the company and the type of the product, but we’ll go over them briefly here.
User researchers, which a lot of bigger companies employ, help product managers get the most benefit from focus groups by helping to write good questions, finding people who will give useful answers, and generally finding better data for the product manager to work with.
Some larger companies also employ analysts. As researchers help with the qualitative side of the focus groups, analysts will help with the quantitative part of the data that product managers get from surveys. These roles have become increasingly popular recently, and sometimes a team might have its own dedicated data analyst. Without someone like this, the product manager basically has to play the role of the analyst.
These people are responsible for creating tests for the product. In most companies, engineers on the team will do this, but larger companies might employ specific test engineers to make sure that the product is working as it should be. These employees can be particularly helpful for engineers, as in writing the tests, they look at the product with an engineer’s capabilities and with a fresh set of eyes, so they can spot problems other engineers may have missed.
The delivery manager is a coordinator who removes obstacles to success for the product manager by scheduling meetings, liaising with other departments, or asking for approval on new initiatives. Sometimes, product managers who lack delivery managers can get so overwhelmed with coordination and an email inbox that is never empty that they are unable to think strategically or holistically.
Compare your company’s product development team structure to the ideal structure described in this summary..
Think about your company’s team structure. What are the similarities with the description of a team structure provided above? What are the differences? (For instance, is the structure flat or hierarchical? How capable is the product manager?)
Are the people and team structure effective? Why or why not?
How could your team structure and employees be more effective?
We’ll now move from mostly discussing the team to discussing the product. Part 3 will discuss how most companies develop products, the problems with this approach, and a better approach focused on vision and strategy.
Most companies develop products by starting with an idea and creating a roadmap: a series of orders handed down by executives that, if completed properly, should result in a desired output. Roadmaps are lists of priorities. Generally, either upper management or the product manager issues a new roadmap every three months or so.
Roadmaps include big picture requests and due dates, but not where engineers need to fix bugs or address smaller technical questions. There are a few reasons why managers think that roadmaps are a good management technique:
Roadmaps are popular for two reasons:
However, roadmaps generally lead to waste. Here’s why:
Both of these issues throw off the timing of the roadmap. If, as previously stated, managers are relying on a roadmap to know when products will be finished, it’s more than 50% likely that the team won’t meet their expectations.
Additionally, roadmaps can lead to morale problems. If engineers—or, in some cases, product managers—feel as if they’re only getting orders, and they’re unable to complete them on time by no fault of their own, they blame their bosses for giving them unreasonable requests.
There is a better approach than roadmapping that maintains the beneficial aspects of the roadmap (again, that employees are properly prioritizing their tasks and bosses are able to schedule around when they think tasks will be finished) while eliminating the weaknesses.
This alternative approach focuses on product vision and product strategy. Each is essential to product development—product vision broadly allows companies to create a better understanding of their goals in building a product, and product strategy helps companies reach those goals. They are more flexible than a roadmap, which is stringent about deadlines and often comes from the top of an organization without input. We’ll now discuss vision and strategy in depth.
Product vision is the overall goal of the company (or, in a large company, a component of the company). It is something that can be achieved only far in the future—somewhere between two and 10 years. Here are 10 principles for creating a product vision:
Strategy is your plan to achieve the product vision. The product strategy can change more than the vision—it’s subject to fluctuations in the market, your team sticking together, or even where you’re competing geographically. There are four criteria for a sound product strategy:
In addition to implementing vision and strategy, employees developing a product can do a better job if they understand the business context. This understanding informs their decision-making, and it helps them to better understand the value of their tasks. At tech companies in particular, business context has two components:
By providing employees with an understanding of the company and freedom to work out the solutions to goals themselves, employees are better able to properly prioritize their tasks. Employees will know even better what to prioritize than in the roadmap scenario, because they’ll understand why their objective is important and then create a strategy to get it done themselves, rather than relying on a strategy from up top that might not be as efficient, because the people at the upper levels of the company might not have a good technical understanding of how to solve problems.
Next, we’ll discuss the benefit of creating a realistic product development schedule or deadline.
Sometimes, especially in the later stages of product development when it’s obvious that customers like the idea, it is in the best interest of companies to set a due date. However, companies have to be sure that this will work—this means making what is called a high-integrity commitment, or a commitment that a team knows that it can fulfill because of research it has already done.
What’s important to note about these commitments is that, unlike roadmap-based commitments, product teams don’t make them too early. There isn’t an exact science to finding high-integrity commitments, but it’s about finding a good balance between executives and stakeholders and product managers and other workers. Once the product managers have figured out how to solve their problem, then it’s possible to set a soft due date on when they can deliver their work.
At this point, we’ve explained how product vision and product strategy lead to success. Now, we’ll consider the importance of creating product principles that guide what you build. When an organization has the same set of principles that govern everyone in it, employees feel they’re being judged on a fair standard.
Product principles can be broken down into “Objectives and Key Results,” or OKR. This is the system that Google has used almost since its inception. The system is meant to empower employees while also properly measuring their progress. (Shortform note: OKR is meant to track a company’s progress against measurable goals.) Here are some things to keep in mind when setting objectives and results metrics:
Individual employees, of course, can and should have their own goals. But the OKRs, again, should be at least product team-wide, and should be uniform across the organization, so that everyone knows that they are being judged on the same broad standard as their counterparts. Naturally, this is more difficult the larger the company is. When a company is scaling up, OKRs are useful, because they’re fairly conducive to scale; you can easily add objectives and new data points to OKRs while your company is growing. During a company’s scaling process, leadership needs to make sure that all OKRs remain aligned toward the same larger goal/vision.
As mentioned in the vision section, “spreading the faith” is essential to success. The more people there are inside and outside the company who believe in your idea, the more likely you are to succeed. On the other hand, if you can’t excite many people about your idea, you’re almost certainly doomed to failure. Here are 10 ways to get employees excited about a product:
Even when teams are functioning properly and leadership is properly overseeing the company, if there are a lot of product teams that are working on different components of the same larger product, it can be difficult to keep everyone on track and aimed at the same goal. There are a few principles to rely on that can help to fix this issue.
After creating a vision and strategy, the next step in product development is discovering products and getting them to market. Once again, the product manager plays a key role. “Discovery” is the process by which a company identifies customer needs or problems and develops products to solve them.
Companies should focus on maintaining and updating the quality of their current products while continuing to experiment with new products and solutions. Usually, good engineers know how to do the former. But many have trouble with the latter. This section will establish a process of continuous discovery. Every part of the company should be involved with product discovery.
What follows are specific techniques used in the discovery process. This section will discuss the techniques of:
Framing helps us identify underlying issues with proposed products. Some product discovery is straightforward—we know there is a specific problem to solve. However, for the more complex questions of discovery, framing is essential. It has two specific goals:
We’ll go over three framing strategies—from an opportunity assessment, which is most helpful when asking simple discovery questions, to a startup canvas, which works for companies trying a completely new product or strategy:
Opportunity assessments answer four questions to determine feasibility:
You’ll use this framing technique for most product discovery. It’s for the simpler questions of discovery.
In the customer letter technique, product managers imagine a letter from a satisfied customer, which helps them better understand their goals. Using the technique, you’ll work backward. Begin by writing a (fictitious) letter from a satisfied customer who has tried your new product. Why does she like it? What problems does it solve? Then, build your discovery strategy around the letter. Ask how do we make this letter come true? How do we solve these problems?
This technique is well-suited to larger projects with overlapping goals because in working backwards, product managers can understand how their goals dovetail into customer satisfaction. A project may attempt to solve multiple problems for a customer in an effort to make her more satisfied overall.
The startup canvas framing technique is useful for quickly highlighting the biggest risks of starting a new company or product line.
(Shortform note: The startup canvas is a one-page template that allows you to examine your concept from various perspectives. Use a section or column of the page to define the problem you’re attempting to solve, and further sections for your solution, the unique value of your idea, and why customers will react well to it. You can add as many sections as necessary.)
Startups have many questions, like how to raise or make money, how to find customers, and how to build a new line/company from scratch. Rather than creating a full business plan, though, you can use the startup canvas as a leaner option.
The biggest risk for startups is generally related to value. You’re looking for something that your customers will buy, but it’s difficult to know whether they will be willing to do so. Plus, if you’re competing in an existing market (which the grand majority of companies, even the new ones, are), your product needs to be substantially better than your competition’s in order for people to feel justified in switching.
Take a look at the market, the big players, the risks, your own product and financial stability, and answer all of the questions in the previous two frames as well. Once you’ve identified your risks, whether the effort is feasible will become clear.
Step two in the product discovery process is figuring out how to create the infrastructure necessary to get a product to market. This is the planning stage of the process. Useful techniques include story mapping and customer discovery.
Story mapping is the creation of a more complex “to do” list. It’s a simple but useful technique that helps companies plan how to build products.
Create a 2D map of your product. From left to right along a line, place the activities your user can do on your product, basically in the order that they’ll do them. You might have dots like “open the app” or “sign in” near the beginning and “edit their profile” closer to the middle/end. Vertically, add the tasks necessary to make all of these activities work. The more complex the activity, the higher the vertical bar will be. This way, you can clearly see what to accomplish and what parts of your idea will be more or less difficult. As customers provide feedback on prototypes, you can add that to the map.
Customer discovery is a technique that helps to find reference customers, or customers who are loyal to the product. These customers are the lifeblood of any company—they help you determine how to market the product, and they help spread the word about it to similar customers. They are people who would pay for a final version of your product and like it enough that they would recommend it to friends. The process is generally more complex than story mapping.
As few as six reference customers can help your company grow exponentially. Before fully launching, a company should recruit between six and eight of these people. The best reference customers share these characteristics:
Recruit these customers either from existing users who have a problem they need to have solved, or from surveys that determine whether potential customers could use your product. Once you find these people, treat them like colleagues or partners rather than test subjects. You both need one another equally.
Prospective reference customers will be excited by the idea of having some input into the product. The product team can use the reference customers to test out their products before launch. The product manager needs to identify one solution that solves the problem that all reference customers had going into the test. Otherwise, it’s possible the solution will be too specifically tailored.
All of this is a lot of effort, especially for the product manager running all of this. But if you have six people at the end of it whose problems are truly solved and who are willing to go to bat for the company, this almost necessarily means that there are a lot more people in the target market who would benefit significantly from this.
Step 3 in the product discovery process is generating ideas for products and product features.
Interviewing current or past customers can help the team generate ideas, because customers who regularly use the product may notice issues with it and consider how it can be better. If we know, from the customer, what our company needs to do to make them use our service, they’ve almost generated some ideas for solutions for us. In every interview, the interviewer should consider the following questions:
Conduct many interviews with potential customers to help get the answers to these questions. Additionally, be open to hearing their answers, rather than advancing your own agenda. Finally, if possible, it is helpful to do these interviews in the subject’s home or a place where they feel comfortable. This will make them much more open to you.
At least one engineer, the product designer, and the product manager should attend these interviews. The product designer can thrive in interviews, because their focus is designing usable products.
After the interview, the team should debrief on what they learned right away. And once the team has the answers to the above questions, it’s much easier to generate good design ideas.
The idea behind concierge testing is that the company becomes the “concierge” for potential customers, helping them with their needs. After interviews with customers, product teams know their needs. The product teams then focus on helping specific customers with their problems. By trying to solve specific problems, the product teams are able to better understand these issues and how they might relate to more than one customer.
Again, an engineer, the product designer, and the product manager should do this together and debrief on their experience afterward.
In addition to generating ideas for designing new products, companies need to generate ideas for improving existing products. One way to do this is by observing how customers use a product, which may be different from the way its designers intended.
eBay’s “everything else” marketplace is an example. When eBay launched, they wanted to be a website that facilitated transactions mostly for collectibles and electronics. But they also created an “other” or “everything else” tab where people could buy/sell (mostly) whatever they wanted. EBay didn’t realize that their customers would sell items like cars on their site. But today, eBay has a huge market share in the used car industry.
EBay allowed their customers to behave in ways that they didn’t expect or prepare for with their service. By doing so, they grew their business exponentially, and in response to customer demand, they built up more infrastructure around customer interests like the used car market.
Obviously, this strategy only works in specific cases. If your product is ultra-targeted, it’s more difficult to pull off. But if done correctly, as we’ve seen, it can reap huge dividends.
The final strategy for ideation is holding “hack days,” in which the company’s engineers, product managers, product designers, and senior executives spend the day brainstorming and solving problems. Hack days may focus on a specific issue or be unstructured.
The benefits include:
The next step in the discovery process after generating ideas is prototyping. People often think of prototypes as nearly complete products, but less elaborate prototypes are more useful and less expensive to produce.
While prototypes do take much less time, money, and energy than the final product to create, they still force teams to take the ideas in their heads and put them to work. They are a good balance between putting too much effort and too little effort into an idea.
This section discusses four types of prototypes.
Sometimes engineers aren’t sure whether they can build a tech product—for instance, because of concerns like scale or whether it is possible to successfully code the version of the product they have in mind. The way to answer the question is to build a feasibility prototype.
In creating a feasibility prototype, engineers typically write just enough code for the project to know that they can complete it. The code doesn’t need to be perfect—it’s unlikely that it will go into the final build.
The feasibility prototype is done by the engineers and is for the engineers. The product manager needs to concern herself with it only insofar as she ultimately decides whether to move forward with it.
While feasibility prototypes involve writing a minimal amount of working code, user prototypes are simulations of the final product. They’re not actually functional—for example, a customer wouldn’t be able to buy anything via a user prototype for an online marketplace like eBay.
The simplest user prototypes often don’t look anything like the final product and serve only as the skeleton. Generally, simple user prototypes are for internal use only—to help the team visualize the product.
In contrast, more complex user prototypes called high-fidelity user prototypes look and feel like the final product. They take longer to create, and they can be used both internally and externally on test subjects. However, high-fidelity user prototypes aren’t live, and can still be fairly basic—for example, a search function might generate only a few results, or an algorithm might still need building.
A company pursuing a risky idea can get real data on whether a product will sell while in the discovery phase by creating a live-data prototype.
This prototype is a pared-down version of the final product—it’s not scalable, can’t take much traffic, and doesn’t have any SEO or analytics associated with it, but it does function. Test users can use the product and provide qualitative data on how they felt and quantitative data on how they used it and how well it worked.
Remember though, that at this point, the product still has a long way to go—the engineers have likely done less than 10% of the work needed for success.
The final prototype is the hybrid, which is a combination of the first three types. A “Wizard of Oz” prototype is an example of a hybrid prototype—the name comes from what’s behind the curtain. Behind the product’s front-end user experience, an engineer manually performs the tasks that the front-end says the product can do. This saves time on automation, and can provide a sense of what people think of the product.
Most hybrid prototypes are the least scalable of the four types, as they’re meant to be built quickly and provide customer feedback without requiring unnecessary engineering work.
Testing is the final step in the discovery process—it’s meant to once and for all separate the good ideas from the bad. It should address the four risks of product discovery:
The answer to all of these questions must be “yes” before a company moves on to creating the product. A company can’t know whether the product has a market niche, or whether people will buy it, with 100% certainty—which is why some products flop. But tech companies can validate many ideas during the discovery process. Most of these ideas won’t work out, but failures won’t be a large blow if companies use prototypes and focus groups to limit the time and resources spent. Transparency and communication are critical to the testing process as well—a sales executive might realize that an idea doesn’t meet the standard of business viability, whereas an engineer might conclusively say that building a product isn’t feasible.
Determining whether a product has value or a market niche (commercial viability) is one of the most important tests. Customers will generally only buy a new product if it’s significantly more valuable than what they’re currently using. There are three ways to test for value: the fake door demand test, the qualitative value test, and the quantitative value test.
The fake door demand test determines whether there’s a demand for your product. The test works like this: You add your idea for a product to your company’s already-live system. If it’s a new feature on your company’s app—you’d put the feature link where it would be if you were to launch it. But clicking on it would take the customer to a page recruiting test subjects for the feature. Similarly, for a new product, you’d build a landing page that links the potential customer to a recruiting page. You can track the number of clicks on the feature or product to see if demand exists, and you can find some new test subjects.
This type of value testing will show why a product has value or doesn’t. If the latter is the case, it will also show what a company can do to fix its value problem (if it’s fixable). You’re not proving that your product is good here. Rather, you’re learning quickly. This type of testing, according to Cagan, is the most important part of the discovery process. Here’s how it works:
It’s almost certain you’ll get different answers from different test subjects. Figure out why they feel differently from one another. Product managers should be at every qualitative test to help understand the differences. Some people are bound to be uninterested in the product. But if most test subjects aren’t interested, it might not work. Even if many test subjects are interested, it’s useful to listen to those who aren’t so you can understand what to fix.
The third type of value testing—quantitative testing—is generally done with live-data prototypes, which allow the company to acquire enough data for statistically significant results. While qualitative testing is about learning, quantitative testing is about building evidence. Generally, larger companies do more quantitative testing because they have more resources to do so and they’re more risk averse. They may also have more site traffic to build their quantitative tests around.
The best type of quantitative test is an A/B test. In this test, 99% of users use the “A” version of the product, or the version that’s already publicly available. The other 1% uses the “B” version, or the product that’s in the discovery stage. The company then collects data on the behavior of the two groups.
Some companies that don’t have enough traffic for an A/B test will use an invite only test. This is similar, but instead of selecting a random and small group of users, they invite users to use the “B” version. Unfortunately, though, the data isn’t as reliable because subjects opted in to using a new version.
Advanced analytics have changed the way companies can go about their product discovery. They help companies measure progress and understand much more about customer behavior, and for this reason, more companies are using them.
(Shortform Note: Michael Lewis’s Moneyball: The Art of Winning an Unfair Game explores the differences between qualitative and quantitative analytics through the lens of baseball. Read the Shortform summary here.)
Usability is the second of the four risks that testing must address in the discovery process. Usability testing tests whether users understand how to use your product by putting an early prototype in front of them and asking them to use it. This gives companies an idea of how potential users approach the product, how they understand the UX design, and whether they have functionality concerns that you may not have spotted. The usability testing process is as follows:
First, recruit a group of test subjects. If you have a customer discovery program (as described earlier), use that for your subjects. Otherwise, you can advertise via Craigslist or your company website, or send emails to an email list for current customers. Trade shows can also be useful for finding test subjects. Generally, especially if you’re doing the testing in your office, you’ll pay the subjects for their time.
Next, prepare the test. As you might expect, most usability testing happens using a high-fidelity user prototype, because the test subjects should have most of the experience of using the product before they make a judgment on whether or not they understand it.
Before administering the test, decide what you want out of it and what you want the test subjects to do. If you’re designing a betting app, for example, you’ll look for test subjects navigating the app, placing (fake) bets, depositing money, and so on.
One person should administer the test and another should be responsible only for notetaking. Once again, the product manager, product designer, and an engineer should be present to see the results. If you don’t have an office that works for this sort of testing, it’s easy to do in a coffee shop, or even in your test subject’s office. This can sometimes even be useful, because you’ll better understand the computer/phone setup that your test subject has and how they’d interact with your product on their own time.
Now, you’re ready to administer the test. Here are some steps to do so:
After the test, a team member should immediately write a summary of what happened using the notes. The more information from the test the better.
The third risk to be explored by testing is feasibility, or whether engineers can actually build a product. Feasibility testing asks engineers to determine whether it is possible for a product to be built either by building a feasibility prototype or by building enough of the product that they are confident they can build the rest. Feasibility testing is also asking whether the current engineers on the team have the skills to do so, whether the company has enough time and resources to build the product, whether the product can be scaled, and even whether the company has the raw materials to build the product if it’s hardware.
Feasibility testing is essential because if a product team devotes significant time and energy to a product and then finds out it can’t be completed, they’ve wasted all of that time.
At this stage in discovery, most engineers will decide that the answer to the above is “yes, this is feasible.” Occasionally, though, if engineers are not sure if something is feasible, they need time to investigate it. In this instance, engineers build a feasibility prototype to answer any outstanding questions. As we’ve learned, these prototypes don’t take much time or energy generally, but the product manager still has to decide whether it’s worth the effort. Generally, the answer will be yes, and often, while considering the question of feasibility and dealing directly with the product without other distractions for a day or two, engineers come back not only saying it’s feasible, but offering ideas to make the product better.
The fourth risk that testing explores is business viability, or whether the product will be profitable. This is the final hurdle before moving on with product creation. The product manager shows departments throughout the company the business model they have created of the product, and these departments in turn analyze the business model for any potential problems. If they don’t see any, they will sign off on the project. Many stakeholders need to sign off before a product has business viability—here are some of the most common.
The marketing department is concerned primarily with driving sales. They will be looking for a product that they can easily explain to customers and one that will have a lasting impact and relevance in the marketplace.
While the marketers are the ones trying to drive people to the product, the sales team are the ones getting pen to paper (or hand to credit card or keyboard) and completing sales. Especially if your company has a direct sales team, they will be interested in whether they have a product that they can get off the shelves and one that they can make good money on.
Product managers should be aware of a company’s customer success strategy while they are building their product. A customer success strategy is how companies have decided to help their customers through using the product. Some companies use a high-touch strategy, meaning that they provide significant support for their customers, while others provide a low-touch strategy, which is hands off. The product needs to fit with the company’s strategy.
The finance department will ask whether the company can afford to produce and sell the product. Additionally, they’ll have a good sense of investor expectations—it’s useful to talk through the costs associated with the product (and the benefits) with someone in the finance department.
Project managers must address legal concerns before they can launch a product. Companies that don’t consider whether there are potential privacy violations, intellectual property violations, or compliance violations may be opening themselves up to legal action that can cost the company money and reputation.
The product manager needs to be clear that the product is secure before launch. The easiest way for a tech company to enter into a downward spiral is to compromise the security of its users’ information.
Finally, the product manager needs to get approval from leadership. The leadership of the company has to be satisfied that all of the previous business viability conditions have been met before they give their sign-off. Hopefully, they’ve been involved for much of the process, but no matter what, they’re always aware from experience of the risks associated with launching a product.
This exercise will help you better understand how to create prototypes.
Think about a technology product you use often. How would you pitch that technology product to test subjects who haven’t seen it before?
What kind of prototype would you use and why (a feasibility prototype, user prototype, live-action prototype, or hybrid prototype)?
What would you hope to see at your demonstration that would suggest to you that the test subjects like the prototype and would actually use the product?
Implementing the discovery method of product development often requires changing company culture. This section provides tools and tips for overcoming resistance and aversion to risk on the way to building a more successful culture.
First, we’ll discuss why some teams have trouble innovating and using the discovery process. Then, we’ll examine ways to get employees interested in the discovery process and weaned off of roadmaps, including two specific strategies called discovery sprints and pilot teams.
Companies that constantly innovate share many of the same characteristics. To build a strong culture, companies must innovate and execute. When companies have trouble with innovation it means they lack some of the following attributes:
Additionally, as teams grow, they sometimes lose velocity, or an ability to innovate quickly. There are a few more success attributes that are specific to speed:
It’s not easy to change a company’s culture so that it takes on all of the above attributes. But there are some strategies that can help employees get interested in the discovery process, which in turn will lead to an improvement in a company’s ability to innovate.
Discovery sprints are a way to get more people involved in discovery. Teams are asked to pause their work for a week and all focus on solving a problem, such as why users are spending very little time on their website.
During the week, the team should consider all kinds of product ideas to help solve the chosen problem. By the end of the week, the team should be able to present prototypes for a few chosen ideas to customers. This may seem ambitious, but if the whole team is working together on only this, it’s possible.
The sprints are most useful in two situations:
Some companies hire discovery coaches, or former successful product managers, to help shepherd them through the discovery sprint.
Another way to get people involved in discovery and thus change the culture is by introducing pilot teams. Pilot teams are subgroups that work on an early rollout before the rest of the team. If one group is working on a rollout and siloed from the rest of the team, the rest of the team can serve in a similar role as test subjects.
Pilot teams work by the same logic that an early or limited rollout works. Have one product team try new strategies like the discovery techniques outlined earlier and observe how the team does. Look to see if the chosen team is doing better with the new strategies than the other teams are with the old strategies. If the whole company sees that the new strategies work better, even the people who are resistant to change will be easier to bring along. Sometimes, the new strategies aren’t successful, but give these experiments time before abandoning them altogether.
As we’ve discussed, many teams are trying to leave the roadmap strategy behind, but are held up by some resistance to change and a lack of understanding about the new methods. The best way to wean a company off of roadmaps is to help employees understand their outcomes. Give roadmaps a six-month trial period in which the team studies the outcomes of the roadmaps. Usually, for the reasons we’ve outlined in Part 3, roadmaps don’t work well. Eventually, companies will change roadmaps from prioritizing launch dates to prioritizing results and the discovery process. In doing so, the team will wean itself off of roadmaps.
Continuing the success of the discovery process is more difficult as companies get bigger. Companies have to manage more stakeholders—including marketing, sales, finance, legal, and leadership—who might not be familiar with or interested in the discovery process. The best way for product managers to scale the success of the discovery process is to maintain good relationships with stakeholders.
The product manager has to sincerely convince each stakeholder that the manager understands the risks she’s taking in discovery and why the innovation is likely to pay off.
While product discovery is about figuring out which products will be successful and which won’t, the process also often delivers larger lessons about the company. This is especially true if the product manager is able to develop good relationships with multiple stakeholders and understand their needs.
It may become clear that the company needs to build up their test user program or that they should hire more engineers. Or, a product team could learn something about the larger product that’s useful for everyone to hear. It’s useful to have a brief (15-30 minutes) all-hands meeting every month or so to share lessons. Each product team should share what they’ve learned. This helps product teams nail down the big takeaways from their recent work, and it spreads this knowledge throughout the company. As knowledge spreads, all stakeholders can learn more about the virtues of the discovery process.