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

by Marty Cagan

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

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.

So, I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way, the really good teams assume that at least three quarters of the ideas won't perform like they hope.)

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.

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—sales, marketing, finance, legal, etc.).

In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.

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. Specifically, this means getting answers to four critical questions: 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?

So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company's product vision.

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. So, in this book, I talk about different types of prototypes being used in discovery and products being produced in delivery.

There are many benefits of product teams, but a big goal is captured best by a quote from John Doerr, the famous Silicon Valley venture capitalist: “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.

The honest truth is that the product manager needs to be among the strongest talent in the company. If the product manager doesn't have the technology sophistication, doesn't have the business savvy, doesn't have the credibility with the key executives, doesn't have the deep customer knowledge, doesn't have the passion for the product, or doesn't have the respect of their product team, then it's a sure recipe for failure.

At one level, the responsibilities of the product manager are pretty straightforward. He or she is responsible for evaluating opportunities and determining what gets built and delivered to customers. We generally describe what needs to get built on the product backlog.

The third critical contribution—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. This is tougher than it sounds.

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.

No matter what your title or level may be, if you aspire to be great, don't be afraid to lead.

User experience (UX) is much bigger than user interface (UI). Some people even use the term customer experience to further emphasize the point. UX is any way that customers and end users realize the value provided by your product.

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.

I'll say right up front that this is a difficult role, and it is difficult to perform well. Those who do succeed in it make a dramatic difference for their companies. Great product leaders are highly valued and often go on to found their own companies. In fact, some of the best venture capitalists only invest in founders who have already proved themselves as great product leaders.

Weak teams just plod through the roadmap they've been assigned, month after month. And, when something doesn't work—which is often—first they blame it on the stakeholder that requested/demanded the feature and then they try to schedule another iteration on the roadmap, or they suggest a redesign or a different set of features that this time they hope will solve the problem.

In the empowered product team model this book is predicated on, the teams are themselves equipped to figure out the best ways to solve the particular business problems assigned to them. But for this to happen, it's not enough to have strong people equipped with modern tools and techniques. 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.

So, the compromise is straightforward. The product team asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.

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.

The first can easily be summed up with the famous General George Patton quote I mentioned earlier: “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”

It's important that, one way or another, teams feel accountable to achieving their objectives. If they fail substantially, it's worth having a post‐mortem/retrospective with some of their peers or management.

This assumes the individual isn't committing to a burden that will interfere with their ability to contribute their part to their product team, which of course is their primary responsibility.

Share the pain. Show the team the customer pain you are addressing. This is why I love to bring engineers along for customer visits and meetings.

Absolutely be sincere, but let people see you're genuinely excited. Enthusiasm really is contagious.

The purpose of product discovery is to address these critical risks: Will the customer buy this, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Does this solution work for our business? (Business viability risk)

The point is that all three of these are completely intertwined. This is the single biggest reason we push so hard for the product manager, product designer, and tech lead to sit physically adjacent to each other.

I know this is a sensitive topic, and I don't want to sound like I'm preaching or condescending in the least, but I personally encourage the teams I work with to also consider the question, “Should we build it?”

The idea is to answer four key questions about the discovery work you are about to undertake: What business objective is this work intended to address? (Objective) How will you know if you've succeeded? (Key results) What problem will this solve for our customers? (Customer problem) What type of customer are we focused on? (Target market)