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

by Marty Cagan

But soon we began to ask ourselves some very important questions: Who decides what products we should build? How do they decide? How do they know that what we build will be useful?

It doesn't matter how good your engineering team is if they are not given something worthwhile to build.

I promised myself that never again would I work so hard on a product unless I knew the product would be something that users and customers wanted.

I realized that the state of the art was very different from the state of the practice.

Within modern technology product teams, the product manager has some very specific and very challenging responsibilities. It's a tremendously difficult job, and anyone who tries to tell you otherwise is not doing you any favors.

The reality of startup life is that you're in a race to achieve product/market fit before you run out of money. Nothing else much matters until you can come up with a strong product that meets the needs of an initial market, so most of the focus of the young company is necessarily on the product.

Yet the very high failure rate of technology startups is no secret. The few that succeed are usually those that are really good at product discovery, which is a major topic of this book.

There are many very significant challenges involved in growing and scaling a startup into a large, successful business. While it's an extremely difficult challenge, it is, as we say, a good problem to have. In addition to hiring lots more people, we need to figure out how to replicate our earlier successes with new, adjacent products and services. At the same time, we need to grow the core business as fast as possible.

Sales and marketing often complain that the go‐to‐market strategies that worked for the first product are not so appropriate for some of the new products in the portfolio.

The technology infrastructure that was created to meet the needs of the initial product is often bursting at the seams, and you start to hear the term “technical debt” from every engineer you speak with.

You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I've just described is very much a waterfall process. In fairness to the engineers, they're typically doing about as much Agile as they can, given the broader waterfall context.

In any case, one of the most critical lessons in product is knowing what we can't know, and we just can't know at this stage how much money we'll make.

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

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.

Unfortunately, projects are output and product is all about outcome.

and as with any tool, you have to be smart about how you use it.

When I see these teams, they may frame the issues a little differently, sometimes using different nomenclature, but at the heart, I see three overarching principles at work:

Risks are tackled up front, rather than at the end.

Products are defined and designed collaboratively, rather than sequentially.

Finally, it's all about solving problems, not implementing features.

Conventional product roadmaps are all about output. Strong teams know it's not only about implementing a solution. They must ensure that solution solves the underlying problem. It's about business results.

The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.

So, in the product world, we strive to achieve product/market fit. This is the smallest possible actual product that meets the needs of a specific market of customers. Marc Andreessen is credited with popularizing this all‐important concept, and it is a major focus of this book.

The MVP should be a prototype, not a product.

“We need teams of missionaries, not teams of mercenaries.”

Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that's very much the intention.

will tell you there's never a perfect way to carve up the pie. Realize that, when you optimize for one thing, it comes at the

expense of something else. So, decide what's most important to you and go with that.

And, today, on the best teams, the engineers and designers want to see some evidence that what you're asking to build is truly worth building.

When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault.

You can start to see why this role is a proving ground for future CEOs and why the best VCs only want to invest in a company that has one of these proven product people as one of the co‐founders.

four things that the rest of your team is counting on you to bring to the party:

Deep Knowledge of the Customer

This requires both qualitative learning (to understand why our users and customers behave the way they do), and quantitative learning (to understand what they are doing), which is what we'll talk about next.

It should go without saying as it's really table stakes for a product manager, but just to be clear, the product manager must also be an undisputed expert on your actual product.

Deep Knowledge of the Data

Most product managers start their day with half an hour or so in the analytics tools, understanding what's been happening in the past 24 hours.

Deep Knowledge of Your Business

and the one that is often considered the most difficult by many product managers—is a deep understanding of your business and how it works, and the role your product plays in your business.

Deep Knowledge of Your Market and Industry

To summarize, these are the four critical contributions you need to bring to your team: deep knowledge (1) of your

customer, (2) of the data, (3) of your business and its stakeholders, and (4) of your market and industry.

It normally takes about two to three months of dedicated work for a new product manager to get up to speed. This assumes you have a manager who can give you the help and access you need to gain this expertise, including lots of access to customers, access to data (and when necessary, training in the tools to access that data), access to key stakeholders, and time to learn your product and industry inside and out.

By persistent, I mean pushing companies way beyond their comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance.

The passion for products and for solving customer problems is not something I think you can teach.

Start by becoming an expert in your users and customers. Share very openly what you learn, both the good and the bad. Become your team's and your company's go‐to person for understanding anything about your customer—quantitative and qualitative.

Work to establish a strong relationship with your key stakeholders and business partners. Convince them of two things: (1) You understand the constraints they operate under. (2) You will only bring to them solutions that you believe will work within those constraints.

Become an undisputed expert on your product and your industry. Again, share your knowle...

Finally, work very hard to build and nurture the strong collaborative relationshi...

True leadership is a big part of what separates the great product people from the merely good ones. So, no matter what your title or level