Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)

by Marty Cagan

The first truth is that at least half of our ideas are just not going to work.

The first truth is that at least half of our ideas are just not going to work. There are many reasons for an idea to not work out. The most common is that customers just aren't as excited about this idea as we are. So, they choose not to use it. Sometimes they want to use it and they try it out, but the product is so complicated that it's simply more trouble than it's worth, so users again choose not to use it.

If that's not bad enough, the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that time to money.

Maybe the biggest missed opportunity in this model is the fact that engineering gets brought in way too late. We say if you're just using your engineers to code, you're only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.

The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed. The irony is that many teams believe they're applying Lean principles; yet, they follow this basic process I've just described.

To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week.

Fight your temptation to provide your designer with your own design ideas. Give your designer as much room as possible to solve the design challenges him or herself.

Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What's not okay is to have a team of engineers in which none of them wants to engage in discovery activities.

The hallmark of a great CTO is a commitment to continually strive for technology as a strategic enabler for the business and the products. Removing technology as a barrier, as well as broadening the art of the possible for business and product leaders, is the overarching objective.

One of the key themes of this book is focusing on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results.

Note that our delivery managers are key to determining any commitment dates. Just because your engineers believe something might take only two weeks to build and deliver, what if that team is already occupied on other work, and they can't start on this work for another month? The delivery managers track these commitments and dependencies.

The product vision describes the future we are trying to create, typically somewhere between two and five years out. For hardware or device‐centric companies, it's usually five to 10 years out.

The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.

Most important, the product vision should be inspiring, and the product strategy should be focused.

We can't ignore the market, but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them.

The first principle is fundamentally about how to empower and motivate people to get them to do their best work, and the second is about how to meaningfully measure progress.

Learn how to give a great demo. This is an especially important skill to use with customers and key execs. We're not trying to teach them how to operate the product, and we're not trying to do a user test on them. We're trying to show them the value of what we're building. A demo is not training, and it's not a test. It's a persuasive tool. Get really, really good at it.

Back in 2003—a full four years before the debut of the iPhone—a young product manager at the BBC, Alex Pressland, had just finished leading a product effort that enabled the BBC to be one of the first media companies in the world to syndicate content.

You might also recognize this problem in another guise. Many teams get into a lot of grief with the concept of a minimum viable product (MVP) because on the one hand we are very motivated to get this out in front of customers fast to get feedback and learn. And, on the other hand, when we do get out there fast, people feel like this so‐called product is an embarrassment to the brand and the company.

But here's the key. If you want to discover great products, it really is essential that you get your ideas in front of real users and customers early and often.

If you want to deliver great products, you want to use best practices for engineering and try not to override the engineers' concerns.

We know we can't count on our customers (or our executives or stakeholders) to tell us what to build. Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it. It's not that customers or our executives are necessarily wrong; it's just that it's our job to make sure the solution we deliver solves the underlying problem.

Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it.

The most important thing is to establish compelling value. It's all hard, but the hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use. We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing. As a result, this is generally where we'll need to spend most of our discovery time.

We must validate our ideas on real users and customers. One of the most common traps in product is to believe that we can anticipate our customer's actual response to our products. We might be basing that on actual customer research or on our own experiences, but in any case, we know today that we must validate our actual ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, and not after.

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.

Further, your job as product manager is not to put in the features that all six companies request.

But we are looking for those customers that are so hungry and desperate for a solution that they will absolutely make time for this. Every market has this segment.

Think of these early prospective customers as development partners. You're in this together. You need to treat them as colleagues—open the kimono, you are helping each other. You'll find that the relationships you create can last for many years.

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.

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.

However, the reality is that this is often not the case. Or, if customer interviews are happening, the product manager is not present, so the learnings are not understood viscerally or taken as seriously as they need to be (see Discovery Principle #10 on shared learning).

Wizard of Oz prototype combines the front‐end user experience of a high‐fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation.

A Wizard of Oz prototype is absolutely not scalable, and we would never send any significant amount of traffic to this. But the benefit from our perspective is that we can create this very quickly and easily, and from the user's perspective, it looks and behaves like a real product.

Act like a parrot. This helps in many ways. First, 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.

The customer must perceive your product to be substantially better to motivate them to buy your product and then wade through the pain and obstacles of migrating from their old solution.

You need to help protect your company's revenue, reputation, employees, and customers you've worked so hard to earn.

For example, a direct sales channel is very expensive, and this requires a high‐value product and price point. Or, you may have built up a sales channel with a certain set of skills, and if your new product requires a very different set of skills and knowledge, your sales force may completely reject the product.

Some tech companies have what's referred to as a high‐touch model of helping their customers, and some have a low‐touch model. You need to understand what your company's customer success strategy is, and you need to ensure that your products are aligned with that strategy.

After working with more than 100 product teams, and refining their methods as they learned what worked well and what didn't, the GV team decided to share their learnings in a book. The book is titled, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp, John Zeratsky, and Braden Kowitz.

With a grateful nod to Ben Horowitz's classic post “Good Product Manager/Bad Product Manager,”

Good teams have a compelling product vision that they pursue with a missionary‐like passion. Bad teams are mercenaries.

Good teams get their inspiration and product ideas from their vision and objectives, from observing customers' struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.

Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.

Good teams have product, design, and engineering sit side by side, and they embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduling meetings.

Good teams are constantly trying out new ideas to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test.

Good teams ensure that their engineers have time to try out the prototypes in discovery every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.

Good teams know that many of their favorite ideas won't end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what's on the roadmap, and are satisfied with meeting dates and ensuring quality.

Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.

Good teams instrument their work so they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a nice to have.