Marty Cagan – Q&A – World Product Day 2020

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

Remote discovery techniques

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

The use of OKRs for teams

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

How to get management buy-in?

• Worth looking at this article on the topic: 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.