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.

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.

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

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.

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.

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

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

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.

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.

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

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

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

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.

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

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

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 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 tool was first described in 1998 in one of my all-time favorite books, The Inmates Are Running the Asylum, by Alan Cooper. If you haven’t read this book you should—it’s a classic for product managers, designers, and engineers.

The product manager is responsible for defining—in detail—the product to be built, and validating that product with real customers and users. The product marketing person is responsible for telling the world about that product, including positioning, messaging and pricing, managing the product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing and influencer marketing programs.

Will the product actually work? Is the product a whole product? How will customers actually think about and buy the product? Is it consistent with how we plan to sell it? Are the product’s strengths consistent with what’s important to our customers? Are we positioning these strengths as aggressively as possible? Is the product worth money? How much money? Why? Can customers get it cheaper elsewhere? Do I understand what the rest of the product team thinks is good about the product? Is it consistent with my own view?

As product people, we’re essentially in the idea business. It’s our job to come up with great ideas and then make them a reality.

The Inmates Are Running the Asylum, by

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.

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

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

the hiring manager needs to take responsibility for the interview effectiveness of the interview team, and the interview experience for the candidate.

in strong product companies, technology is not an expense, it is the business. Technology enables and powers the products and services we provide to our customers. Technology allows us to solve problems for our customers in ways that are just now possible.

The product strategy describes how we plan to accomplish the product vision, while meeting the needs of the business as we go. The strategy derives from focus, then leverages insights, converts these insights into action, and finally manages the work through to completion.

Leaders don't create followers, they create more leaders.

if you temporarily move someone to another team to deal with an urgent priority. These moves are hard on the person moving as they must adjust to a new team and new work. It's also hard on the team that was left behind as they are often forced to find a way to fill the void.

Let me be clear on this: the best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams.

high‐integrity commitments and deliverables should be the exception and not the rule. Otherwise, it is a slippery slope and pretty soon your objectives become nothing more than a list of deliverables and dates, which is little more than a reformatted roadmap.

The companion to empowerment is accountability.

Empowered teams that produce extraordinary results don't require exceptional hires.

I look at all the people who've worked for me or who I've helped in some way, he would say, and I count up how many are great leaders now. That's how I measure success.

A's hire A's, but B's hire C's.

I know a few organizations that have tried hard to achieve this, but I have never seen this succeed. The systems always seem to grow in complexity and size much faster than anyone can document, and with software, the definitive answer always lives in the source code itself

How much money you'll make, and how much it will cost?

It's way too late in the game to get the real value of design, and mostly what's being done is what we call the “lipstick on the pig” model.

Unfortunately, projects are output and product is all about outcome.

People are always searching for a silver bullet to create products, and there is always a willing industry—ready and waiting to serve with books, coaching, training, and consulting. But there is no silver bullet, and inevitably people figure this out.

Risks are tackled up front, rather than at the end.

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 give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.

The Group Product Manager Role There's a role in larger product organizations that I find especially effective. The role is titled group product manager, usually referred to as GPM. The GPM is a hybrid role. Part individual contributor and part first‐level people manager. The idea is that the GPM is already a proven product manager (usually coming from a senior product manager title), and now the person is ready for more responsibility. There are generally two career paths for product managers. One is to stay as an individual contributor, which, if you're strong enough, can go all the way up to a principal product manager—a person who's an individual contributor but a rock‐star performer and willing and able to tackle the toughest product work. This is a very highly regarded role and generally compensated like a director or even VP. The other path is to move into functional management of the product managers (the most common title is director

The Group Product Manager Role There's a role in larger product organizations that I find especially effective. The role is titled group product manager, usually referred to as GPM. The GPM is a hybrid role. Part individual contributor and part first‐level people manager. The idea is that the GPM is already a proven product manager (usually coming from a senior product manager title), and now the person is ready for more responsibility. There are generally two career paths for product managers. One is to stay as an individual contributor, which, if you're strong enough, can go all the way up to a principal product manager—a person who's an individual contributor but a rock‐star performer and willing and able to tackle the toughest product work. This is a very highly regarded role and generally compensated like a director or even VP. The other path is to move into functional management of the product managers (the most common title is director of product management) where some number of product managers (usually somewhere between 3 and 10) report directly to you. The director of product management is really responsible for two things. The first is ensuring his or her product managers are all strong and capable. The second is product vision and strategy and connecting the dots between the product work of the many teams. This is also referred to as holistic view of product. But lots of strong senior product managers are not sure about their preferred career path at this stage, and the GPM role is a great way to get a taste of both worlds. The GPM is the actual product manager for one product team, but in addition, she is responsible for the development and coaching of a small number of additional product managers (typically, one to three others). While the director of product management may have product managers who work across many different areas, the GPM model is designed to facilitate tightly coupled product teams.

Here's some very practical and important advice for you to consider. Holding a weekly planning meeting where you throw a bunch of ideas at the engineers—and demand they give you some sort of estimate either in time, story points, or any other unit of effort—is almost certain to go badly. If you put an engineer on the spot, without time to investigate and consider, you are very likely to get a conservative answer, partly designed to make you go away.

Along the vertical dimension, we have a progressive level of detail. As we flesh out each major activity into sets of user tasks, we add stories for each of those tasks. The critical tasks are higher vertically than the optional tasks.

Let's start at the top—the source of ideas. This model leads to sales‐driven specials and stakeholder‐driven products. Lots more to come on this key topic, but for now, let me just say that this is not the source of our best product ideas. Another consequence of this approach is the lack of team empowerment. In this model, they're just there to implement—they're mercenaries.

Likewise, we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old t‐shirt sizing compromise—just let us know if this is “small, medium, large, or extra large.

First, collaboration is built on relationships, and product teams—especially co‐located teams—are designed to nurture these relationships. Second, to innovate you need expertise, and the durable nature of product teams lets people go deep enough to gain that expertise. Third, instead of just building what others determine might be valuable, in the product team model the full team understands—needs to understand—the business objectives and context. And most important, the full team feels ownership and responsibility for the outcome.

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

the morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries. You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face. Don't try to shelter them from this—instead, share these problems and challenges very openly with them. They will respect you more for it, and, in most cases, the developers will rise to the challenge.

Architectures drive technologies, which drive skill sets.

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

there's a common tendency to have each functional department create their own OKRs for their own organization.

thinking like an owner versus thinking like an employee is primarily about taking responsibility for the outcome rather than just the activities.

if you can't manage to clear four hours a day during your workday, then I only know of two possibilities: either you extend your workday, or you fail to deliver results and so you fail at your job.

Why is thinking so important? Because at its core, product teams are all about problem solving.

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

the best product companies hire competent people of character, and then coach and develop them into members of extraordinary teams.

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

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

that every product needs a single, accountable product manager, who is responsible for the product definition (the combination of product requirements and user experience design that describe the product to be built). Unfortunately, when I begin working with a company,

Unfortunately, the skills for interaction design are very different from product management, and it’s the rare product manager who’s good at both.

If we’re going to make this decision based on opinions, we’re going to use my opinion.

Even if a true MRD is done, they suffer many of the same problems as PRDs—

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 acquire and engage new customers, and we have the go‐to‐market channels and capabilities required to get our product into the hands of our customers.

Many teams get into a lot of grief with the concept of a minimum viable product (MVP) because on the one hand we are very motivated to get this out in front of customers fast to get feedback and learn. And, on the other hand, when we do get out there fast, people feel like this so‐called product is an embarrassment to the brand and the company. How could we possibly consider launching this?

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?

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.

engineering gets brought in way too late. 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.

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.

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.

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

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)

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.