A Review of the Online Stanford Product Management Course

I recently completed the new online Stanford course Product Management: Transforming Opportunities into Great Products. Before signing up I had a look for reviews, but since the course is fairly new I didn’t find many, so I thought I’d share my insights for others considering the course.

In summary: it’s fairly short, well organised, and covers the basics of product management using a lifecycle framework. The video material is good, but a little basic. The main value comes from the reading materials for each section. Those reading materials are just links to freely available content though (which I’ll provide below), so you have to question if the $675 is really worth it.

For those who are brand new to product management, you’ll find decent value here. For those with experience, I don’t think you’ll find anything new, but the reading material will offer some good reminders on best practices. So in essence, you’re paying $675 for a refresher on good content for each major stage of the product lifecycle.

The course is broken into nine modules, with a final test at the end. The test is 20 multiple choice questions, and if you’ve been paying attention in the course they are pretty straightforward. The modules are:

  • Module 1: Course Introduction
  • Module 2: Overview of the Product Lifecycle
  • Module 3: Understanding the Problem Space
  • Module 4: Designing the Solution
  • Module 5: Launching
  • Module 6: Distribution and Go-To-Market
  • Module 7: Roadmaps
  • Module 8: Build
  • Module 9: Course Conclusion

It follows the flow of this lifecycle process:

Image for post

Each module has pre-reading materials, which is the bulk of the effort involved. After reading those, you then watch the videos which reinforce the key points made in the reading — the videos are fairly short, around 5 minutes or so each.

You get two months of access to the course, which is plenty of time — if you’re a fast reader, you can easily complete a module in an evening, and be done with the entire course in a week or two. It’s a little disappointing that Stanford don’t give you lifetime access to the course materials though.

Here’s a full list of the pre-reading (Modules 1 and 9 don’t have any pre-readings). The articles I found most valuable/interesting are marked with a *.

Module 2

Module 3

Module 4

Module 5

Module 6

Module 7

Module 8

Originally posted on Medium:


Marty Cagan, SVPG – Product Discovery, Product Strategy & Empowered Product Teams – Product Faculty

A really good Q&A with Marty by the Product Faculty in Toronto. Some good questions raised here that I haven’t heard on other Marty talks.

You’ve talked about the benefits of being colocated. During Covid, what advice do you have for teams to work effectively?

  • There’s no question that colocated teams are behind most of the best innovations.
  • But I’ve seen good work happen in distributed teams.
  • More often than not though, those distributed teams will struggle.
  • Product teams in general is doing two things: discovery work (figuring out what to build), and delivery work.
  • The nature of remote employees is different for each. For delivery it really doesn’t matter that much. It’s harder to communicate a bit, but you also get less interruptions. It’s a tradeoff.
  • But for discovery, which is really where innovation comes from, is where there is bigger impact.
  • Innovation happens through real collaboration. A designer, tech lead, PM, having their heads together on prototypes. It’s possible to do it virtually, the tools have never been better. But there are realities that get in the way:
    • When you’re sitting next to each other, there is a natural flow to just showing your laptop screen to each other.
    • As soon as you’re separated, it’s human nature to start asking things like ‘give me the design brief, give me the constraint, give me the user story … and I’ll work on it and then show it to you.’
    • Or the tech lead says, just tell me what you want me to build.
    • We move from a collaboration model to an artifact model – we’re exchanging artifacts. Then we’re on a fast train to waterfall.
    • It’s an unintended consequence. We’re no longer just going to lunch together and chatting together.
  • There’s some pragmatic things working remotely. People working from home may not have that much quiet time. The chance of two people both having quiet time at the same time gets lower.
  • When we sit face to face, we see the body language and know the intentions. You get the benefit of the doubt if I say something stupid. But on Slack or Email people don’t come across as well. And you break that trust.

Should we be doing user research right now, given that so much is different about the world in Covid times? Should we hold off or double-down?

  • Audrey Crane – one of the best thinkers on design, wrote an article about this question.
  • She argues that now is one of the best times to do user research. It’s much easier to get at the real insights.
  • Article mentioned: https://designmap.com/ideas/now-more-than-ever

Product managers doing user research – if you don’t have a dedicated researcher?

  • You don’t have to have it, although I love it. But you do need a designer on staff.
  • A product designer, who is trained on service design, interaction design, and user research, is a must.
  • They will get to insights faster and more reliably than somebody who isn’t trained in it.
  • If you don’t have a designer, then you have a much larger problem.
  • There’s no reason a PM can’t learn these skills, but what bothers me is that a real PM shouldn’t have time to learn and do these things. If you’re a feature team PM then you might not have that much to do and start looking for more things to pick up.

You said the best teams are running 10-15 experiments a week – could you elaborate more on that inspirational number?

  • We usually frame it as 10-30 iterations per week in discovery.
  • An iteration is very loose. It might be a small change to an existing prototype, or it might be three workflows for the same problem.
  • Each iteration should try at least one thing new or different.
  • We are trying an idea and get a sense of whether it is valuable, usable, feasible, viable.
  • The main thing is getting good at prototypes.
  • The designers are going to be creating 90% of the prototypes. There’s a whole suite of tools now available for them to do this. You can get to 50 iterations a week with this.
  • You need a skilled designer, and access to clients to test with.
  • With that said, you have to remember that number of 50 a week is a vanity KPI. It’s not a business result.
  • Get very good at it, as there’s a much better chance you’ll solve real problems, by trying more ideas and more approaches. But I’ve met several teams that thought they were successful because they could do 50 iterations a week, and that’s not true.

Do you think that learning about product growth, marketing, and positioning is becoming more important? Given that it’s easier to launch products, but harder to grow them, should PMs be learning more about growth?

  • Growth: is at the heart of product. This is one of the main goals. Growth marketing and hacking is product, but it’s applied to the funnel.
  • Differentiation: this is the product marketing role, and responsible for the GTM strategy. The product marketing role is a major area by itself.
  • Every good marketing person I know will say that the best way to be differentiated, is simply to be a great product. Without a great product, there is only so much you can do.
  • Look at Zoom. They took off because people consider it to be significantly better.
  • Slack tackled old problems, but tackled it so much better.

Why does a successful team not do some basic TAM analysis before going into product discovery?

  • Often the difference between great companies and the rest, is that they really have a well thought out data driven, and insight driven, product strategy.

Over the last 5-10 years, have you noticed that growth optimization is getting less valuable?

  • I’m a big fan of doing optimization. As soon as you have something live and have a good number of users you can start optimizing.
  • I’ve seen some companies that only do optimization. And here you see diminishing returns, no matter how good you are.
  • You should continue optimization in the background, but the breakthroughs will not come from that, they come from discovery.
  • What’s going on in these companies is that they’re scared, they’re afraid to take risks. Optimization is safe.
  • In discovery you need to take some risks, but that’s what you really need to do.

What’s the different between empowered vs feature product teams?

  • There’s really three kinds of teams out there:
    • Delivery teams. I don’t really talk about them because I just wish they didn’t exist. They have a product owner, not a product manager. Just a backlog administrator. Often lack a designer. Processes like SAFe or Less, they are just delivery teams. I don’t know a single tech product companies that use those processes, but a lot of banks and insurance companies that don’t have a clue.
    • Feature teams and product teams look alike. They have a designer, a product manager, and 2-10 developers. They both have squads. And that is good.
    • The difference is that in a feature team they are pressured to produce a roadmap, or are given a roadmap, with a list of features. They’re given these features to build, and the designer designs them. They may do some usability testing if it’s a complicated feature. And then it goes on the backlog and they build it. If that feature doesn’t actually solve the business problem, well, it’s not on them really, because they were just building the feature they were told to build. Feature teams are focused on output.
    • Product teams aren’t given a roadmap of features, they’re given business or customer problems to solve. They’re now held accountable to getting results.
    • In a feature team you really don’t need a product manager, you just need a project manager, as you’re just managing the work between design and engineers. It’s useful, but it’s not product management.
    • In product teams it’s much harder, now you really have to figure out a solution that works. The product manager is responsible for building something that is valuable and viable – these two things are incredibly difficult.

Are there examples of PM ‘normal talent’ that has been entrusted to be in an empowered product team?

  • Yes, there are examples of that, and examples of normal talent actually going to Google.
  • What frustrated me, is why don’t more companies work like Amazon, Google, Netflix?
  • One of the reasons you often hear is that ‘we can’t get the same calibre of people they do’. And that is not what is going on.
  • The real question is: what is going on when you get there (to these companies)? And it’s coaching. They have somebody who is showing them how it’s done. Managers take coaching seriously at places like Google. The reason people go there and do good work is that they have somebody there showing them how it’s done.
  • Most people struggle because they’re in a company where there is no-one to spend time with them and show them how it is done.

Is there a way to know how to hire the best product managers who you can trust?

  • It’s always been a hard position to interview for.
  • One of the best ways is to hire somebody from a great product company who knows how to do it.
  • If not, you’re making a bet on somebody. Two things:
    • We need to determine if they have the competencies to be successful.
    • Some of my favourite hires are university hires – you’re making a bet on their potential.
      • Only do this if the hiring manager has the time to invest to develop this person.
      • The Google APM program is this: find high potential people and putting them in a very intense coaching program, 1-2 years typically. It’s meant to turn you into a rockstar.

What’s the risk if you don’t take on the empowered team model?

  • The risk is dying.
  • I don’t say that lightly. It has happened in industry after industry.
  • Go back to Marc Andreessen’s Software is Eating the World article. It’s seminal. He is saying that if you don’t take this seriously, this is what will happen.
  • https://a16z.com/2011/08/20/why-software-is-eating-the-world/
  • A lot of companies still aren’t getting this, and the role of technology today.
  • Some companies can take twenty years to actually die. But if you stop innovating, you start that process of dying.

In Toronto we have a lot of B2B enterprise companies. An article in First Round talked about a Google PM joining an enterprise company and didn’t want to commit to anything beyond a few months. But it didn’t work, as companies buying a expensive enterprise software want to know what your roadmap for 1-2 years is. Are they making a safe bet?

  • Two things going on here:
    • 1: Is it reasonable for a prospective customer to know where you are heading before making a big purchase? This is absolutely reasonable.
    • 2: A different question is: is a roadmap the best way to provide that? I would argue absolutely not.
    • The roadmap doesn’t really tell them what they want to know. The roadmap just shows a bunch of features that may or may not work.
    • They all know the word roadmap, so ask for that. But what they really want to see is the product vision. And I’m more than comfortable sharing that vision – I want to validate that vision.
    • Amazon is a company that has succeeded both with B2B and B2B. They are great at the vision part. Be stubborn on your vision, but flexible on the details.
    • If you share the roadmap you’re not flexible on the details any more. You’ve now got commitments.
    • The vision is what people are buying into.
    • A lot of enterprise companies have no vision – what can sales sell? Let’s make that the vision.
    • When I hear somebody complain that they’re a sales driven organization, that is usually because they’re weak in product.
    • The product org needs to start working on the vision, taking this out to people and making sure it’s where people want it to go.

In thirty years of coaching, what is the one skillset that product managers have to do better at? Where are they falling short?

  • And we’re talking about empowered product teams, not feature teams.
  • First thing I do when coaching a PM is to do an assessment – I use this rubric: https://svpg.com/coaching-tools-the-assessment/
  • Everybody is different. People will bring different strengths.
  • If they’re coming from engineering, they have an advantage on the technology, but could be clueless on the business, finance, customers.
  • If we get a brilliant mind from business development, they have a good understanding of the business, finance, but no clue about design and technology.
  • That’s why it’s difficult to say one thing for all people.
  • But looking at the single most important thing in an empowered team, it is the notion of an empowered engineer. Every single innovation I know, there is an empowered engineer behind it. This is why feature teams almost never innovate.
  • This is the most important element of a real product team.
  • See this article about the topic: https://svpg.com/empowered-engineers-faq/

Where do I start to be a great Product Manager- with Marty Cagan

Marty Cagan gave this talk on Sept 12th 2020 with Indian-based The Product Folks. The first 34 minutes are excellent and I highly recommend listening to Marty’s analysis of product team types. The Q&A that follows is less useful in my opinion – as is often the case it seems the questions are not well organised, some repeat, and don’t ask Marty anything new or interesting.


  • Will be somewhat blunt and honest about the situation in product at the moment.
  • It’s harder today to be a new product manager, because there are so many voices that are so contradictory.
  • If you’re lucky you have a manager that knows what they’re doing, so they can guide you, and tell you the difference between those to follow and those who don’t know what they’re talking about.
  • There are a lot of different models out there for product management.
  • Today, I want to describe three models that are out there. I think only one of these is any good. Oddly the good one is also the least common.

The good, the bad, and the ugly (models of product management)

  • Feature teams are not all bad, it can be a lot worse. But what bothers me is the waste of talent on those teams. Feature teams are just disappointing. Everybody working on product deserves to be on a real product team.
  • You can be on a feature team and still learn something. But if you’re on a delivery team, you need to find yourself another company to work for.

Delivery teams (the ugly)

  • They exist to serve the business.
  • They have a product owner, but more accurately they are just a backlog administrator.
  • They are software factories. Given a backlog of things to build and they go deliver it.
  • Mostly what defines them is the process they use.
  • Common examples are at banks or insurance companies, that are using a process called SAFe. This has nothing to do with Agile – it’s just a marketing message to say it’s Agile.
  • This process is a delivery team process.
  • There is no innovation in this model.
  • If you’re in this environment, then nothing in my books or articles has any relevance to you.
  • There isn’t a single successful product company I know of that uses this process.
  • If you’re there, you need to move to a company that understands why SAFe is not a good process for product companies.
  • Let’s move beyond delivery teams, as any good product person would not be working for one.

Feature teams (the bad)

  • They are also there to serve the business. Not the customers.
  • They treat stakeholders in the company as if they are the customers. Head of marketing or sales, etc.
  • These teams are typically provided with a roadmap containing features to build.
  • They then design those features, do some wireframes, maybe some usability testing. Then put it on the backlog and engineers build, and QA test. This is common.
  • The product manager here is not really that, they are a project manager. It’s helpful. But it is not a product manager role.
  • These teams are like mercenaries. They just build what others in the company tell them to build.
  • They can’t feel any real ownership of it, and they can’t take any responsibility for real outcomes. It’s all about output.
  • These teams are not solving difficult problems.

Empowered product teams (the good)

  • They might look similar from the outside to the feature teams, as they have people with titles of product manager, designer, and some engineers.
  • But a huge difference. It starts with purpose: the empowered team is there to serve the customers.
  • They come up with solutions that customers love, which also work for the business – both together.
  • Instead of being given roadmaps with features to build, you are instead given problems to solve.
  • Examples of problems to solve: not enough customers renew every year; it takes a customer way too long to get live once they sign-up for the product; they have a hard time finding the merchandise they need to find; or they can’t pay successfully, etc.
  • If you’re given problems to solve, this is much harder than just being given a feature to build.
  • You have to figure out a solution that works. That is valuable, feasible, usable, viable.
    • Valuable = will somebody buy it and get value from it?
    • Usable = can they figure out how to use it effectively?
    • Feasible = can we actually do it with the tech and skills we have?
    • Viable = does it also work for our business?
  • If you look at founders of product companies, this is what they are doing in the early days. They are looking at valuable and viable solutions. They are then hiring designers to make it usable, and engineers to make it feasible.
    • This is why we say the product manager is like the CEO of their product.
    • If you’re on a feature team, this has no relevance to you. You’re not even close to a CEO of a product. You’re a project manager.
  • You sign up to an empowered team to solve a problem. If you don’t solve it in the first iterations, you’re not done. You keep trying.
  • The flip side to empowerment is accountability – you hold them responsible for the outcome.
  • The team as a whole solve the problem. There is a lot of back and forth between the roles. This is really important to understand.
  • Empowered product teams are small. Designer, product manager, between 2 and 10 engineers. You don’t switch people around. Teams need to go deep and know and trust each other, so durability is important.
  • In feature teams, the engineers are assigned different areas to work on each month. This is not what we’re talking about.
  • An empowered team doesn’t mean they choose what to work on – but they are given a problem to solve, and figure out the best way to solve it.
  • True collaboration between the team members is key.
  • Most of the time the weak link in the product team is the product manager. Often they are used to being a project manager, and that’s a problem on an empowered team.
    • An empowered product team that doesn’t have a skilled product manager almost never succeeds.

Transforming to empowered teams

  • Can you transform from feature teams to empowered? Yes – but it’s hard. And you can also go the other way. I’ve seen great empowered teams be changed by new leaders into feature teams.
  • To make the change:
    • You need the support from senior leadership, as it’s a big cultural change. You’re changing the role and relationship of the technology organization. You will need aircover from leadership to make it happen.
    • Then you must have the product leadership in place. The leaders of product managers, designers, and engineering. These three key areas must have leaders who know what they’re doing, otherwise there is no hope.
    • In places where it works, they have hired leaders from companies who have done it and know what to do.
    • Those leaders need to raise the bar on the teams. It’s typically not that hard for designers or engineers, but it’s hard to do for product managers. Not all product managers will make the transition.
    • They need to then reintroduce the team to the business. So that the transition is clear to everybody.
  • I’ve seen it done, but it’s very hard to do.


How has product management changed over your career?

  • Separate the role from the techniques.
  • See Ben Horowitz’s book The Hard Thing About Hard Things. The role has not actually changed much. What has changed is:
    1. the techniques have changed dramatically – what we have today just blows away what we had before. We couldn’t run live data tests and get results in a few days, for example.
  • But good teams, the principles are still there as before. Fundamentally good teams have always been about solving hard problems for customers. AWS, Alexa, the iPhone – real product teams are behind these. They work so differently to other teams.

Do you have a framework on how to make the switch?

  • If you’re in a company that is running like delivery teams – you need to get a job at a product company, even on a feature team.
  • If you’re in a feature team, I would suggest you help to transform, and start learning.
  • The company probably already knows at some level that they need to become better.
  • Go to the leaders and say, why don’t we try it out and work more like Amazon (or one of these comapnies) does? Most companies are willing to at least try.

What to look for in a company before joining them?

  • Once you know what to look for, it’s easy to see in the interview process.
  • Talk to product managers and ask them to describe what they do. You can tell if they’re a project manager or product manager.
  • Ask the leaders. What is the workflow? What are we responsible for? How do you measure a teams success?
  • You can learn the difference in five minutes by talking to any engineer. On a feature team they’re mercenaries, happy with the pay check. Engineers are missionaries on empowered teams. A very different level of engagement and investment. They also know they are the single biggest source of innovation on the team.
  • Read the blog post here to help spot the differences: https://svpg.com/product-vs-feature-teams/

How to get stakeholders more involved?

  • The product manager needs to have a close relationship with each part of the business – this is key to role.
  • But in terms of the team itself, the product manager needs an intense relationship with the designers and engineers.
  • You don’t need every engineer totally excited about everything, but you do need your tech lead to be excited and engaged, a missionary.
  • If you want mercenaries, just outsource development.
  • It should be obvious that you don’t outsource design and engineering, and if they’re on the team, then you want them engaged.
  • Every day in the discovery phase we should be creating prototypes – created by the designer. So every day let the engineers see them and play with those prototypes for a short while. Is there anything that makes them nervous in terms of feasibility? Is there some tech debt that makes implementing this hard? We want to know that early before we go much further.
  • Since engineers are working on technology every day, they have a better feeling for what is possible. Is there a better way to solve this problem, that the product manager and designer just don’t see yet?
  • 10-15 minutes every day is what you want from the engineers. This will get them engaged in what we are building.

Can an individual make this change or must it come from the top?

  • Don’t treat feature teams and delivery teams the same.
  • If you’re using SAFe or something like this, it’s almost always caused by the head of technology, or a CIO. In this scenario it’s very tough for an indiviaul to make a change.
  • If you’re in a feature team, it’s not so hard. There will probably be a lot of desire to move to empowered teams, they just don’t know how to do it.
  • Start by recognizing how the best teams work, and ask how we can implement more of what they do.

What is the best way for product managers to pick up the needed skills

  • There are more training programs for product people than ever.
  • Don’t fall for all of the certification BS – ignore that.
  • There is no good certification for this, believe me on that.
  • Most of the programs out there are teaching you how to be a feature team product manager.
  • This is due to the people who are teaching it have learned it by working on a feature team before.
  • You need to learn from somebody who has done it. Product is an experiential thing. You have to do it, and be coached.
  • The biggest benefit to your career is not training programs, but coaching by good product people.

What’s your view on product management consulting?

  • Product manager consulting has never taken off.
  • It’s always been the one role that hasn’t taken off in this way.
  • Unlike design and engineering, you cannot jump in and start doing useful things. It can take a minimum of three months before you’re even useful. Who wants to hire a consultant who cannot do anything for three months?
  • But there is a role called a discovery coach – somebody who knows how to do product really well. They’re hiring you to learn how to work better. They already have a product manager, so the discovery coach is there to help them work better.

B2B tend to split into feature mode more – because of the initial clients. How do the better ones tackle this?

  • The quality of B2B on average has been way worse than B2C software.
  • This is the main reason. Most B2B software is driven by sales. They are typically direct sales companies, and big customers ask you do things just for them – specials.
  • But this is changing, there are some really good B2B companies now.
  • The techniques are actually even better in the B2B world.

How to empower the engineers to be part of the day to day process

  • As mentioned above. Do the prototype of the day work – show them, 15 minutes every day engage them on what you’re thinking.
  • Looking for feasibility concerns or questions. And for ideas from the engineers.

Do you follow startups in India?

  • Not particularly. But I do follow Punit Soni who is great in everything he does.

Any other books you recommend for product managers?

Recommended people to follow

What would you do differently if starting out again?

  • Saw very early on that not all the teams were the same, and that it wasn’t about smart people or not smart people, it was something more fundamental.
  • But didn’t really understand what was going on. Found it conusing and frustrating.
  • It wasn’t until recently in the last 5-10 years or so that I really started to understand the dynamics of what was going on.
  • Didn’t originally call it product vs feature team, was more IT vs product team. But it’s become more clear now.
  • When you can understand the reasons for the behaviour it really helps. I wish I had understood that earlier in my career.
  • I would have only worked with the ones I knew were product companies if I had a way to tell this earlier.

Product404 – Marty Cagan (Product Leadership & Teams, Product vs. Feature Teams, OKRs, and more)

Empowered teams vs feature teams

  • Is there something PMs can do to push stakeholders towards empowered teams?
    • Most teams are feature teams, and doing almost no innovation
    • It’s not an easy change. Moving to agile doesn’t tackle any of this
    • Which is why companies get very little out of their digital transformation, because this is what they thought it meant
    • It needs at least three things:
    1. You need product leaders who know how to do this
      1. Without that the stakeholders won’t have trust in them to let them be fully empowered
    2. Redefine the relationship with the business
      1. Can just be the one team at first
      2. Once they are really ready to be fully empowered, they need to go to stakeholders and redefine what a product team means
      3. Feature teams are there to serve the business. Product teams are there to serve the customer, in ways which work for the business
      4. Moving from a subservient relationship with the business, to a partnership with the business
      5. This is only works if the product leaders step up and do their homework, and earn the trust of the leaders
      6. They must become experts on the customers, experts on how the company works – how does it sell, market, finance itself, etc.
    3. Educate the company on the role of technology
      1. The way people view technology is fueling the feature teams
      2. Do they view it as a necessary expense? Or view it as really what powers the business?
      3. This is the easiest thing to spot. Talk to any of the engineers, and you can tell how the business thinks of it.
  • In a feature team, the engineers and designers rarely have any respect for the PMs. They don’t understand what the point of them is. They do a little bit of product management work, which anybody could do, and that’s it. They’re not adding the value.


  • There are two issues here:
    1. There are way too many companies out there doing the rituals of agile and kanban, and still only releasing once every ten weeks. This is missing the most basic point of agile. The better companies are releasing at minimum every two weeks.
  • There are other companies who are doing this well, and probably doing continuous delivery. But it doesn’t mean they are agile in spirit – because they are still feature teams, doing quarterly roadmaps.
    • Agile really means you’re able to spear out difficult problems – this is not talked about a lot.

Team topologies

  • Book recommendation: Team Topologies – written by guys coming from the dev ops world.
  • One of the big factors to look at when structuring a team is the skills you need.
  • You want any product team to have clear ownership of something. If it’s a true startup, and the company is essentially one team, it’s easy. But once you get ten teams and beyond, then this becomes a much more complicated problem.
  • Head of Product and Head of Engineering have to figure this out together.
  • One of the issues we had before was lack of skills for native mobile apps – so that ended up being all in one team. But now it’s much less of a problem, so you can have those skills in any team.
  • But now the same issue is happening with machine learning – they have very few people who know it, so this factors into the team topology decisions.
  • Stable teams is key, so how do you do this when you have these scarce resources. You need to then create a team focused on that work – such as a machine learning team. That becomes like a platform team that others are dependent on.
  • We’re trying to optimize for teams that work really well together, and trust each other. Once we get something that clicks, then we don’t change it.
  • You don’t want to break up teams which work really well. Better to just give them more challenges, even if it means some time to learn and get up to speed together.


  • Have always been a fan of OKRs, but more recently have stopped advising companies to use them, because if teams are not empowered it doesn’t work.
  • Realized I was in a bubble with the kind of companies I was working with – OKRs worked well there. But in most of the world you’re talking about feature teams. OKRs came from empowered teams.
  • If you have roadmaps and OKRs, that doesn’t really make sense. Roadmaps mean feature teams. OKRs end up being just theatre and meaningless.
  • If you move to empowered teams, then OKRs are a good recommendation. It’s the most popular way to give those teams work.


  • It’s fair enough for the board to want to know what teams are working on. But a roadmap is not a guarantee that those things are going to produce the results they’re looking for.
  • They care about business results.
  • So you want to show the problems the teams are working on and showing the progress.
  • But lots of companies are addicted to roadmaps. And it’s just too easy to get stuck on feature teams and roadmaps.
  • It’s a fundamental change that needs to happen. Focusing on outcomes rather than on features and roadmaps.
  • Teams can move to an outcome based approach fairly easily – just do it for the next quarter or whatever cadence you normally have. What is harder is to train the rest of the company.
  • What matters here is then the leaders, they are the ones who can make that happen, or not.

Product management trends in 2020

  • Not seeing a lot of change honestly. There are just as many feature teams as ten years ago.
  • There are companies out there running SAFe, which is the polar opposite of what is great – this model makes feature teams look like a beautiful destination.
  • I can understand why leaders buy into this, it’s the same pitch as waterfall had. It’s just new buzzwords. They deserve what they get, because we’re talking about leaders which are really deficient. It’s natural selection in our industry.
  • The empowered teams however are getting better and better. The pace of innovation has really increased.
  • Lots of teams are just training on CSPO and thinking that’s it. In many ways teams have gotten worse than ten years ago.
  • The CSPO aspects is the administrative part of the job only, it’s like 5% of the work.
  • Encouraging companies to adopt APM type programs. An associate product manager is an entry level position, they are like apprenticeship programs. You need one very strong product leader who is willing to coach people. Doing this will raise the bar on product people.

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, Pendo.io, Mixpanel, Intercom, and Google Analytics are all data platforms. Some, like Intercom and Pendo.io, 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.