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 little secret in product is that engineers are typically the best single source of innovation;

Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late. Teams using Agile in this way are getting maybe 20 percent of the actual value and potential of Agile methods. 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.

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.).

Products are defined and designed collaboratively, rather than sequentially. They have finally moved beyond the old model in which a product manager defines requirements, a designer designs a solution that delivers on those requirements, and then engineering implements those requirements, with each person living with the constraints and decisions of the ones that preceded. In strong teams, product, design, and engineering work side by side, in a gi...

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 s...

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.

To be absolutely clear, the product manager is not the boss of anyone on the product team.

A product team is a set of highly skilled people who come together for an extended period of time to solve hard business problems.

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.

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.

To summarize, product owner responsibilities are a small subset of product management responsibilities, but it's critical that the product manager covers both.

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.

Once you get a designer dedicated to your product team, here are five keys to a successful and healthy relationship with your designer: Do whatever you need to do to have your designer sit next to you. Include your designer from the very inception of every idea. Include your designer in as many customer and user interactions as possible. Learn about the users and customers together. 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. Encourage your designer to iterate early and often.

You want to give your engineers as much latitude as possible in coming up with the best solution. Remember, they are the ones who will be called in the middle of the night to fix issues if they arise.

The key here is that the VP product needs to complement the CEO.

If your engineers and architects are only being used to write software, then you are only getting a fraction of the value from them you should be.

This starts with a clear and compelling product vision, and the path to achieving that vision is the product strategy

The idea is that our organization has a product vision, and all the product teams in that organization are helping to contribute to making that vision a reality. Of course, in very large organizations, while the mission statement might apply to the full company, it's likely that each business unit would have its own product vision and strategy.

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

The first is market sizing, usually referred to as total addressable market (TAM).

The second factor concerns distribution, usually referred to as go to market (GTM).

The third factor is a (very rough) estimation of how long it will take, referred to as time to market (TTM).

These are typically the three dominant factors for prioritizing your markets, but others can be important also. I typically suggest that the head of product, head of technology, and head of product marketing sit down together to work out your product strategy,

use the product vision to articulate your purpose. Everything follows from that.

Fall in love with the problem, not with the solution.

Create something you can get excited about. You can make any product vision meaningful if you focus on how you genuinely help your users and customers.

So many teams give up on their product vision far too soon. This is usually called a vision pivot, but mostly it's a sign of a weak product organization.

It is very possible that you may have to adjust course to reach your desired destination. That's called a discovery pivot, and there's nothing wrong with that.

The idea here is that you can release all the features you want, but if it doesn't solve the underlying business problem, you haven't really solved anything.

Key results should be a measure of business results, not output or tasks.

Keep the number of objectives and key results for the organization and for each team small (one to three objectives, with one to three key results each is typical).

It's critical that every product team track their active progress against their objectives (which is typically weekly).

The objectives do not need to cover every little thing the team does, but they should cover what ...

It's important that, one way or another, teams feel accountable to achie...

Establish very clear and consistent ways to indicate when a key result is in reality a high‐integrity commitment (described earlier) rather than a normal objective. In other words, for most key results, you may be shooting for that 0.7 score. But for a high‐integrity commitment, these are special, and it's more binary. You either delivered what you promised or you didn't.

Senior management (CEO and executive team) is responsible for the organization's objectives and key results. The heads of product and technology are responsible for the product team objectives (and ensuring they deliver on the organization's objectives). The individual product teams are responsible for proposing the key results for each objective they've been assigned. It

If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.

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.

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.

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

As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.

So much product work fails because it tries to please everyone and ends up pleasing no one.

I was taught years ago that the key number is six reference customers. This is not meant to be statistically significant—it is meant to instill confidence—and I have found that number has held up over time. Again, more than six would be even better, but we shoot for six because each one is a lot of work.

Now these are not just any six customers. We are looking to develop six reference customers in our specific target market or segment, so, 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.