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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • The risk is dying.
  • I don’t say that lightly. It has happened in industry after industry.
  • Go back to Marc Andreessen’s Software is Eating the World article. It’s seminal. He is saying that if you don’t take this seriously, this is what will happen.
  • 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:
  • 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:

Published by

Tim Woods

Product manager (formerly software engineer and marketing manager) with 17 years of experience in the field of innovation management. South Coast of England.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s