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.

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

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.

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.

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

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

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

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.

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

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.

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

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.

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

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

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

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

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

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.

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

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.

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

All other things being equal, a co‐located team is going to substantially outperform a dispersed team. That's just the way it is.

When we empower product teams, we are giving them problems to solve, and we are giving them the context required to make good decisions.

Keep in mind that there will never be a single “perfect” team topology for your organization.

Moreover, as an organization scales, OKRs become an increasingly necessary tool for ensuring that each product team understands how they are contributing to the greater whole, coordinating work across teams, and avoiding duplicate work.

Overall, we look to leadership for inspiration and we look to management for execution.

But one of the most important lessons in our industry is to fall in love with the problem, not the solution.

Please believe me when I say that there are few things more powerful to a product organization than reference customers. It is the single best sales tool you can provide to your sales and marketing organization, and it completely changes the dynamics between the product organization and the rest of the company.

unless I knew the product would be something that users and customers wanted.

A manager that is not an accomplished product manager, designer, or engineer herself is ill‐equipped to assess a candidate, and it is easy to see how the company can end up hiring someone that is not competent at the job. Moreover, without the necessary experience herself, the hiring manager is not able to coach and develop that person to competence.

Coaching might be even more essential than mentoring to our careers and our teams. Whereas mentors dole out words of wisdom, coaches roll up their sleeves and get their hands dirty. They don't just believe in our potential; they get in the arena to help us realize our potential. They hold up a mirror so we can see our blind spots and they hold us accountable for working through our sore spots. They take responsibility for making us better without taking credit for our accomplishments.

usually someone behind the scenes, working tirelessly—who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business.

leananalyticsbook.com

Finally, while we're busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead. We can't get that time or money back.

A product team is a group of people who bring together different specialized skills and responsibilities and feel real ownership for a product or at least a substantial piece of a larger product.

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.

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)

Realize that any product vision is a leap of faith. If you could truly validate a vision, then your vision probably isn't ambitious enough. It will take several years to know. So, make sure what you're working on is meaningful, and recruit people to the product teams who also feel passionate about this problem and then be willing to work for several years to realize the vision.

Every product begins with the people on the cross‐functional product team. How you define the roles, and the people you select to staff the team, will very likely prove to be a determining factor in its success or failure.

group

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.

They are empowered to figure out the best way to meet those objectives, and they are accountable for the results.

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.

There are essentially three ways for a product manager to work, and I argue only one of them leads to success: The product manager can escalate every issue and decision up to the CEO. In this model, the product manager is really a backlog administrator. Lots of CEOs tell me this is the model they find themselves in, and it's not scaling. If you think the product manager job is what's described in a Certified Scrum Product Owner class, you almost certainly fall into this category. The product manager can call a meeting with all the stakeholders in the room and then let them fight it out. This is design by committee, and it rarely yields anything beyond mediocrity. In this model, very common in large companies, the product manager is really a roadmap administrator. The product manager can do his or her job. The honest truth is that the product manager needs to be among the strongest talent in the company. My intention in this book is to convince you of this third way of working. It will take me the entire book to describe how the strong product manager does his or her job, but let me just say for now that this is a very demanding job and requires a strong set of skills and strengths.

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.

The successful product manager must be the very best versions of smart, creative, and persistent.

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.

preparation for this role. 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 knowledge openly and generously. Finally, work very hard to build and nurture the strong collaborative relationship with your product team. I'm

If, for example, your company provides a two‐sided marketplace with buyers on one side and sellers on the other, there are real advantages to having some teams focus on buyers and others focus on sellers. Each product team can go very deep with their type of customers rather than have them try to learn about all types of customers.

During this session, you'll hear about issues or obstacles, and you'll coach on the best way to handle them. In some cases, you'll need to help by talking to a key stakeholder, or finding an additional engineer, or talking to another team about their need to help with a problem, or a hundred similar things. Please don't confuse this with command‐and‐control management. You are not taking over control and telling the teams what to do—you are responding to their requests for help. It's more accurately described as servant leadership and you're being asked to help remove an impediment.

the morale of the engineers is very much a function of you as the product manager.

the tech lead also has an explicit responsibility to help the product manager and product designer discover a strong solution.

developing great people requires a different set of skills than developing great products, which is why many otherwise excellent product managers and designers never progress to leading organizations.

Good product organizations have a strong team, a solid vision, and consistent execution. A great product organization adds the dimension of a strong product culture.

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.

Realize that if the company was set up with feature teams, then it is very unlikely that there was any unifying vision at play—as feature teams are all about serving the needs of their particular stakeholders.

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

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 it. Sometimes the issue is that customers would love it, but it turns out to be much more involved to build than we thought, and we decide we simply can't afford the time and money required to deliver it. 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.)

it's important that a product team has responsibility for all the work—all the projects, features, bug fixes, performance work, optimizations, and content changes—everything and anything for their product.

The bottom line is that we try hard to keep teams together and fairly stable.

An even bigger issue is what comes next, which is when companies get really excited about their product roadmaps. I've seen countless roadmaps over the years, and the vast majority of them are essentially prioritized lists of features and projects. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea.

Good product designers think about the customer's journey over time as they interact with the product and with the company as a whole. Depending on the product, the list of touch points could be very long, considering questions as: How will customers first learn about the product? How will we onboard a first‐time user and (perhaps gradually) reveal new functionality? How might users interact at different times during their day? What other things are competing for the user's attention? How might things be different for a one‐month‐old customer versus a one‐year‐old customer? How will we motivate a user to a higher level of commitment to the product? How will we create moments of gratification? How will a user share his experience with others? How will customers receive an offline service? What is the perceived responsiveness of the product?

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

life is too short for bad products.

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.

The goal is that over time, the organization moves its focus from specific features launching on specific dates to business results.

It is also important culturally that the product organization be transparent and generous in what they learn and how they work. It helps the broader organization to understand that the product organization is not there “to serve the business” but, rather, to solve problems for our customers in ways that work for our business.

Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.

Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps. Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something. Good teams have product, design, and engineering sit side by side, and they embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduling meetings. Good teams are constantly trying out new ideas to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test. Good teams insist they have the skill sets on their team, such as strong product design, necessary to create winning products. Bad teams don't even know what product designers are. Good teams ensure that their engineers have time to try out the prototypes in discovery every day so that they can contribute their thoughts on how to make the product

Good teams engage directly with end users and customers every week, to better understand their customers, and to see the customer's response to their latest ideas. Bad teams think they are the customer. Good teams know that many of their favorite ideas won't end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what's on the roadmap, and are satisfied with meeting dates and ensuring quality. Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough. Good teams make high‐integrity commitments after they've evaluated the request and ensured they have a viable solution that will work for the customer and the business. Bad teams complain about being a sales‐driven company. Good teams instrument their work so they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a nice to have.

Customer‐centric culture. As Jeff Bezos, the CEO of Amazon says, “Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don't yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.

When we talk about validating feasibility, the engineers are really trying to answer several related questions: Do we know how to build this? Do we have the skills on the team to build this? Do we have enough time to build this? Do we need any architectural changes to build this? Do we have on hand all the components we need to build this? Do we understand the dependencies involved in building this? Will the performance be acceptable? Will it scale to the levels we need? Do we have the infrastructure necessary to test and run this? Can we afford the cost to provision this?

We think of four types of questions we're trying to answer during discovery: Will the user or customer choose to use or buy this? (Value) Can the user figure out how to use this? (Usability) Can we build this? (Feasibility) Is this solution viable for our business? (Business viability)

Before you jump in, we want to take the opportunity to learn how they think about this problem today. If you remember the key questions from the Customer Interview Technique, we want to learn whether the user or customer really has the problems we think they have, and how they solve those problems today, and what it would take for them to switch.

Testing Demand Sometimes it's unclear if there's demand for what we want to build. In other words, if we could come up with an amazing solution to this problem, do customers even care about this problem? Enough to buy a new product and switch to it? This concept of demand testing applies to entire products, down to a specific feature on an existing product. We can't just assume there's demand, although often the demand is well established because most of the time our products are entering an existing market with demonstrated and measurable demand. The real challenge in that situation is whether we can come up with a demonstrably better solution in terms of value than the alternatives.

The problem I just described can happen at the product level, such as an all‐new product from a startup, or at the feature level. The feature example is depressingly common. Every day, new features get deployed that don't get used. And, this case is even easier to prevent.

One of the biggest possible wastes of time and effort, and the reason for countless failed startups, is when a team designs and builds a product, yet, when they finally release the product, they find that people won't buy it.

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.

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.

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.

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