INSPIRED How to Create Tech Products Customers Love

The most important point for technology companies: if you stop innovating, you will die.

Fall in love with the problem, not the solution.

Successful products are not only loved by your customers, but they work for your business.

We need teams of missionaries, not teams of mercenaries.

We need teams of missionaries, not teams of mercenaries.

Learning More

The Silicon Valley Product Group website (www.svpg.com) is designed as a free and open resource where we share our latest thoughts and learnings from the world of technology-powered products.

You will also find examples of the techniques described in the book (see www.svpg.com/examples) as well as a current recommended reading list (see www.svpg.com/recommended-reading).

Top Reasons for Loss of Innovation

(...)

Organizations that lose the ability to innovate at scale are inevitably missing one or more of the following attributes:

1. Customer-centric culture. (...)

2. Compelling product vision. (...)

3. Focused product strategy. (...)

4. Strong product managers. (...)

5. Stable product teams. (...)

6. Engineers in discovery. (...)

7. Corporate courage. (...)

8. Empowered product teams. (...)

9. Product mindset. (...)

10. Time to innovate. (...)

Communicating Product Learnings

(...) at a company all-hands or similar meeting every week or two, to take 15 to 30 minutes to highlight what has been learned in product discovery across the various product teams.

Note that this is meant to cover the bigger learnings and not the minor things— what worked, what didn't work, and what the teams are planning to try the following week.

This update needs to move fast and kept at the big learnings level,

User Test versus Product Demo versus Walkthrough

(...) there are three very different techniques for showing the prototype, and you have to be careful to use the right technique for the right situation.

A user test is when we test our product ideas on real users and customers. It is a qualitative usability and value-testing technique, and we let the user drive. The purpose is to test the usability and value of the prototype or product.

A product demo is when you sell your product to prospective users and customers, or evangelize your product across your company. This is a sales or persuasive tool. Product marketing usually creates a carefully scripted product demo, but the product manager will occasionally be asked to give the product demo-especially with high-value customers or execs. In this case, the product manager does the driving. The purpose is to show off the value of the prototype or product.

A walkthrough is when you show your prototype to a stakeholder and you want to make sure they see and note absolutely everything that might be a concern.

The purpose is to give the stakeholder every opportunity to spot a problem. The product manager usually drives, but if the stakeholder would like to play with the prototype we are happy to let them. You are not trying to sell them anything, you're not trying to test on them, and you're definitely not trying to hide anything from them. (...)

Demand Testing Techniques

(...)

The demand-testing technique is called a fake door demand test. The idea is that we put the button or menu item into the user experience exactly where we believe it should be. But, when the user clicks that button, rather than taking the user to the new feature, it instead takes the user to a special page that explains that you are studying the possibility of adding this new feature, and you are seeking customers to talk to about this. The page also provides a way for the user to volunteer (by providing their e-mail or phone number, for example).

(...)

In practice, the demand is usually not the problem. People do sign up for our trial.

The problem is that they try out our product and they don't get excited about it—at least not excited enough to switch from what they currently use. (...)

Preparing the Test

(...) do usability testing with a high-fidelity user prototype. (...) for the value testing that typically follows usability testing, we need the product to be more realistic (...)

(...) do a usability and/or value test, it's with the product manager, the product designer, and one of the engineers from the team (from those that like to attend these).

(...) concentrate on the primary tasks—the ones that users will do most of the time.

(...) Good product managers know they will get the product wrong initially and that nobody gets it right the first time.

• (...) have one person administer the usability test and another person taking notes.

(...)

The other environment that works really well is your customer's office. It can be time consuming to do, but even 30 minutes in their office can tell you a lot.
They are masters of their domain and often very talkative. In addition, all the cues are there to remind them of how they might use the product. You can also learn from seeing what their office looks like. How big is their monitor? How fast is their computer and network connectivity? How do they communicate with their colleagues on their work tasks?

• (...) view the remote usability testing as a supplement rather than a replacement.

Testing Your Prototype

• (...) make sure to tell your subject that this is just a prototype, it's a very early product idea, and it's not real. Explain that she won't be hurting your feelings by giving her candid feedback, good or bad. You're testing the ideas in the prototype, you're not testing her. (...)

(...) before you jump into your tasks: See if they can tell from the landing page of your prototype what it is that you do, and especially what might be valuable or appealing to them. Again, once they jump into tasks, you'll lose that first-time visitor context (...)

(...) do everything you can to keep your users in use mode and out of critique mode.

(...) If users knew what they really wanted, software would be a lot easier to create. So, watch what they do more than what they say.

During the testing, the main skill you have to learn is to keep quiet. (...)

(...) cases you're looking for: (1) the user got through the task with no problem at all and no help; (2) the user struggled and moaned a bit, but he eventually got through it; or (3) he got so frustrated he gave up. Sometimes people will give up quickly, so you may need to encourage them to keep trying a bit longer. (...)

(...) avoid giving any help or leading the witness in any way.
If you see the user scrolling the page up and down and clearly looking for something, it's okay to ask the user what specifically she's looking for, as that information is very valuable to you. Some people ask users to keep a running narration of what they're thinking, but I find this tends to put people in critique mode, as it's not a natural behavior.

Act like a parrot. (...) it helps avoid leading. If they're quiet and you really can't stand it because you're uncomfortable, tell them what they're doing: "I see that you're looking at the list on the right." This will prompt them to tell you what they're trying to do, what they're looking for, or whatever it may be. If they ask a question, rather than giving a leading answer, you can play back the question to them. They ask, "Will clicking on this make a new entry?" and you ask in return, "You're wondering if clicking on this will make a new entry?" Usually, they will take it from there because they'll want to answer your question (...)

Summarizing the Learning

(...) It might be nomenclature, flow, visual design issues, or mental model issues, but as soon as you think you've identified an issue, just fix it in the prototype. There's no law that says you have to keep the test identical for all of your test subjects. (...) We're not trying to prove anything here; we're just trying to learn quickly.

(...) usually either the product manager or the designer-writes up a short summary e-mail of key learnings and sends it out to the product team. But forget big reports that take a long time to write, are seldom read,

Discovery Prototyping Techniques

(...)

Feasibility Prototypes

(...) The idea is for the developer to write just enough code to be able to address the feasibility risk.

User Prototypes

(...)

Live-Data Prototypes

(...) The main purpose of a live-data prototype is to collect actual data so we can prove something, or at least gather some evidence-normally to find out whether an idea (a feature, a design approach, a workflow) really works.

Concierge Test Technique

(...)

The idea is that we do the customer's job for them—manually and personally. Just as if you went to a hotel concierge and asked if he could find you some theater tickets to a popular show. (...)

A concierge test requires going out to the actual users and customers and asking them to show you how they work so that you can learn how to do their job, and so that you can work on providing them a much better solution.

Like the principle of shared learning, it is most valuable if the product manager, the product designer, and one of the engineers does the concierge test.

Customer Interviews

(...) This is one of the most powerful and important skills for any product manager and very often the source or inspiration for many breakthrough product ideas.

(...) Here's what I'm always trying to understand:

• Are your customers who you think they are?

• Do they really have the problems you think they have?

• How does the customer solve this problem today?

• What would be required for them to switch?

(...) tips for getting the most out of these learning opportunities:

Frequency. Establish a regular cadence of customer interviews. (...) two to three hours of customer interviews per week, every week.

Purpose. You are not trying to prove anything during these interviews, one way or the other. You're just trying to understand and learn quickly.

(...)

Location. It's always amazing to see customers in their native habitat. There's so much to learn just by observing their environment. (...)

Preparation. Be clear beforehand what problem it is you think they have, and think about how you'll either confirm or contradict that.

Who should attend. My favorite is to bring three people to these interviews: the product manager, the product designer, and one of the engineers from the team (we normally rotate among those that want to attend). Usually, the designer drives (because they ve usually been trained how to do this well), the product manager takes notes, and the developer observes.

Interview. Work to keep things natural and informal, ask open-ended questions, and try to learn what they're doing today (not so much what they wish they were doing, although that's also interesting).

Afterward. Debrief with your colleagues to see if you've all heard the same things and had the same learnings. (...)

(...) you don't have to wrap up after the interview-you can follow it up with a user test of your latest product ideas.

Discovery Ideation Techniques

(...) Remarkably, in the vast majority of companies (not the ones that are good at product), the actual product teams don't do much ideation themselves. This is because what's really going on is that the ideas are already handed to the product teams in the form of prioritized features on product roadmaps, where most of the items on those roadmaps are coming either from requests from big customers (or prospective customers), or from company stakeholders or execs. Unfortunately, these are rarely the quality of ideas we're looking for.

Defining Product/Market Fit

(...) One of the most common techniques for assessing product/market fit is known as the Sean Ellis test. This involves surveying your users (those in your target market that have used the product recently, at least a couple times, and you know from the analytics that they've at least made it through to the core value of the product) and asking them how they'd feel if they could no longer use this product. (The choices are "very disappointed," "somewhat disappointed," "don't care," and "no longer relevant because I no longer use."). The general rule of thumb is that if more than 40 percent of the users would be "very disappointed," then there's a good chance you're at product/market fit.

(...) once we have those six reference customers, we can aggressively and effectively sell that product to other customers in that market.

Customer Discovery Program Technique

(...) in this chapter, I talk about what I consider one of the most powerful techniques we have to ensure and prove we have a strong, viable product (...)

The Power of Reference Customers

First, we need to talk about the nearly magical power of a happy reference customer.

(...) This is a real customer (not friends or family), who is running your product in production (not a trial or prototype), who has paid real money for the product (it wasn't given away to entice them to use it), and, most important, who is willing to tell others how much they love your product (voluntarily and sincerely).

(...) this technique takes substantial effort, primarily on the part of the product manager. I wish it were easier. But I will also say that if you do this technique, I consider it the single best leading indicator of future product success.

(...) There are four main variations of this technique for four different situations:

1. Building products for businesses

2. Building platform products (e.g., public APIs)

3. Building customer-enabling tools used by employees of your company

4. Building products for consumers

The core concept is the same for all four variations, but there are some differences.

I'll describe the variation for businesses first and then describe the differences for each of the other uses.

(...) the idea is to find six similar customers. If you end up targeting two or three customers from two or three different markets, this program will not give you the focus you want and need.

(...) Once we have those reference customers for that initial target market, we can move on to expanding the product to meet the needs of the next target market.

(...) We are looking for prospective customers that truly feel the pain and are near desperate for the solution we want to build. If they could find a solution that worked for them elsewhere, they would have already bought it.

However, it's also important we screen out technologists. These people are mainly interested because of the technology, not because they desperately need the business value.

We need them to have people and time willing to work closely with us. They need to be willing to spend time with the product team, testing out early prototypes and helping the team ensure the product works well for them.

(...) Coming up with the right set is normally something the product manager does in tight collaboration with the product marketing manager.

It's critical to explain to each prospective member of the program that your job is to come up with a general product —something your company can successfully sell to a large number of customers. You're not trying to build a custom solution that only works for that one company (and they wouldn't want that in any case as they would be left with unsupported, dead-end software). You are, however, deeply committed to coming up with a product that works extremely well for them and just a handful of other companies.

(...) Your job is to dive deep with each of the six customers and identify a single solution that works well for all six customers.

(...) then it's very possible you're chasing a problem that isn't that important, and you will almost certainly have a very hard time selling this product. This is one of the very first reality checks (aka demand validation) to make sure you're spending your time on something worthwhile. If customers aren't interested in this problem, you may want to rethink your plans.

(...) Think of these early prospective customers as development partners. You're in this together. You need to treat them as colleagues (...)

Story Map Technique

(...) These are two-dimensional maps, in which major user activities are arrayed along the horizontal dimension, loosely ordered by time from left to right. So, if there are a dozen major user activities, they would be along the top from left to right, generally in the order you would do them—or at least, if you were describing the overall system to someone else, the order in which you'd describe them.

Along the vertical dimension, we have a progressive level of detail. As we flesh out each major activity into sets of user tasks, we add stories for each of those tasks. The critical tasks are higher vertically than the optional tasks.

(...) Many teams I know consider a high-fidelity user prototype and a story map as their go-to techniques.

Another must-read book for product managers: User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton (O'Reilly Media, 2014).

Discovery Planning Techniques

(...) two of my favorite discovery-planning techniques. One is simple (story maps), and the other is fairly complicated (customer discovery program), but they are both remarkably powerful and effective.

The Biggest Risk

(...)

It's human nature for people to focus more on those areas they feel they can control and are knowledgeable about.

I think this is at least partly because risk is subjective and hard to quantify. So, depending on your perspective, you may think some risk is secondary when I think it is primary. (...)

You're probably thinking that I'm speaking of market risk-that the new product is focused on solving a problem that customers just don't care enough about. This is a very real risk, and one that's responsible for its share of failed efforts, but I argue this is not usually the most significant risk. (...)

I believe the major risk facing most efforts is value risk. On a startup canvas, this shows up under solution risk-discovering a compelling solution to customers. A solution that your customers will choose to buy and use.

This is generally hard enough but realize that to get someone to switch to our new product, it's not enough that it's comparable (sometimes referred to as feature parity), it must be demonstrably and substantially better. This is a high bar.

(...) you need to make sure you primarily use your time to discover a winning solution.

(...) you don't need to spend your time doing pricing optimization testing, sales tools, marketing programs, and cutting costs, until and unless you have discovered a truly valuable product.

Startup Canvas Technique

(...) another especially difficult situation requires a more comprehensive framing technique. This is an early stage startup, where you are trying to figure out a new product that can power a new business, or, for those that work at an enterprise size company, when you re asked to tackle an all-new business opportunity for the company. (...)

You're not being asked to improve an existing product, you're being asked to invent an entirely new product.

For decades, people would create thick business plans to try to highlight these topics and how they intended to tackle them. But many people, including me, have written about the many reasons those old business plans were often more harmful than helpful.

A startup canvas, its close cousins the business model canvas, and the lean canvas are intended to be lightweight tools to call out these risks early and encourage the team to tackle them up front.

Customer Letter Technique

(...) there are a few techniques that are central to how Amazon builds product, and one of them is referred to as the working backward process, where you start the effort with a pretend press release.

(...) The idea is that the product manager frames the work ahead of the team by writing an imagined press release of what it would be like once this product launches. How does it improve the life of our customers? What are the real benefits to them? You've all read a press release before—the only difference is that this is entirely imagined. It is describing a future state we want to create.

(...) if people don't see the value after reading the press release, then the product manager has more work to do, or perhaps should reconsider the effort.

(...) It's only validating demand or value with your colleagues rather than with real customers, however, so I think of it primarily as a framing technique.

(...) a former long-time Amazonian who joined Nordstrom a couple of years ago, shared with me a variation of this technique that was developed and refined at Nordstrom.

The idea is that rather than communicate the benefits in a press release format, you describe them in the format of a customer letter written from the hypothetical perspective of one of your product's well-defined user or customer personas.

The letter-sent to the CEO from a very happy and impressed customer-explains why he or she is so happy and grateful for the new product or redesign. The customer describes how it has changed or improved his or her life. The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business.

Opportunity Assessment Technique

(...) The idea is to answer four key questions about the discovery work you are about to undertake:

1. What business objective is this work intended to address? (Objective)

2. How will you know if you've succeeded? (Key results)

3. What problem will this solve for our customers? (Customer problem)

4. What type of customer are we focused on? (Target market)