Month: September 2020

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?

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.

Agile

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

OKRs

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

Roadmaps

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