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

by Marty Cagan

creating the right product culture for success, and understanding the array of product discovery and delivery techniques so that you can use the right tool for the specific issue you are facing.

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.

It's my belief that most products today are transforming into technology‐powered products, and the companies that don't realize this are rapidly being disrupted.

The reality of startup life is that you're in a race to achieve product/market fit before you run out of money.

In the list that follows, I'm going to share what I consider to be the top‐10 biggest problems with this way of working. Keep in mind that all 10 of these problems are very serious issues, any one of which could derail a team. But many companies have more than one or even all of these problems.

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.

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.

We say if you're just using your engineers to code, you're only getting about half their value.

What you're really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.

The biggest flaw of the old waterfall process has always been, and remains, that all the risk is at the end, which means that customer validation happens way too late.

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.

But there is no silver bullet, and inevitably people figure this out. That's when the backlash begins. As I write this, it's in vogue to criticize both Lean and Agile.

Risks are tackled up front, rather than at the end. In modern teams, we tackle these risks prior to deciding to build anything. These risks include value risk (whether customers will buy it), usability risk (whether users can figure out how to use it), feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have), and business viability risk (whether this solution also works for the various aspects of our business

Products are defined and designed collaboratively, rather than sequentially.

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

Discovery and delivery are our two main activities on a cross‐functional product team, and they are both typically ongoing and in parallel.

We are always working in parallel to both discover the necessary product to be built—which is primarily what the product manager and designer work on every day—while the engineers work to deliver production‐quality product.

In discovery, we are tackling the various risks before we write even one line of production software.

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.

Will the user buy this (or choose to use it)? Can the user figure out how to use this? Can our engineers build this? Can our stakeholders support this?

The vast majority of times I meet a team that has been working hard to create an MVP I am able to convince them that they could have achieved the same learning in a fraction of the time and effort. They have spent literally months building an MVP when they could have had this same learning in days or, sometimes, even in hours.

The MVP should be a prototype, not a product.

Building an actual product‐quality deliverable to learn, even if that deliverable has minimal functionality, leads to substantial waste of time and money, which of course is the antithesis of Lean. I find that using the more general term prototype makes this critical point clear to the product team, the company, and the prospective customers.

John Doerr, the famous Silicon Valley venture capitalist: “We need teams of missionaries, not teams of mercenaries.”

If we want teams to feel empowered and have missionary‐like passion for solving customer problems, we need to give them a significant degree of autonomy.

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.

Every business depends on customers. And what customers buy—or choose to use—is your product. The product is the result of what the product team builds, and the product manager is responsible for what the product team will build.

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's amazing to me how many companies I encounter that just don't understand why having strong and talented designers is so important. They understand the need for engineers, but often will waste significant time and money because they do not understand the need for design.

If you're doing products for consumers, I would argue that strong design today is table stakes. If you're doing products for businesses, then this is one of your best competitive differentiators.

For this to happen, we need to make design a first‐class member of the product team, sitting side by side with the product manager, and not a supporting service.

Engineers are typically smart and often skeptical by nature, so if you're bluffing, they likely won't be fooled.

If the product or site looks like it was created by half a dozen different outside design agencies, with conflicting user models and poor usability, you're probably missing a head of design or principal designer.

Even with the greatest product ideas, if you can't build and launch your product, it remains just an idea.

The main obstacle to rapid delivery is often technical debt, and it is the responsibility of the CTO to ensure that the company is keeping this at a manageable level and not allowing the problem to cripple the organization's ability to deliver and compete,

In the first case, the team simply isn't trusted yet by management, and management is reluctant to give too long of a rope to the team. In the second case, the team wants to change something that the leaders had assumed was part of the foundation.

As is so often the case with product, things boil down to a tradeoff—in this case between the team's autonomy and leverage of the foundation.

The first inconvenient truth is that at least half of our product ideas are just not going to work. There are many reasons for a product idea to not pan out.

the second inconvenient truth is that, even with the ideas that do prove to be valuable, usable, feasible, and viable, it typically takes several iterations to get the execution of this idea to the point where it delivers the expected business value that management was hoping for. This is often referred to as time to money.

strong product teams understand these truths and embrace them rather than deny them. They are very good at quickly tackling the risks (no matter where that idea originated) and are fast at iterating to an effective solution.

If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.

The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.

But we need to make what is called a high‐integrity commitment. This will be discussed in detail later, but the key takeaway here is that we need to solve the underlying problem, not just deliver a feature.

roadmaps have existed for so long because they serve two purposes, and these needs don't go away: The first purpose is because the management of the company wants to make sure that teams are working on the highest‐business‐value items first. The second purpose is because—since they're trying to run a business—there are cases where they need to make date‐based commitments, and the roadmap is where they see and track those commitments (even though in most companies, they rarely trust the dates anymore).

The product teams need to have the necessary business context. They need to have a solid understanding of where the company is heading, and they need to know how their particular team is supposed to contribute to the larger purpose.

In the model I'm describing, it is management's responsibility to provide each product team with the specific business objectives they need to tackle. The difference is that they are now prioritizing business results, rather than product ideas.

It is all about outcome rather than output.

their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome‐based roadmaps.

We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution. We need the time to validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business.