Modern Product Management with Marty Cagan

This Q&A with Marty is not one of the best, the questions are not particularly good, but still a few good insights on key themes like strategy, the PM role, agile methods, etc.


  • The main thing I get frustrated with at companies, is that they have no strategy – not even a bad strategy, just none.
  • They have some objectives, like grow the business or reduce churn rates. And then a roadmap of features. But that’s it.
  • This is a difference with good product companies, where the strategy is right at the heart of what teams do.
  • Strategy requires doing things that are hard, like making decisions about what not to work on. They have too many priorities. They don’t really understand what it means to focus.
  • Thinking and looking at insights is required for good strategy. It takes a lot of work.
  • Managers need to sit down one-on-one with product teams to discuss how they are contributing to the strategy.
  • Product strategy should tell you what problems need to be solved. This is what you then give to the product teams to tackle. Not just passing down a roadmap.

What is an empowered team?

  • Do they get to figure out the best way to solve the problems they are tasked with, or does somebody else figure that out?
  • But to do that, they need a true cross-functional team. PM, UX and design, and engineering.
  • The biggest thing missing from most teams is a real product manager. They have product owners, but not a product manager.
  • A product owner is just a backlog administrator. This is not that helpful to a product team.
  • These people can be coached most of the time to be a product manager though.
  • The PM is a problem, because there is only one on a team, unlike engineering. And if that PM is not capable, then you have a big problem.

Trust in product teams

  • The executives need to trust the team, and in particular the product manager.
  • Otherwise they won’t let them figure out the solutions.
  • In the team it requires trust between the different roles, because to solve the problems it means everyone working together.
  • Character is also important. Don’t hire jerks, otherwise it is hard to collaborate as a team.

Agile methods

  • Lots of teams say they use Agile or Kanban, but this doesn’t mean they really are agile in nature, they are still following a roadmap and building features.
  • There are a bunch of processes out there that call themselves Agile, but they are not. The most famous one is SAFe – this is just marketing, there is no agile there in shape or form. It’s command and control and waterfall.
  • Companies sometimes have these Agile religious people. Anytime you have a religious view on these things it is dangerous.

Product Discovery

  • Discovery is much faster than delivery. We should do doing 15-30 prototypes or tests a week.
  • We like discovery because we can very quickly find out whether something is worth building or not.
  • Don’t like using the term MVP much anymore because it confuses people. It’s just another prototype mechanism. Most prototypes, and most MVPs, are going to be thrown away at the end.
  • I’m allergic to process. A competent product manager is choosing the right techniques for the job.
  • The four risks: value, usability, feasibility, viability, all require different methods.
  • Sometimes it’s very easy and it just goes on the backlog. Sometimes it’s very risky and we have to do a lot of prototyping.

The difference between B2C and B2B

  • It depends if it’s a good or bad B2B. Most B2B companies are terrible. That’s long established. They do terrible products.
  • If it’s a good B2B company, the difference is not big at all. Basically you should build products for business users the you build for consumers.
  • Most B2B companies are not well run from a product perspective. They are really sales driven.
  • That leads to a whole bunch of bad behaviours.

How to measure progress in the discovery phase?

  • Try not to think of discovery as a phase. It’s what design and PM do every day.
  • You can look at silly metrics like how many prototypes we did. But none of that matters.
  • What matters are the results. Look at the result KPIs.
  • Everything else is a vanity KPI.
  • You can do 100 prototypes in a week and still have a terrible product.

What does a sales team or CEO say when asked when a feature will be ready?

  • It’s normal for customers to ask about features.
  • You need to have a conversation with them about what they are really trying to do.
  • The real answer is easy: we will solve the problem by a certain date. Not a certain feature.
  • This is easier in B2C than it is in B2B.

Recommended book: Lean Analytics – this is one of the best in the series, and good for learning the data analytics part of the job. Also take a course on statistics.

What skills do product managers lack the most?

  • Four big things:
    • Deep understanding of your users and customers
    • Deep understanding of the data and analytics
    • Deep understanding of your own business
    • Deep understanding of your industry
  • A key thing for product people is constant learning. If you don’t like learning then you won’t like this job.

Escaping the Build Trap – by Melissa Perri

Most people working in Product Management will recognise what Melissa describes – building features to satisfy stakeholders or meet output deliverables on a roadmap. But how do you change from an output team to an outcome focused team? This book goes through the steps to get there.

It’s a good read. Although like many business-related books, it feels too long, and a long-form article would have sufficed. But still, Escaping the Build Trap is one of the better books for product managers.

The following are the highlights I made while reading the book.

Part 1: The Build Trap

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce.

“A lot of it is due to having too many priorities. Everything is number one on your project list. You are peanut-buttering your strategy – meaning that you have so many strategic initiatives spread over very few people.”

To get out of the build trap, you need to look at the entire company, not just at the development team. Are you optimizing your organization to continually produce value? Are you set up to grow and sustain products as a company? This is what a product-led organization does.

In this book, I go into detail on how you can set up a product management organization to look for opportunities that maximize business and customer value.

Chapter 1. The Value Exchange System

When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure. “Value” becomes the quantity of features that are delivered, and, as a result, the number of features shipped becomes the primary metric of success.

The company also overpromised during the sales process, giving customers whatever it took to get the contract signed. The result was a ton of one-off features that satisfied the needs of only one client, rather than a strategic choice to build what would scale for many clients.

Instead of analyzing how each of these features provided unique value to its customers and moving the company strategy forward, the organization was stuck in reactive mode. It was not building with intent. And yet, it thought of itself as a successful company because it had a million features to talk about at user conferences. The company lost sight of what made its product attractive to customers – what made the company special.

Chapter 2. Constraints on the Value Exchange System

For example, many companies follow such a rigid development process and cadence that there is no opportunity to experiment. Whenever I start a new training or workshop, I say to product managers, “Raise your hand if you went back and iterated on the last thing you shipped.” Normally, 15-20% of the people raise their hands. My next question is, “How do you know that what you shipped was successful?” The answers here usually revolve around meeting a deadline and finishing with bug-free code.

Yet most companies I encounter are stuck in output mode, and their entire organization is optimized to increase the output. Their processes are driven by deadlines by checking off as many features on a list as possible. Teams are rewarded and incentivized to build more.

Most companies are unaware of the detrimental impact these factors have on their value production, and it’s because they are not actually measuring the outcomes of their actions. They lose track of their strategy and vision, and they end up in the build trap.

Chapter 3. Projects Versus Products Versus Services

Many companies operate on a project-based development cycle, in which they scope out work to be done, create deadlines and milestones, and then have the teams get to work. When the project is over, they move on to the next project. Many of these projects have their own measures of outcomes, but there is no aligning strategy above them.

Products, as I said before, are vehicles of value. They deliver value repeatedly to customers and users, without requiring the company to build something new every time.

Companies that optimize their products to achieve value are called product-led organizations. These organizations are characterized by product-driven growth, scaling their organization through software products, and optimizing until they reach the desired outcomes.

Chapter 4. The Product-Led Organization

But, if you’re not product-led, what are you? Many companies are, instead, led by sales, visionaries, or technology. All of these ways of organizing can land you in the build trap.

Sales-led companies let their contracts define their product strategy … The product roadmap and direction were driven by what was promised to customers, without aligning back to the overall strategy.

Many small companies start off as sales-led, and that can be okay. As a startup, it’s necessary to close that first big client and get the revenue needed to continue operating.

But this way of working does not scale for long. When you have 50 to 100 customers or more, you cannot build everything uniquely to match the needs of each one, unless you want to be a bespoke agency. If that is not in the cards for you, you need to change your strategy to building features that apply to everyone, without customization.

Yet many companies that do not want to go the bespoke route operate as sales-led for far longer than they should. Their sales process gets ahead of their product strategy, and they continually need to play catch-up to make their commitments. This leaves no room for product teams to strategize or explore what could push the company further.

Product-led companies optimize for their business outcomes, align their product strategy to these goals, and then prioritize the most effective projects that will help develop those products into sustainable drivers of growth.

The good thing is that it’s not that technically difficult to make this change. You don’t need to hire an entire new team. You don’t need to scape all your products and start over. What is needed, though, can sometimes be even more challenging to implement – and that’s the mindset shift.

Chapter 5. What We Know and What We Don’t

Product management is the domain of recognizing and investigating the known unknowns and of reducing the universe around the unknown unknowns. Anyone can run with solutions based on known knowns. Those facts are readily available. But it takes a certain skill to be able to sift through the massive amounts of information and to identify the right questions to ask and when to ask them.

Product managers identify features and products that will solve customer problems while achieving business goals. They optimize the Value Exchange System.

Part 2: The Role of the Product Manager

They keep the team focused on the why – why are we building this product, and what outcomes will it produce? The chief product officer is the cornerstone of the product team in companies, helping to tie together the business outcomes to the roadmap and to represent its impact to the board.

Chapter 6. Bad Product Manager Archetypes

There are few paths available today to learn product management. It isn’t taught at college. Training programs on the job are usually lacking. Microsoft and Google are two of the only major companies that actually have an entry-level career path for product managers. Internships are few and far between. And most product managers you meet have made either a lateral move inside their company or have been “promoted” from software development.

Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management. Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset.

To understand what the product manager’s role is not, you need to understand the common archetypes of bad product managers.

The Mini-CEO

Product managers are not the mini-CEOs of a product, yet 90% of the job postings I have seen for product managers describe them as being the mini-CEO.

Out of this wonderful CEO myth emerged an archetype of a very arrogant product manager who thinks they rule the world.

The Waiter

The waiter is a product manager who, at heart, is an order taker. They go to their stakeholders, customers, or managers, ask for what they want, and turn those wants into a list of items to be developed. There is no goal. There is no vision. There is no decision making involved.

The most common question I get from product managers in this position is, “How do I prioritize?” Because they have no goal in which to provide context for trade-offs, it becomes a popularity contest for whomever is making the request. More often than not, the most important person gets their features prioritized.

The product death cycle is a specific form of the build trap. You are implementing ideas without validating them. It’s not the customer’s job to come up with their own solutions. That is your job. You need to deeply understand their problems and then determine the best solutions for them.

The Former Project Manager

Project managers are responsible for the when. When will a project finish. Is everyone on track? Will we hit our deadline?

Product managers are responsible for the why? Why are we building this? How does it deliver value to our customers? How does it help meet the goals of the business?

Answering why is very different than answering when. It requires a strategic mindset that understands the customer, business, market, and organization. This is a critical skill set for a great product manager.

Chapter 7. A Great Product Manager

They need to understand the market and how the business works. They need to truly understand the vision and goal of the company. They also need deep empathy for the users for whom they are building products, to understand their needs.

One of the biggest misconceptions about the role of a product manager is that they own the entire product and therefore can tell everyone what to build. Act this way, and you will only alienate the rest of your team. Product managers really own the “why” of what they are building.

One of the worst traits a product manager can have is the lone wolf mentality – the idea that they are the only one responsible for the success of their product.

One of the biggest mistakes companies make in hiring a product manager is trying to find either a technical or market export. Product managers are not experts in either of these domains; they are experts in product management.

That doesn’t mean they don’t need knowledge in either of these areas. They need to know just enough to talk with an engineer or a business person and to understand enough to make informed decisions. A product manager must be tech literate, not tech fluent.

“The biggest thing I’ve learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing.”

When you look at the role of the product owner in most Scrum literature, the three responsibilities of the position include the following:

  • Define the product backlog and create actionable user stories for the development teams.
  • Groom and prioritize the work in the backlog.
  • Accept the completed user stories to make sure the work fulfils the criteria.

Although Scrum has a lot of information on the processes and rituals of what to do as a product owner, it leaves lots of questions unanswered and these questions are important for creating successful products:

  • How do we determine value?
  • How do we measure the success of our products in the market?
  • How do we make sure we are building the right thing?
  • How do we price and package our product?
  • How do we bring our product to market?
  • What makes sense to build versus buy?
  • How can we integrate with third-party software to enter new markets?

Product ownership is just a piece of product management. A good product manager is taught how to prioritize work against clear, outcome-oriented goals, to define and discover real customer and business value, and to determine what processes are needed to reduce the uncertainty about the product’s success in the market.

In other words, product owner is a role you play on a Scrum team. Product manager is a career.

Product management and Scrum can work well together, but product management is not dependent on Scrum.

Product managers ultimately play a few key roles, but one of the most important ones is being able to marry the business goals with the customer goals, to achieve value. Good product managers are able to figure out how to achieve goals for the business by creating or optimizing products, all with a view toward solving actual customer problems. This is a very important skill set.

I’ve trained dozens of teams who are using SAFe, and I have never seen it work well. Although the appear of having a framework that lays out everything you need to do technology-wise in nice near boxes sounds appealing, in practice it usually breaks down.

I teach my clients that product managers in senior roles (VPs, product leads, or middle managers) concentrate on defining the vision and strategy for the teams based on market research, an understanding of company goals and strategy, and by looking at the current state of success of their products.

Chapter 8. The Product Manager Career Path

The foundations of working with a development team, diving into individual user needs and problems, and measuring data will always be relevant skills for a product manager at any level.

Typical product management career path:

  • Associate product manager
  • Product manager
  • Senior product manager
  • Director of product
  • VP of product
  • Chief product officer (CPO)

It’s important to remember that this is a discipline that must be mastered as a career. As I’ve explained in this chapter, product management is not something you can learn in a two-day course, as so many Agile consultancies would like you to believe.

Senior product managers are critical to the success of companies of all sizes because they can operate more independently than many product managers. They are also usually entrepreneurial, which is a great trait, since these people are usually the ones who will start new product lines for businesses.

A director of product is usually found only at larger companies and is a critical role for scaling.

In large, enterprise companies, VPs of product are also directly responsible for the financial success of their product line, not just the delivery of product feature. All the VPs of product in a large company must be aligned in their strategy and purpose, to ensure a successful portfolio of products.

The CPO is a fairly new yet critical role for organizations. A CPO oversees a company’s entire product portfolio. This is the highest role of a product manager, and it represents a seat at the executive table of a company.

A company should think about adding a CPO when it starts to develop its second product, expands into another geography, or merges with another company. This role is critical to ensure that the entire portfolio is working together to achieve the company goals.

…those that make the best chief product officers also have three key traits that set them apart: they inspire confidence, empathize, and are relentless and resilient.

Chapter 9. Organizing Your Teams

The way you structure your product teams and organize them around the work that needs to be done on features and products is incredibly important for the success of your product development. Companies tend to organize in three main ways: value streams, features, and technical components.

TransferWise has a reletively small number of product teams at around 12. The way they organize their teams – around strategic goals – allows them to stay small and still get an immense amount of work done.

One team is focused on retention, another on implementing new currencies, and another on acquiring new users. Each of the teams has ownership of their goal and is judged for success based on their outcomes. They are also allowed to work across all products to do whatever is needed to reach those goals … Even though the coordination might seem like a handful, having fewer teams makes them ruthlessly prioritize around the most important initiatives. There’s no useless work.

A value stream is all of the activities needed to deliver value to the customer … To do that, it makes sense to organize your teams around the value stream. How do you organize this way? First you begin with the customer or user – whomever is consuming your product at the end of the day. What is the value that you are providing them? Then work backward.

This often happens when teams restructure around value instead of components. They find they do not need as many people to accomplish their goals.

This gets to what we were talking about earlier – organizing teams around your strategy, which is the most important work for your business.

When organizations lack a coherent product strategy that is ruthlessly prioritized around a few key goals, they end up spreading themselves thin.

Part 3: Strategy

Strategy creation is the process of determining the direction of the company and developing the framework in which people make decisions.

We started investing 1% to 2% of revenue every year in downloading, and I think it’s tremendously exciting because it will fundamentally lower our mailing costs. We want to be ready when video-on-demand happens. That’s why the company is called Netflix, not DVD-by-Mail.” [Reed Hastings]

After we eventually won the Blockbuster battle, I looked back and realized all those things distracted us. They didn’t help, and they marginally hurt. The reason we won is because we improved our everyday service of shipping and delivering. That experience grounded us. Executing better on the core mission is the way to win.” [Reed Hastings]

That guideline was to “delight customers, in margin-enhancing, hard-to-copy ways.” He set goals that would accomplish this and would help Netflix execute on the company vision around key initiatives including personalization, instant access to entertainment, and ease of use. Teams were then able to explore tactics to accomplish these goals, and they were held accountable to success metrics for each.

Netflix can change tactics or kill ideas because it commits itself not to the solutions they are building but rather to the outcomes these solutions produce.

Chapter 10. What is Strategy?

Teams that lock themselves into these plans of action before gathering actual evidence will build useless features that do not matter to their customers.

Thinking of strategy as a plan is what gets us into the build trap. We keep adding new features to the list but have no way to evaluate whether they are the right features in the holistic context of our company.

A good strategy should sustain an organization for years. If you are changing strategy yearly or monthly, without good reason from data or the market, you are treating your strategy as a plan rather than as a framework.

Chapter 11. Strategic Gaps

  • The knowledge gap
  • The alignment gap
  • The effects gap

At one company, I walked around asking all of the product managers on the hundred or so teams why they were working on their current project. I then asked their leaders the same question. I got two different answers from these two different levels. They could not connect the activities of the teams back to the outcomes of the companies because leadership had passed down feature requests rather than expected outcomes and goals.

When these teams realized that customers did not want the consultant-proposed solution, they should have had the freedom to explore alternative options. That is how a product-led organization would operate. This is what keeps us out of the build trap. Instead, their adherence to pre-determined meetings and formalities trapped them into staying quiet. Product teams need the freedom to explore solutions and to adjust their actions according to the data they receive. As long as they are aligned with the overall strategic intents and vision for the company, management should feel comfortable granting the necessary autonomy to capable teams.

But why do we care about strategy being something that enables action? Well, that is how you scale an organization – by enabling action through autonomous teams.

In the world of software, we don’t work this way. We’re hiring incredibly smart people and paying them hundreds of thousands of dollars to make the decisions on how to grow companies by making complex software that customers love. When you have that sort of talent, you need to give them the room to make decisions so that you can get the full benefit of their knowledge skill.

That’s what a strategic framework promotes. If you’re aligned coherently and you have a good strategic framework, you can then allow people to make decisions without a lot of management oversight.

Chapter 12. Creating a Good Strategic Framework

It was reacting to the customer that screamed the loudest instead of evaluating whether those requests matched the strategic objectives. The morale of the company was low, and, because of that, employees were not producing.

So the company decided to change. It decided to create and deploy a strategy that would work with modern product management methods.

One of the biggest issues I hear from executives is that they do not have the data they need to make decisions. People ask them to create a vision, but they do not continuously surface information in a way that helps inform the strategic decisions that enable the organization to achieve the vision. The teams should be out there, analyzing, testing, and learning and then communicating what they discover back to their peers and their management teams. This is how we set strategy. [Bloom]

Chapter 13. Company-Level Vision and Strategic Intents

“What is the most important thing we can do to reach our vision, based on where we are now?” There should not be laundry list of desires or goals – just a few key things that need to happen to make a big leap forward. Keeping the list of strategic intends small focuses everyone.

One intent is usually good for a small company, and three are plenty for a large organization. Yes, three. I know that sounds like very few goals for an organization of thousands of people, but that is key. This is also where the level and time frame matters.

That’s the point. The strategic intents are about the whole company, not just the product solution.

Chapter 14. Product Vision and Portfolio

All of these solutions, which I call options, were aligned to this product initiative. Options are your bets, as Spotify would cal them. They represent the possible solutions that teams will explore to solve the product initiative.

To get there, the CPO answers these questions for their teams:

  • How do all of our products work as a system to provide value to our customers?
  • What unique value does each of the product lines offer that makes this a compelling system?
  • What overall values and guidelines should we consider when deciding on new product solutions?
  • What should we stop doing or building because it does not serve this vision?

Amazon is the king of building innovation into its portfolio. It spins up teams in secret labs, and these teams spend years figuring out how to expand the company’s business.

Amazon set the time and space aside that it needed in product initiatives to go after and explore how to enter this new market.

Part 4: Product Management Process

Chapter 15. The Product Kata

After we have set the goal, we begin walking through the Product Kata. We ask ourselves the following:

  • What is the goal?
  • Where are we now in relation to that goal?
  • What is the biggest problem or obstacle standing in the way of me reaching that goal?
  • How do I try to solve that problem?
  • What do I expect to happen (hypothesis)?
  • What actually happened, and what did we learn?

One of the biggest mistakes I’ve seen in product management is teams rushing into apply a tool or practice at the wrong stage. Many times, they are experimenting unnecessarily when the problem is not yet known or when there is already a good idea about the solution.

Chapter 16. Understanding the Direction and Setting Success Metrics

Product metrics tell you how healthy your product is, and, ultimately, your business, given that a healthy product contributes to overall health of the business. They are the lifeblood of every product manager. Keeping a pulse on your product is crucial for knowing when you should act and where. This is how we set direction.

To make sure you have enough data to act on, it’s important to implement tools that make it easy to measure these things. This is one of the first things every company should do – implement a metrics platform. Amplitude,, Mixpanel, Intercom, and Google Analytics are all data platforms. Some, like Intercom and, also implement good customer feedback loops, because they provide tools to reach out to customers and ask questions. Having a metrics platform implemented, whether it’s homegrown or third party, is essential for a product-led company because it enables product managers to make well-informed decisions.

You won’t be able to set success metrics without investigating the problem. This is why we first need problem exploration, a process we explain in the next chapter.

Chapter 17. Problem Exploration

Product managers are often spoken about as the “voice of the customer,” yet too many of us are not getting out and talking to customers as much as we should. Why? Because it involves talking to (gasp) people. It takes a lot of effort to line up the interviews, and sometimes that can seem more daunting than staying inside and jumping right into A/B testing or sifting through data. Although data analysis is important, it can’t tell the entire story.

If you don’t have an underlying understanding of the problem, you can never deliberately create the right solution.

Instead, fall in love with the problem you are solving.

People often immediately jump into telling you the solution. “Oh, I just need a button here that lets me do X,” they say. As a product manager, you need to back up and ask, “Okay, but why? Why do you need a button? Why do you think a button is the right thing? What are you trying to accomplish?” It is understanding the user’s need – not the button – that helps you to get closer to understanding the root of the problem.

Remember, it’s not the customer’s job to solve their own problems. It’s your job to ask them the right questions.

Chapter 18. Solution Exploration

Companies often confuse the building to learn and building to earn. Experimentation is all about building to learn. It allows you to understand your customers better and to prove whether there is value in solving a problem. Experiments should not be designed to last for a long time.

Concierge experiments are particularly interesting for B2B companies because this is how many of these companies got started – by taking on the work for the customers and then later automating it. By taking on the work yourself, you can learn how to build the software correctly the first time. And it’s far faster and less expensive to iterate on a service than on a coded feature. I frequently used this type of experiment to learn about my customers when I worked as a product manager.

Zappos actually started with this Wizard of Oz method. Back in the way, founder Nick Swinmurn wanted to see whether people would really buy shoes online. He put a simple website up on WordPress. Visitors could view and then buy the shoes online. But, on the backend, it was just Nick, singlehandedly running around, buying shoes from Sears and shipping them out from UPS himself.

Every industry and product has unknowns – getting creative about how you answer these unknowns is key.

Chapter 19. Building and Optimizing Your Solution

After the direction is set for the product vision, it’s important to make sure everyone understands the context and work that needs to be done. Story mapping and North Star documents are two ways to help teams find alignment around the vision.

We are done developing or iterating on a feature only when it has reached its goals. Often, teams ship a first version of the feature and then move on to the next, without measuring the outcomes for the user. As Jeff Gothelf, the author of Sense & Respond, once said, “Version 2 is the biggest lie in software development.” This mentality always leads to the build trap.

When you have success criteria set for the launch, you can use them in the Product Kata and repeat the steps we went through in this section: set the direction with your success criteria, understand what problems are standing in the way of you reaching it, and systematically tackle them through experimentation.

This is how you build with intent and get out of the build trap. But, in addition to having a solid process and strategy, you need a company that supports good product management efforts. Christa’s team was able to succeed only because their environment allowed it to. They were able to talk to customers. The team was oriented around outcomes, and then the leadership team gave it the space to figure out how to achieve those outcomes.

These are the marks of a product-led company. Process and frameworks get you only so far on your way to success. Culture, policies, and structure are the things that really set a company apart to thrive in product management.

Part 5. The Product-Led Organization

The product-led organization is characterized by a culture that understands and organizes around outcomes over outputs, including a company cadence that revolves around evaluating its strategy in accordance to meeting outcomes. In product-led organizations, people are rewarded for learning and achieving goals. Management encourages product teams to get close to their customers, and product management is seen as a critical function that furthers the business.

Its philosophy as an organization was not set up to succeed in the world of rapid innovation that emerged during the early 2000s.

Many companies are in danger of becoming just like Kodak, but this fate can be avoided by adopting a product-led mindset.

Chapter 20. Outcome-Focused Communication

If there is one main reason I have seen companies fail to make a transition, it’s the lack of leadership buy-in to move to an outcome-oriented company. Leaders will say that they want to achieve results, but, at the end of the day, they still measure success by features shipped. Why? There’s so much satisfaction in seeing things move, at both a leadership and a team level. People want to feel like they are accomplishing things. Checking off the boxes of finished work feels good, but we need to remember that this is not the only measure of success.

Instead of thinking of roadmaps as a Gantt chart, you should view them as an explanation of strategy and the current stage of your product. This combines the strategic goals with the themes of work and the emerging product deliverables from it. To do this, the product roadmap should be updated constantly, especially at the team levels. This is why, at Produx Labs, we call them Living Roadmaps.

Roadmaps are not one-size-fits-all. You need to communicate them differently, depending on whether you are talking internally to your team about uncertainty or to the sales team about features that it can communicate to customers. You should design your communication to match your audience.

One great resource for determining how to set a roadmap is C. Todd Lombardo and Bruce McCarthy’s book, Product Roadmaps Relaunched. It’s an in-depth, practical guide on how to create great roadmaps for your company.

Usually, our roadmaps consist of a few key parts:

  • The theme
  • Hypothsis
  • Goals and success metrics
  • Stage of development
  • Any important milestones

Chapter 21. Rewards and Incentives

[No notes]

Chapter 22. Safety and Learning

Marquetly was successful because the CEO and leaders held back while the teams were experimenting, even if that made them squirm a bit. Product managers need a certain amount of trust from the organization to have room to explore different options. To really push boundaries, teams are going to have to try some perceivably wild stuff. It might not be the solution you originally thought of and the teams might not have all the answers at the beginning, but if they are not allowed to explore these weird paths, they will never push the status quo. The status quo is safe. The status quo keeps you from innovating.

Learning should be at the core of every product-led organization. It should be what drives us as an organization.

Ideally, product managers should be risk mitigators who say, “Hey, I think the most costly thing we can do is build this product without knowing it’s the right product to build. How do I test it and ensure that this is actually what we want? How do I become more confident that we’re on the right path before I invest money in this?” Leaders who give people the room to do that see the best results and avoid the build trap.

Chapter 23. Budgeting

One of the factors that leads to the output-over-outcome mindset in organizations is the way that they do budgeting.

It’s far wiser to look at funding product development like a venture capitalist.

Product-led companies invest in and budget for work based on their portfolio distribution and the stage of their work.

They then allocate more and more funds to grow the opportunities as they become validated.

But the idea is that all budgeting should be tied to getting a product to the next stage. It’s an effective way to both focus the teams and make sure you’re not overspending.

Chapter 24. Customer Centricity

Many of the top companies today, such as Amazon, Netflix, Zappos, Dollar Shave Club, and Disney, have gotten where they are by focusing on the customer. You can see this attitude manifest in the way that executives talk about and treat their customers.

This is the core of what it means to be customer-centric – to put yourself into your customers’ shoes and ask, “What would make my customers happy and move our business forward?”

This is what it means to be customer centric: knowing that the most important thing you can do to create great products is to deeply understand your customers. This is also the core of what it means to be product-led.

Chapter 25. Marquetly: The Product-Led Company

Getting out of the build trap is possible, but it takes time and effort. It’s not something that you can easily achieve in a year. It requires not only changing how you work but also how you think as an organization. It needs the participation of everyone in the organization, from the leaders in the C-Suite to the product managers on the teams. Reading this book is your first step. Setting up a fully-functioning product organization will be your first step.

Afterword: Escaping the build trap to become product-led

Consulting also taught me that one of the quickest ways to kill the spirit of a great employee is to put them in an environment where they can’t succeed. That’s when most people leave. Even good product managers become tied of waking up and going to war every day. They spend too much time trying to change the policies so that they can succeed at their job rather than building the best product they can.

The truth is that most organizations out there are not product-led. And yet, being product-led is a winning strategy. If you look at some of the best companies out there today – Amazon, Netflix, and Google, for example – they are not reactively building whatever customer request comes their way. They are not following Agile processes blindly to build whatever features they can, as fast as they can. Instead, they are developing products with the intent to deliver value to their customers.

Six questions to determine whether a company is product-led

  • Who came up with the last feature or product idea you built?
  • What was the last product you decided to kill?
  • When’s the last time you talked with your customers?
  • What is your goal?
  • What are you currently working on?
  • What are your product managers like?

Marty Cagan: Ordinary people, extraordinary results

  • Shocked by the difference between how most companies work, and how great companies work.
  • That difference is what keeps me doing this.
  • I’m not talking about the difference between Silicon Valley and others. I’m talking about the difference even within San Francisco between two companies on the same street.
  • Many of the best product teams I know today are scattered all over; Israel, India, China.

Product discovery

  • Product discovery is hard. It’s about coming up with a solution that addresses the four key risks: valuable, usable, feasible, viable.
  • There are more than 100 techniques available for product discovery today. So it can take a full day to talk about all of those.
  • A lot of teams now know this and how to work well, but their company doesn’t allow them to work this way.
  • Unfortunately, that means most people out there are not working in the kind of company and team that I’ll talk about today.


Empowered teams

  • In most organizations, technology teams exist to “serve the business”. This is a clear sign they are not using the best practices for product teams.
  • In a strong product organization, the purpose of a product team is to serve the customers, in ways that meet the needs of the business. The difference is only a few words, but it changes everything.

Some examples of others who have talked about truly empowered teams:

You should read all of these, they’re inspiring books about empowered teams:

So why don’t more companies truly empower their teams?

  • When pushed, a CEO will eventually give an honest answer, which is that they don’t really trust their product teams.
  • So who hired these people? Usually that sits at the leadership level.
  • Ultimately you need to get teams in place that you do trust.
  • Amazon, Google, Apple, all have different cultures, but are all very product focused. They can all trace back to the same source, which is Bill Campbell, the coach of Silicon Valley. He personally coached Steve Jobs, Larry and Sergey, and Jeff Bezos, during the formative years for their companies.
  • Not many people know this, because he hated publicity and didn’t want any focus on him.
  • Campbell was truly sincere about creating an environment where greatness can emerge from everyone on the team.
  • Those top companies follow this mindset of truly empowering people.
  • It’s not that they hire the best people, it’s the environment they hire them into that is different.

The role of leadership

  • Management and leadership is different. Not all managers are leaders.
  • Often people believe that with agile you need to have management backoff, but that’s not the case. You need them to manage, but not in a command and control way.
  • Leadership needs to:
    • Provide the product vision
    • Particularly the common objective across all teams
    • A compelling vision is also important for recruiting the kind of quality people you need
    • Product strategy – the plan for moving towards the vision
    • Not a roadmap, but more like a series of product market fits
    • Product principles – help us to make decisions
    • Product priorities – leaders need to set the priorities so it’s clear where to focus
    • Product evangelism – the bigger the company the more critical this is. We need missionaries not mercenaries.
  • One of the characteristics of great product managers: they are humble, and don’t pretend to know things that they don’t. They are aware of what they don’t know.

The role of management

  • Steve Jobs: don’t hire smart people and tell them what to do; hire smart people so they can tell us what to do. This is the heart of good management.
  • Recruit the team – this is where a lot of companies get it wrong. It’s the responsibility of management to get this right. May have some help from HR, but they are not responsible for this – the managers need to take responsibility.
  • Coaching – must be constantly coaching people and moving them up the levels. It’s hard to have truly empowered teams without managers coaching.
  • Objectives – managers need to play an active role in aligning objectives across teams. Not just let the teams set their own, but instead have a discussion back and forth to find the right objectives and key results. A manager can’t say we need to focus on growth and get 30%. But a manager can say let’s focus on growth, what result do you think you can achieve?

The basis of trust

  • Competence – a critical point. The average competence of PMs has gone down, not up. I think this is because the only training most PMs have had, is a certified scrum training – that teaches you how to administer Jira, or a backlog, and it does not teach you how to build product.
  • Before Agile, PMs actually were better, because the focus was not so much on managing a backlog.
  • Often the people hiring PMs do not know what good looks like. Typically those hiring engineers or designers have done that role before, but this is not always the case for PMs, they’ve never seen what good looks like.
  • You can hire for potential, but only if you have a manager that will coach them on a daily basis.
  • Character – New Zealand All Blacks, the most successful team across all sports over the last hundred years. They learned a long time ago that character is key – they screen out anybody that would be toxic for the team. They have the “no asshole rule”.
  • So, find competent people, filter out the assholes, and then you have a solid group of people to hire from.
  • Google has done a great job at looking into why great teams work, the results can be found in Project Aristotle. They found the best teams are not made up of rockstars, but ordinary people who are not assholes. The best teams have psychological safety.

The true test of empowered teams

  • The team is staffed with competent people with character, covering the necessary range of skills.
  • The team is assigned business problems to solve, and they are able to decide the best way to solve those problems.
  • The team is accountable for solving the customer or business problem (outcome).

Beyond Lean and Agile by Marty Cagan

  • Worked at HP as a developer for ten years. Worked on software tools for other developers.
  • Then worked for Marc Andreessen at Netscape. Had an amazing time there. Would still be there today if Netscape hadn’t lost the browser wars.
  • Then went to ebay and for the first time my customers were not developers, but rather buyers and sellers.
  • Started the Silicon Valley Product Group with some friends after this. Mostly advising startups and some growth stage companies.
  • At SVPG we are technique agnostic, and we didn’t invent any of them. Good product people know when to use which technique.

What’s the state of lean and agile?

  • There’s a backlash going on right now against these topics.
  • Pundits get involved and try to oversell any new method that comes up.
  • There’s another framework called Safe (Scaled Agile Framework), which I’m hoping nobody here uses. It’s used by banks a lot. I don’t know a single tech company that uses it.
  • Three principles of agile are still solid though.
  • There is a correlation between the number of “at bats” you get and the amount of success.
  • We need to go fast if we’re going to innovate.
  • Each iteration is something we can test, and learn from.

So what’s different about strong teams?

  • Have had an advantage, in that I’ve been able to work with really good people. Was introduced to Google when they only had six people.
  • When they do something well, I get those techniques and spread them around.
  • The best teams work very differently to the basic IT agile style teams do. They have taken the benefits of lean and agile, and taken steps beyond that.
  • 3 Key Themes
    • Risks
      • Product teams are typically happier to optimise, rather than take risks.
      • Good teams focus on tackling these risks early and often:
        • Value risk
        • Usability risk
        • Feasibility risk
        • Business viability risk
      • All the best teams know these risks and tackle them before their engineers go build stuff.
      • Not everything we build is risky, it’s clear that we just need to do it. If design, PM and engineering look at those four risks and are fine with them, then you just build.
      • Feasibility and usability are not that hard, but the other two are much harder.
      • Value risk is by far the biggest. Most things we think are valuable to users don’t turn out to be. Don’t know any company that has better than a 50% batting average on this.
    • Collaboration
      • Define products collaboratively, not sequentially.
      • You need all three roles working closely together. Design, engineering, product.
      • It’s a lot of give and take between them.
      • A lot of companies don’t have the right people doing these jobs. Some companies have the old IT developer mindset, who just want to be told what to do.
    • Results
      • It’s not that hard to ship things on time, and meet budget.
      • It’s hard to build things that achieve results.
      • a weak product teams are there to ship feature on a roadmap.
      • A good product team is there to solve hard problems.

Recommended book: Creative Selection by Ken Kocienda. Great example of a huge risk that had to be overcome, removing the keyboard from the phone and having the on screen iPhone keyboard. Very detailed description of how they worked on products with Steve Jobs.

  • Discovery and Delivery: this is not a process, it’s a conceptual model.
  • Start with an objective, rather than a roadmap. A clear problem to solve.
  • Discovery is about build to learn. Delivery is more like build to run a business.
  • Some call this dual-track agile.
  • You want to be doing something in the order of 15-30 iterations a week on discovery prototypes.

Truly empowered teams

  • This whole talk is predicated on having empowered teams.
  • The team must be staffed with competent people with character, covering the necessary range of skills.
    • Competent = Too many product people don’t know how to do their job. They have not done their homework. They can usually be trained, but if they haven’t been, they’re not up to the job.
    • Also no assholes on the team.
  • The team is assigned problems to solve, and they are to decide the best way to solve those problems.
    • It doesn’t mean they can go off and build whatever they want. It means they have a clear objective and is accountable for solving it.

Product is Hard by Marty Cagan at Lean Product Meetup

  • One of the hardest questions I get is, what is really the best way to split up our product team and who is responsible for what. This still takes a long time to break down, and I don’t have a crisp answer for it yet.
  • But what follows are some of the other questions that are more straightforward to discuss.

What are characteristics of good product managers?

  • One of the best books recently is Principles by Ray Dalio. It’s a bizarre culture, and definitely not for everybody. He talks about principles for how people should work, and also life principles, and those are gold.
  • He talks a lot about how to make a decision. First principles. But also the believability test. If somebody has expertise in an area, then it has more weighting. And this is a problem for many PMs, they don’t do their homework, so then you have a situation where the CEO is meeting customers every week, and the PM hardly does. PM shouldn’t decide anything if they’re not out there with customers at least as much as the CEO. And you need to share what you learn so that others see that you are believable.

Meetings all day, no time for doing real work

  • This is very common for product managers, particularly at medium to large companies. At a startup you’re incredibly busy, but at least it’s real work.
  • I don’t know how you can do this job if you can’t find four hours of quality time a day to work on real PM things.
  • I’ve got to the point where if I don’t turn on airplane mode on my phone, I can’t get through anything hard.
  • A lot of PMs, particularly in the Valley, are getting those four hours from 6-10 at night.
  • The other way, is to stop going to all these meetings. Product people feel like they have to be at every meeting their product is talked about.
  • Four hour a day reality.

We can’t find enough engineers or designers locally

  • The results, particularly for innovation, for a co-located team are much better.
  • Remote employees are better than contractors and outsourcing.
  • If you can have a tech-lead sitting with you, then they can at least talk to the other engineers sitting elsewhere.
  • If we can’t keep the three roles together (design, engineer, PM), then ability to solve the problems drops way down.
  • Contractors are mercenaries. And to solve hard problems you need passion, and to be a missionary.


  • The dual track model is how good modern product teams work.
  • But most agile teams are actually waterfall.
  • What makes something waterfall?
    • Requirements drives design which drives code
    • Result is output
    • All risk is at the end
  • Even if you’re doing two week sprints, but those three things above are happening, then it’s still waterfall. It’s better that it’s two weeks instead of three months, but it’s still the bad way of working.
  • Dual track agile is designed to avoid those three characteristics
    • Tackle risks up front
    • Define collaboratively
    • Outcome not output

We’re in a regulated industry, how do we experiment?

  • Leverage opt-in techniques
  • Lower expectations on level of confidence
  • Lean more on qualitative learning

Our execs are addicted to roadmaps

  • Maybe the single most common product team frustration
  • I understand leaders here, they are trying to run a business, they need to know when things are going to happen
  • Outcome-based roadmaps.
    • Transition to this, can take about a year to do though.
    • Keep doing the roadmaps you’re already doing, but immediately start adding what the business result is once you complete the items on the roadmap.
    • Then every time you talk about that roadmap item, you talk about the KPI.
    • Once it goes live, you start reporting on that business result.
    • The board level should care about business results, which you are highlighting here. It’s the middle management layer that cares about features.
    • Keep returning to the KPI you expected and the result you got.
    • If you want an empowered product team, you’ve got to give them the problems not the solutions.

Our technical debt has overwhelmed us

  • Early at ebay we lost a third of customers due to tech debt issues
  • Netscape lost the browser wars due to tech debt
    • Three points:
      • This issue needs to be treated as a business continuity issue – it can literally kill companies
      • Dial up engineering capacity and down product and design
      • Pick your battles
  • You cannot avoid having tech debt. You need to control it though. Do not let it get way out of control.
  • We’re not even talking about the point of having major outages. If you cannot respond to the needs of the market or your customers, because it takes your engineers so long to build anything, then tech debt is not in control.
  • Ultimately it’s the CTO’s job to ensure the systems and architecture can meet the needs of the business.
  • Sometimes CTOs say that product won’t let them address it. But the CTO is wrong for even asking the head of the product. This stuff is not up to the head of product.
  • If you’re in serious trouble, you need to make a call to dial down product and dial up engineering.

If OKRs are so great, why are they so painful?

  • I’m hoping for a better system to come in the next few years.
  • Too many teams have too many problems when moving to OKRs.
  • The point of OKRs is to have a clear objective for the business, and a measurable result.
  • It’s not implement a feature.
  • For most teams, who are not empowered teams, OKRs just bring the issues to the fore. Which means it is difficult to recommend them to everybody.

My engineers just aren’t excited about what we need to do

  • It’s the responsibility of the PM to excite the team.
  • Bring them to see users and customers in person. Particularly users who have a clear pain.
  • Share the full business context. Life time value, cost per customer, share all of the economics. Anything that adds context.
  • There’s so much innovation in the developer platform space (AWS is a great example). Developers are really good at innovating when they clearly see the problem.
  • Engineers are consistently our best source of innovation.

My CEO tells me what to build and to just “trust him”

  • Often the PM has not done their homework.
  • But when they have done their homework, sometimes they don’t share what they’ve learned enough.
  • When there is a disagreement, try to run a quick test, so that you have some data rather than opinions.

The Marty Cagan special – ProductTank #27 Singapore

  • Will talk about the most common mistakes that companies make when they move to this new model of product.
  • At SVPG we like to share how good teams do good products.

Most Common Problems

Thinking your job is product owner rather than product manager

  • The average skill level of PMs over the last few years has dropped.
  • Most companies have moved to agile, but they knew they needed product owners for this. So they took project managers and business analysts and made them product owners. They then trained them on a scrum certification.
  • But becoming a product owner does not make you a product manager. That is the biggest problem I see today.
  • A product owner is an administrative job, not a product manager job.
  • The PM should also be a PO for the team. The PO part is about 10% of the job. It’s a small part.
  • The biggest issue I see out there is when a PO has been trained as a PO, and think they are a PM.

You need to be trained as a product manager

  • The best way to be trained as a PM is to work with a proven PM. Somebody who has been there and done it, and committed to coaching you. It’s the best way. It takes 1-2 years to build the skills to be a strong product person.
  • The tech industry has grown so fast, that many of the managers have no idea how product should be done.
  • This is the problem so many companies have: not having the right PMs.

Table stakes for a PM

  • Deep knowledge of your user and customer
  • Deep knowledge of the data customers generate
  • Deep knowledge of your business
  • Deep knowledge of your industry

On data aspects

  • User analytics to see what users are actually doing
  • Sales data
  • Data warehouse to see data changes over time
  • These three things give the PM a picture on the customers and the state of the product
  • A data analyst might be there to help, but the PM needs to know it themselves

Not tackling risks upfront

  • This is the heart of how we do modern product
  • We need to discovery a solution that is valuable, usable, feasible and viable (PM and design is responsible)
  • we need to deliver a solution that is reliable, scalable, performant and maintainable (engineering is responsible)
  • The model below is not a process, but a conceptual model.

Not thinking enough about ethical risks

  • A lot of concern about this in Europe right now, and also in San Francisco.
  • Think about Uber. Every morning thousands of Uber cars flood into the city and make things worse for travel.
  • We can build it, but should we build it? PMs need to start thinking more about this.

Gathering or defining “requirements”

  • A lot of issues we have in our industry today comes from the legacy of how it’s been done before, in industries like big banks.
  • If you think your job as a PM is to gather or define requirements, it’s not. This is at the core of the difference now.
  • The way we solve problems today is collaboration: between PM, design, engineers.
  • So many key products we admire today have come from engineers understanding the customer problem and bringing the perspective of what is now possible with the tech to solve those problems.
  • If you think your job is to define requirements, you really want to rethink your job.
  • You have to describe problems that need to be solved. You have to show your designers and engineers your customers pain.
  • But the solutions come from the give and take of the three roles.

Shipping features rather than solving problems

  • Releases aren’t even a thing anymore, we release with continuous delivery, possibly many times a day.
  • The purpose of the team is to solve problems in ways that our customers love, yet work for the business. This is really the only requirement we have.

Acting as “Gatekeeper”

  • The team views themselves as the gatekeeper for all of the ideas coming in from stakeholders.
  • Instead of fending off all of the ideas that don’t work, your job is to understand the problems and try to solve them for the customer and the business, not just spend your time validating ideas from stakeholders.

Not considering alternative solutions or approaches

  • A team will get excited about a particular approach, and spend too much time just on that one way of solving the problem.
  • Should be testing 15-30 ideas a week. Lots of ways to do that.

Spending most of your time on value capture rather than on value creation activities

  • Both of these activities are good.
  • Value capture is optimisation work, and tweaking pricing.
  • Value creation is expanding into new markets, or tackling new problems.
  • Meet so many teams that are just going after the low value tweaks, for small gains. You should do this, but it’s really the easy work that goes on in the background. The majority of your work should be on value creation.
  • Apple: make sure you are always creating more value than you are capturing.
  • Those companies focusing on value capture are scared, they are fearful of taking risks. Optimisation is avoiding risks.
  • Discovery is all about taking risks, but doing it in a smart way.

Not spending most of your time prototyping

  • Teams spend too much time on prioritisation, and it’s usually thinking about things we cannot know, like how much money it will make – we just don’t know at this point.
  • Stop worrying about prioritisation and start trying out a lot more ideas.
  • We should be trying out 50-100 ideas a month. This sounds a lot but it is not hard if you just use modern prototyping techniques.

Not leveraging both qualitative and quantitative learning

  • Apple and Google are doing both of these all the time, even though you might think Google is well known for quantitative and Apple for qualitative. You need to do both to answer different questions.

Not managing your time / playing project manager not product manager

  • To really do this job well, it takes about four hours a day. This is really working on the problems, working with designers or engineers, testing ideas with customers or stakeholders.
  • Getting those four hours is really tough for many PMs, because they feel they also have to play project manager.
  • You can do both parts of the job. Know many who do this. But those people often have to get their four hours in after hours.
  • PMs often feel this need to be there when anybody is talking about their product – but really you don’t. Try to get past that.
  • When coaching PMs, tell them they must get these four hours in. It still leaves some time for all the other stuff, like meetings and project management type work. But the product work must come first. You have to coach the mindset.
  • Jeff Bezos: you want to hire people that think like owners, not like employees. That’s a mindset thing.

Just to be clear, all teams should be running some form of agile as a minimum. But if you’re running SAFe, that is not what I mean, none of this is relevant if that is what you’re using.

Marty Cagan – Q&A – World Product Day 2020

  • Keep seeing dramatic differences between how great teams work and how most teams work. It’s an incredible waste of human talent.
  • Something Silicon Valley startups know: if you don’t solve the hard problems it’s game over. Great product teams are there to solve hard problems.

Remote discovery techniques

  • We’ve had a problem before the pandemic, where it’s too expensive for companies to staff their offices in San Francisco, New York, and London. It’s not scalable from a cost perspective.
  • When you talk about teams working well remotely, you have to separate it into two activities: discovery and delivery.
  • Delivery activities (code, QA, ship) can do at least as well remotely as a co-located team. We’re already optimising for teams to divide and conquer on the work anyway. The less interruptions the better.
  • Discovery activities are where the problems are. When you hear leaders like Jeff Bezos talk about the magic of co-located teams, it’s because of the discovery aspects, not delivery. Because they’re trying to solve very hard problems as fast as they can. This requires very intense collaboration.
  • One issue here: most product teams are actually feature teams, and they don’t really do any discovery anyway, so it’s a non-issue. For them it’s just a little design, and project management. That is not discovery though.
  • What I’m talking is real product teams. Some examples: Etsy, Trainline, BBC, The Guardian, and of course Amazon, Netflix, etc.
  • Three challenges to making it work:
    • Teams start reducing collaboration. It’s not that they don’t want to, it’s just more difficult to do. So people start saying: just give me the info and I’ll work on it. Collaboration collapses, and you’re back to the waterfall method. When you break collaboration you nearly or completely destroy your ability to solve hard problems. Product teams are not feature teams – rather than just building features and delivering a roadmap, they are instead given problems to solve. Collaboration is key.
    • Collaboration is built on trust. Trust is a fragile thing. When you’re face to face with somebody you have so many more non-verbal cues (which help develop trust). Email is the worst, slack marginally better, phone call marginally better again, and video call better. But it’s really fragile.
    • When working remotely it can be hard to find synchronous time together. One team said to me that the only time they can really get together is at 10pm at night.
  • You can overcome these three issues, but it’s just a lot harder.

The use of OKRs for teams

  • They are a terrible tool for feature teams. They think because Google is using OKRs then they must be a good thing to adopt. But Google doesn’t work like a feature team.
  • If you are an empowered product team then OKRs are a good match.

How to get management buy-in?

  • Worth looking at this article on the topic:
  • Getting the leaders to understand the role of technology in their company.
  • Most companies still don’t understand the necessary role of technology. They view it as an IT organization, as a cost center.
  • Some companies create digital business units, and kind of tuck it away.
  • Leaders have to understand this point. Have not seen any successful transformations without the leaders first understanding this.
  • What happens is that some technology-first company starts coming after you. Like an Amazon. And if they do that it’s normally too late, because it can take years to develop these necessary muscles. So you can’t wait until you have somebody who really knows how to build products like we’re talking about to come after you.
  • There are a lot of companies out there that are ripe for disruption.

Best practices for being outcome driven

  • Being outcome driven is really a core tenant of product teams. You’re responsible for the outcome, but also given the room to solve the problem.
  • It doesn’t mean that you don’t have tech debt to deal with, or other kinds of projects. But the project mindset is the problem.
  • If you’re on a feature team, and called a product manager, don’t fool yourself, it’s essentially a project manager job. You make sure it gets designed, added to the backlog, gets delivered – this is project management.
  • The problem is usually the product managers. They have to completely change their mindset, from project to product. They often don’t even know what that means.
  • Top companies don’t necessarily hire anyone better for the role, it’s just that they train them better and align them to proper product management, not project management.

How to be more product and outcome driven when working in Government environments?

  • US Government is terrible for this kind of thing. The UK Government is maybe a shining light that gives hope to others that Gov doesn’t have to be so terrible at technology.
  • It’s a very hard problem to solve. It’s hard enough trying to convince a CEO, but a head of a Gov agency is much harder.
  • When you have something to lose, you protect it. So it’s easier for a startup to adopt new methods. But not so easy for established companies, like Governments.
  • It’s important to note that discovery techniques are there to reduce risk and avoid failure. It’s much cheaper to identify things which don’t work in the discovery phase than on shipping it and finding out after – that is really failure.
  • Lean startup is a subset of the discovery techniques. These techniques are designed to reduce risk, waster, and avoid failure.

How to empower teams when their priorities are on infrastructure projects?

  • A typical product team is given 1 or at most 2 things to work on during a quarter.
  • The question is, how are those 1 or 2 things decided on?
  • The problem is lack of product strategy. Feature teams are just trying to please as many stakeholders as they can.
  • For tech debt (and infrastructure things), this is really not up to the PM. They should not decide on this work.
  • The PM and product team should be working on the 1 or 2 key problems to solve, not the tech debt items which should be managed by engineering.

Educating leaders on empowered product teams

  • The people who carry the most burden are the managers of PMs, designers, engineers. This is where the real challenge is.
  • Share articles, that can be shared with a CEO or leaders. Give people a copy of Inspired.
  • Talk to the leaders and ask them what they think about running a test. Take one team or squad, and let them try to run as a product team, and let’s see how it works.

How can you tell from the outside if a company has empowered product teams?

  • Due to the pandemic, a lot more companies are open to remote working now. Realise the main driver of that is actually the cost of having everybody in SF, NY, London.
  • You can now look for a company to work for pretty much anywhere.
  • An experienced product person can write their own ticket now, they are so in demand today.
  • Don’t worry about what kind of company you work for – consumer, business, etc. Just look at the hiring manager on LinkedIn, figure out where they worked and whether those companies were strong at product. And ask them that if you come and join, will you devote to the time to help me develop. I’m coming to this company to be coached by you.

What do you believe about PM that most others don’t?

  • What most people think about product, I consider complete and utter nonsense.
  • Saw an article about the difference between a PM and a product owner, but it was from a mindset from twenty years ago, describing the old model of the PM talking to customers and the PO talking to engineers. This is so obsolete. But it’s also distressingly common all around the world.
  • I find I’m mostly on the side of uncommon opinion about product.
  • Go to conferences and there are people speaking about product talking nonsense and I cannot believe the organisers have let them talk in front of all these people.
  • Processes like SAFe – what in the world are companies thinking?

How will collaboration between product and design evolve?

  • Both are super important, but they are very different.
  • You want a head of product, head of engineering, and head of design. They are very different skill sets.
  • The designer is responsible for usability.
  • The PM is responsible for value and business viability.
  • Honestly, most PMs are unsatisfied in their job, they didn’t really want to be doing project management on a feature team. They then tend to gravitate towards design.
  • What real designer would want to go work on a feature team?

Recommendations for PMs out of work due to the pandemic

  • A lot of the good companies are hiring remote workers now, and even hiring now without once meeting in the office.
  • A lot of people have extra time right now, so don’t waste this time.

Product Strategy: The Missing Link – Marty Cagan at Lean Product Meetup

  • Meet a lot of teams, and some even in Silicon Valley and SF, that are not allowed to work the way good teams work.
  • Went on a crusade to find out why. Started a multi-year effort around this.
  • Increasingly being more honest about the difference between being a PM on a feature team and an empowered product team. A PM on a feature team is really like a project manager.
  • Strategy; one of the hardest topics to talk about. Easier to talk one on one to company about it rather than generally.
  • For those that haven’t heard me talk: I’m all about the difference between the great companies and everybody else.
  • Amazon, Google, Netflix, Apple – four companies that have influenced me a lot. They have consistently innovated. They have very different cultures. But they share a commonality of empowered product teams.
  • But how does a company choose what problems to work on? That’s product strategy.
  • If you Google product strategy framework, you’ll get a lot of garbage – fill in the blanks sort of stuff.

  • Companies don’t do strategy well because it’s hard.
  • There are four things that are required:
    • 1) Ability to focus in on the critical business problems
      • Most companies don’t even know what focus is. They think it’s prioritisation.
    • 2) Generating insights on how to attack those problems
    • 3) Coordinated actions for each product team
    • 4) Active management of the work
      • Do not mean micro-management. But also don’t mean passive management. We need better management.


  • It’s not a secret that most companies really struggle with focus.
  • At this level, if you’ve got more than a few initiatives, you’ve got too many.
  • The ‘Pandora Product Prioritization System‘ – a blog post which describes exactly the opposite of what you want to do. They give fake dollars to stakeholders and let them buy whatever features they want. They were bragging about it. But remember that feature teams are there to serve the business, and product teams are there to serve the customer (in ways that work for the business). This is serving the business by adding features stakeholders want.
  • Could tell that this a recipe for disaster. They were going to get no innovation from this. And what happened: stock gradually went down and they got sold, they’re gone.
  • They were confusing Focus and Prioritization.
  • What does Focus really mean? It means two things:
    • Impact: Only a few things on your big list of work to do is really going to move the needle.
    • Throughput: If you try to work on too many things at once, everything slows down. You get more throughput if you limit the amount of things you work on – like Kanban.
  • How do you pick the high impact things to work on? That’s where the smart leader comes in. They really look at the data to decide what is going to have the most impact.
  • Organizations spend way too much time worrying about prioritization. They think about things that they don’t, and cannot know, like how much money it will make. Try to get them to stop looking at prioritization, and instead learn to focus.
  • Part of this is getting very good, and fast, at trying things out.


  • At most companies, they are too busy satisfying stakeholders to look at the actual insights.
  • Strong companies: insights are everything.
    • They can come from anywhere, but mainly:
    • Qualitative insights – conversations with our customers and users. Prospects, former customers, competitors customers.
    • Quantitative insights. Data is good, but it sometimes cannot tell why, which is where qualitative comes in.
    • Technology insights. The tech foundations are always changing. Things we couldn’t do before, we now can.
    • Industry insights. Good teams live for this, and share it with everybody around them. Great leaders are like learning distribution machines.


  • There are two ways to turn insights into action:
    • Command and control way, which usually turns into a roadmap.
    • The empowered team way.
  • OKRs
    • I don’t recommend them anymore. I used to be an advocate.
    • There’s a lot of OKR theatre.
    • The fundamental issue. The OKRs came from the empowered product team companies like Intel, Google. If you take a company with feature teams, and overlay OKRs, you get a mess.
    • The real issue is not OKRs, but moving to the empowered team model.
    • Empowered product teams require a real product manager, not a project manager.
    • OKRs are not about individual targets, or manager targets, they are about the product team.
    • The Objectives need to come from the leaders (based on the insights and focus areas). The Key Results come from the team.
    • If you don’t have these three things, then OKRs are not for you:
      • Empowered product teams not feature teams
      • Product team’s objectives not manager’s objectives
      • Active leaders not passive leaders


  • No strategy survives first contact with reality – there will be a lot of learning.
  • What do most teams do? They make roadmaps. This is all output, with a bunch of dates. This is not empowered product teams. This is what feature teams do.
  • Management at good companies is very hands-on, but not micro-managing. They’re removing obstacles. Letting the team come up with the right solutions.

In conclusion

  • It’s not that hard to know what really matters (for focus), it’s usually just a political issue. The board level usually knows. They can see something like retention, and it’s a fundamental issue that needs to be solved.
  • Problem is you have a lot of different stakeholders and they all have their perceived needs. So it becomes a process of trying to do a little bit for everybody.
  • Insights don’t just come out of nowhere. Good leaders are always preparing, studying the data. Using dashboards. Understanding the economics and dynamics of the company. At a company like Amazon it’s not unusual for leader to be tracking several hundred KPIs every day – they have a deep big picture view of the business. They’re doing their homework so that they don’t miss the opportunities.

I’ve been a student of product strategy all my life. I like the discovery part most, because it’s just fun. But the strategy part are the most important, and the most valuable career wise.

Best books on learning about strategy:

Beyond Lean and Agile by Marty Cagan at Lean Product Meetup

  • There is a growing backlash to agile. This is to be expected, as in this industry there is always something new that comes along. None of the techniques that come out are a silver bullet, people eventually realize this, and that starts the backlash.
  • But I believe the principles behind agile and lean are not going away. They just don’t go far enough for product companies. The best companies out there know this and have pushed on way ahead of everybody else – perhaps even a decade apart on how they work.
  • Average companies don’t really practice agile, it’s actually waterfall.

Three big themes

  1. Address major risks up-front
    • Value risk
    • Usability risk
    • Feasibility risk
    • Business risk
  2. Collaboration
    • Define and design collaboratively, not sequentially
  3. Focus on outcomes, not output
    • Good teams are given problems to solve and focus on results

The risks

  • Most teams don’t even tackle value risk, because they assume value – this is the problem with roadmaps, somebody assumed there was value in those items on the roadmap.
  • Usability you lean on your UX and product designers.
  • Feasibility you lean on your engineers.
  • Value and business risk are firmly on the product manager.
  • Too often product managers are more like project managers, who write stories. They don’t understand the customers, they don’t understand the business and how it really works.
  • Some people think getting certified in scrum is what product management is. This is ludicrous.
  • The purpose of an MVP is to tackle these four risks up front.

The Product Manager

  • It’s a ton of work. The PM needs to focus on the product.
  • Stop being a project manager.
  • Stop being a UX designer, making wireframes.
  • Need to take away product marketing as well, in most cases you need somebody specific on that.
  • Smart, creative and persistent. This is what a PM needs to be.


  • The best product teams you see PM, design and some of the lead engineers really working together to solve the problem.
  • They should sit next to each other.
  • This is where the magic happens.
  • Lots of companies ask if we can make this work with distributed teams. You will pay a price for having them distributed.

Outcomes over output

  • It is time for roadmaps to go.
  • Roadmaps are about output.
  • Roadmaps are the antithesis of agile and lean.
  • Stop giving teams features to build and give them problems to solve
  • This is what it means to be an autonomous and empowered team
  • This is a lot harder than just building features

Dual track product development

  • Objectives
  • Build the right product (discovery)
  • Build the product right (delivery)

Dual track: customer development

  • Single favourite technique for best chance of success is the customer development program
  • Develop a set of reference customers in parallel with building the product

Final word on the product manager

  • Using your time effectively as a PM is important
  • It takes about four hours a day of real time, using your brain, to do discovery
  • This could be time with the designer, or showing it to sales, or time with customers
  • You’ve got two choices:
    • From 6-10 at night
    • Or, get really disciplined with your time during the day. Start leaning on others. Stop going to all these meetings.
  • However you solve it, I don’t know how you do this job without four hours a day of this quality time

The Group Product Manager role

  • A player coach
  • Has 1-3 product managers they coach in a very hands-on way
  • As well a being a PM themselves

Favourite book on tech: The Hard Thing About Hard Things by Ben Horowitz

EMPOWERED – Achieving Extraordinary Results with Ordinary People – Marty Cagan

Key Points:

It’s not helpful to sugar coat things. It’s better to be honest and frank on a lot of this stuff.

Introduced to a lot of companies, and amazed by the difference between how great companies work and how the rest work. To me, that difference is unacceptable, it’s embarrassing, at this point in our industry.

Product Discovery – it’s my favourite topic, could talk about it all day. Focus on the four risks.

Teach a lot of companies this way of working. But find out later that they are not allowed to work this way. It bothers me, because I know that unless they work this way, they are almost certainly going to go out of business.

In great organizations teams are there to come up with solutions that customers love, but also work for the business. This is fundamentally different to teams which are just there to serve the business.

Truly empowered teams – this is not even new, this is old news. Here are some books that talk about it:

Why don’t more companies really empower their teams?

It comes down to trust. The leaders don’t trust the teams.

It’s also fair that they are mostly right – the product managers are mostly not the right ones to trust. But that is also the leaders fault for hiring them.

Amazon, Apple, Google = have consistently proven how to innovate on behalf of their customers. They have very different cultures. But they have something in common: all four founders were coached by the same person, Bill Campbell.

Etsy: Mike Fisher and Marty Abbott. Both went to West Point and served in the military. Examples of great leaders.

The Role of Leadership – five key responsbilities

  • Product Vision
  • Product Strategy
  • Product Principles
  • Product Priorities
  • Product Evangelism

Great product leaders, at all levels, acknowledged what they don’t know, and what they can’t know. They are humble.

The Role of Management – the three key responsibilities

  • Staffing
  • Coaching
  • Objectives

Most product managers are not competent. So who is helping them? It’s not their fault, it’s their managers fault. This is where I would point the finger the most – the managers of product managers.

Worry less about the company, but rather find a manager who has been there and done it, and is committed to coaching you for the next year or two. That’s the best way to learn product. The vast majority of people however, have never seen and done it.

New Zealand All Blacks have the No Asshole Rule. They’ve figured out that no matter how skilled you are, you can’t be an asshole.

Designers should sit right next to the product managers. The best ones are not just graphic designers, they are product designers.

Findings from Google Project Aristotle – it’s not the team of rock-stars that produces, it’s the team of ordinary individuals who happen to really trust each other, where they don’t have an asshole on the team making them feel unsafe or uncomfortable.

The true test of empowered teams:

  • Is the team staffed with competent people with character, covering the necessary range of skills.
  • The team is assigned problems to solve, and they are able to decide the best way to solve those problems. (This is the best test of whether you have an empowered team or not).
  • The team is accountable for solving the customer or business problem (outcome vs output)