Marty Cagan Quotes

We need teams of missionaries, not teams of mercenaries.

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

Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” —General George S. Patton, Jr. General

Further, your industry is constantly moving, and we must create products for where the market will be tomorrow, not where it was yesterday.

Keep the focus on minimal product. More on this later, but your job as product manager is not to define the ultimate product, it’s to define the smallest possible product that will meet your goals.

Software projects can be thought of as having two distinct stages: figuring out what to build (build the right product), and building it (building the product right). The first stage is dominated by product discovery, and the second stage is all about execution.

Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.

Product management is about insights and judgment, both of which require a sharp mind. Hard work is also necessary, but for this job, it is not sufficient.

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.

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

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

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

You can't take your old organization based on feature teams, roadmaps, and passive managers, then overlay a technique from a radically different culture and expect that will work or change anything.

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.

That is, there are two essential high‐level activities in all product teams. We need to discover the product to be built, and we need to deliver that product to market.

product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right.

Great teams are made up of ordinary people who are inspired and empowered.

The difference between Amazon, Netflix, Google, Facebook, and the legions of large but slowly dying companies is usually exactly that: product leadership.

product managers are constantly asking developers to look at the code to tell them how the system really works, then you're probably missing a principal product manager.

Trust is a function of two things: competence and character.

We need a product that our customers love, yet also works for our business.

Historically, in the vast majority of innovations in our industry, the customers had no idea that what they now love was even a possibility.

one of the most critical lessons in product is knowing what we can't know,

Rather than being measured on the output of their design work, the product designer is measured on the success of the product.

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. And, yes, it is more than a little ironic that we sometimes need to convince management to focus on business results.

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.

Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create.

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.

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.

Is my product compelling to our target customer? Have we made this product as easy to use as humanly possible? Will this product succeed against the competition? Not today’s competition, but the competition that will be in the market when we ship? Do I know customers who will really buy this product? Not the product I wish we were going to build, but what we’re really going to build? Is my product truly differentiated? Can I explain the differentiation to a company executive in two minutes? To a smart customer in one minute? To an industry analyst in 30 seconds?

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 famous computer scientist Melvin Conway coined an adage that is often referred to as Conway's Law. It states that any organization that designs a system will produce a design whose structure mirrors the organization's structure. Another way to say this is to beware of shipping your org chart.

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.

Where a lot of novice product people go sideways is when they create a high‐fidelity user prototype and they put it in front of 10 or 15 people who all say how much they love it. They think they've validated their product, but unfortunately, that's not how it works. People say all kinds of things and then go do something different.

If you find that you are having real trouble recruiting charter users and customers, then it’s very likely you are chasing a problem that isn’t that important, and you will probably have a very hard time selling this product. This is one of the very first reality checks to make sure you are spending your time on something worthwhile.

If the first time your developers see an idea is at sprint planning, you have failed. We need to ensure the feasibility before we decide to build, not after. Not only does this end up saving a lot of wasted time, but it turns out that getting the engineer's perspective earlier also tends to improve the solution itself, and it's critical for shared learning.

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.

Similarly, product managers must be problem solvers as well. They are not trying to design the user experience, or architect a scalable, fault‐tolerant solution. Rather, they solve for constraints aligned around their customer's business, their industry, and especially their own business. Is this something their customers need? Is it substantially better than the alternatives? Is it something the company can effectively market and sell, that they can afford to build, that they can service and support, and that complies with legal and regulatory constraints?

The Objectives and Key Results (OKR) technique is a tool for management, focus, and alignment. As with any tool, there are many ways to use it. Here are the critical points for you to keep in mind when using the tool for product teams in product organizations. Objectives should be qualitative; key results need to be quantitative/measurable. Key results should be a measure of business results, not output or tasks. The rest of the company will use OKRs a bit differently, but for the product management, design, and technology organization, focus on the organization's objectives and the objectives for each product team, which are designed to roll up and achieve the organization's objectives. Don't let personal objectives or functional team objectives dilute or confuse the focus.

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.

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

I discovered that there was a tremendous difference between how the best companies produced products and how most companies produced them.

While almost everyone today claims to be Agile, what I've just described is very much a waterfall process.

There are essentially three ways for a product manager to work, and I argue only one of them leads to success:

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.

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. In general, if the product team is given actual business problems to solve rather than solutions, and the product team does their job and interacts directly and frequently with actual users and customers, then getting a sufficient quantity and quality of product ideas is not really a problem.

The idea behind business objectives is simple enough: tell the team what you need them to accomplish and how the results will be measured, and let the team figure out the best way to solve the problems.

A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the result of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team. A strong VP product will understand the importance of a strong product culture, be able to give real examples of her own experiences with product culture, and have concrete plans for instilling this culture in your company.

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.

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. This is what product discovery is all about, and it is why I view product discovery as the most important core competency of a product organization.

It is management's responsibility to provide each product team with the specific business objectives they need to tackle.

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer.

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.

every quarter there's a planning exercise that consumes a few weeks and is then largely ignored for the rest of the quarter. Most of the people on the teams say they get little if any value out of this technique.

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) And it's not enough that it's just the product manager's opinion on these questions. We need to collect evidence.

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.

Strong tech‐product companies know they need to ensure consistent product innovation. This means constantly creating new value for their customers and for their business.

As you'll soon see, coming up with winning products is never easy. We need a product that our customers love, yet also works for our business.

However, a very large component of what is meant by works for our business is that there is a real market there (large enough to sustain a business), we can successfully differentiate from the many competitors out there, we can cost‐effectively

But the way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous and here's why. Remember those two key inputs to every business case? How much money you'll make, and how much it will cost?

It's what I call the two inconvenient truths about product.

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.

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

A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives.

We need design—not just as a service to make our product beautiful—but to discover the right product.

Discovery is very much about the intense collaboration of product management, user experience design, and engineering. In discovery, we are tackling the various risks before we write even one line of production software.

Just because we've invested the time and effort to create a robust product does not mean anyone will want to buy it. So, in the product world, we strive to achieve product/market fit.

First, collaboration is built on relationships, and product teams—especially co‐located teams—are designed to nurture these relationships.

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

projects are output and product is all about outcome.

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. And, yes, it is more than a little ironic that we sometimes need to convince management to focus on business results.

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.

Product evangelism is, as Guy Kawasaki put it years ago, “selling the dream.” It's helping people imagine the future and inspiring them to help create that future. If you're a startup founder, a CEO, or a head of product, this is a very big part of your job, and you'll have a hard time assembling a strong team if you don't get good at it.

CHAPTER 12 The Engineers In this chapter, I describe the engineering role (also commonly known as developers or, in some circles, programmers). But as with the last chapter, I'm not trying to speak here to the engineers—I'm aiming this discussion at product managers who need to learn how to work effectively with engineers. There's probably no more important relationship for a successful product manager than the one with your engineers. If your relationship is strong, with mutual and sincere respect both ways, then the product manager job is great. If your relationship is not strong, your days as product manager will be brutal (and probably numbered). Therefore, this is a relationship worth taking very seriously and doing everything you can to nurture. This strong relationship begins with you.

It's also important for tech product managers to have a broad understanding of the types of analytics that are important to your product. Many have too narrow of a view. Here is the core set for most tech products: User behavior analytics (click paths, engagement) Business analytics (active users, conversion rate, lifetime value, retention) Financial analytics (ASP, billings, time to close) Performance (load time, uptime) Operational costs (storage, hosting) Go‐to‐market costs (acquisition costs, cost of sales, programs) Sentiment (NPS, customer satisfaction, surveys)

leananalyticsbook.com

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

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.

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.

In product companies, it is critical that the product manager also be the product owner.

There are a few product teams out there that have modified 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.

In software development, engineers are often pressured to deliver features instead of fixing defects, addressing reliability issues, or working on internal improvement projects. As a result, so called “technical debt”§§ adds up, leading to more complex problems that are increasingly difficult to solve. Consequently, Marty Cagan, a product expert who has trained generations of product leaders on building software products that customers love, stresses the importance for product and engineering leaders to allocate at least 20% of engineering’s time to proactively fix issues before they snowball into catastrophic ones, such as having to “rewrite the entire codebase from scratch.

are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible, the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility). Together, they own the problem and are responsible and accountable for the results.2

I believe the major risk facing most efforts is value risk. On a startup canvas, this shows up under solution risk—discovering a compelling solution to customers. A solution that your customers will choose to buy and use.

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.

If you compare the list of capabilities that your company needs with the impact that your newly released capabilities are generating, and if you are not feeling good about the return, then this is why changing how you solve problems is so important. The root of the issue is that these feature teams are set up to serve the stakeholders in your business, rather than to serve your customers in ways that work for your business.

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.

good teams are asked to deliver business results.

This role is often called a player‐coach role because of this dynamic of leading your own team, in addition to being responsible for coaching and developing one to three other PMs.

This is the organization responsible for architecture, engineering, quality, site operations, site security, release management, and usually delivery management. This group is responsible for building and running the company's products and services.

The critical context is comprised of two things: The overall product vision The specific business objectives assigned to each team We will discuss both of these key topics in the coming chapters. Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don't, there's a vacuum, and that leads to real ambiguity over what a team can decide and what they can't.

The product vision describes where we as an organization are trying to go, and the product strategy describes the major milestones to get there.

Make sure that members of the senior engineering staff are participating actively and contributing significantly throughout product discovery.

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.

At least as important is discovering a product that is valuable, usable, and feasible. When

A’s hiring A’s, and B’s hiring C’s.

Eventually the talent supply runs out and you have to look elsewhere for the right team. Fortunately, there are some terrific sources of outstanding product talent in places such as India, Eastern Europe (especially the Czech Republic, Hungary, Poland, and Slovakia), Northern Europe (especially the Netherlands, Sweden, and Germany), Israel, China, Singapore, Australia, and New Zealand.

Note that you’ve first got to make sure you have strong people before you empower them. If you empower people who aren’t capable, you are abdicating your responsibility as manager. And if you micromanage people who are not capable, you are essentially doing their job for them.

An example of a product principle for a movie site may be that the team believes that the user community’s opinions on movies are more valuable than those of professional reviewers. Later, if a studio wants to place reviews on your site, you can then decide if this is consistent with your principles or not. Whether

I discovered that there was a tremendous difference between how the best companies produced products, and how most companies produced them.