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.

Introduction

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

Q&A

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?

• Ben Horowitz’s new book on culture is a recent good one: What You Do Is Who You Are.

Recommended people to follow

• There are lots, but it’s more important to just avoid the bad people. But here are three good ones:
• Teresa Torres
• Holy Hester-Reilly
• Petra Wille

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.