Category: Marty Cagan

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.
    • Developing strong product managers: https://svpg.com/developing-strong-product-managers/
  • 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/

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.

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.

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.

Strategy

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

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

Agenda

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:

• Principles by Ray Dalio
• Work Rules: Insights from Inside Google That Will Transform How You Live and Lead by Laszlo Block
• The Culture Code: The Secrets of Highly Successful Groups by Daniel Coyle
• Legacy by James Kerr
• Creativity Inc by Ed Catmull
• Start-up Nation by Dan Senor and Saul Singer
• Turn The Ship Around!: A True Story of Building Leaders by Breaking the Rules by L. David Marquet
• Extreme Ownership: How U.S. Navy Seals Lead and Win by Jocko Willink
• The Art of Action by Stephen Bungay
• Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal

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

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

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

Process

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

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

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

Remote discovery techniques

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

The use of OKRs for teams

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

How to get management buy-in?

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

Best practices for being outcome driven

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

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

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

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

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

Educating leaders on empowered product teams

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

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

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

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

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

How will collaboration between product and design evolve?

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

Recommendations for PMs out of work due to the pandemic

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

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

• But how does a company choose what problems to work on? That’s product strategy.
• If you Google product strategy framework, you’ll get a lot of garbage – fill in the blanks sort of stuff.

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

Focus

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

Insights

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

Actions

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

Management

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

In conclusion

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

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

Best books on learning about strategy:

• Good Strategy Bad Strategy by Richard Rumelt
• The Art of Action by Stephen Bungay