Category: Marty Cagan

• There is a growing backlash to agile. This is to be expected, as in this industry there is always something new that comes along. None of the techniques that come out are a silver bullet, people eventually realize this, and that starts the backlash.
• But I believe the principles behind agile and lean are not going away. They just don’t go far enough for product companies. The best companies out there know this and have pushed on way ahead of everybody else – perhaps even a decade apart on how they work.
• Average companies don’t really practice agile, it’s actually waterfall.

Three big themes

1. Address major risks up-front
   • Value risk
   • Usability risk
   • Feasibility risk
   • Business risk
2. Collaboration
   • Define and design collaboratively, not sequentially
3. Focus on outcomes, not output
   • Good teams are given problems to solve and focus on results

The risks

• Most teams don’t even tackle value risk, because they assume value – this is the problem with roadmaps, somebody assumed there was value in those items on the roadmap.
• Usability you lean on your UX and product designers.
• Feasibility you lean on your engineers.
• Value and business risk are firmly on the product manager.
• Too often product managers are more like project managers, who write stories. They don’t understand the customers, they don’t understand the business and how it really works.
• Some people think getting certified in scrum is what product management is. This is ludicrous.
• The purpose of an MVP is to tackle these four risks up front.

The Product Manager

• It’s a ton of work. The PM needs to focus on the product.
• Stop being a project manager.
• Stop being a UX designer, making wireframes.
• Need to take away product marketing as well, in most cases you need somebody specific on that.
• Smart, creative and persistent. This is what a PM needs to be.

Collaboration

• The best product teams you see PM, design and some of the lead engineers really working together to solve the problem.
• They should sit next to each other.
• This is where the magic happens.
• Lots of companies ask if we can make this work with distributed teams. You will pay a price for having them distributed.

Outcomes over output

• It is time for roadmaps to go.
• Roadmaps are about output.
• Roadmaps are the antithesis of agile and lean.
• Stop giving teams features to build and give them problems to solve
• This is what it means to be an autonomous and empowered team
• This is a lot harder than just building features

Dual track product development

• Objectives
• Build the right product (discovery)
• Build the product right (delivery)

Dual track: customer development

• Single favourite technique for best chance of success is the customer development program
• Develop a set of reference customers in parallel with building the product

Final word on the product manager

• Using your time effectively as a PM is important
• It takes about four hours a day of real time, using your brain, to do discovery
• This could be time with the designer, or showing it to sales, or time with customers
• You’ve got two choices:
  • From 6-10 at night
  • Or, get really disciplined with your time during the day. Start leaning on others. Stop going to all these meetings.
• However you solve it, I don’t know how you do this job without four hours a day of this quality time

The Group Product Manager role

• A player coach
• Has 1-3 product managers they coach in a very hands-on way
• As well a being a PM themselves

Favourite book on tech: The Hard Thing About Hard Things by Ben Horowitz

Key Points:

It’s not helpful to sugar coat things. It’s better to be honest and frank on a lot of this stuff.

Introduced to a lot of companies, and amazed by the difference between how great companies work and how the rest work. To me, that difference is unacceptable, it’s embarrassing, at this point in our industry.

Product Discovery – it’s my favourite topic, could talk about it all day. Focus on the four risks.

Teach a lot of companies this way of working. But find out later that they are not allowed to work this way. It bothers me, because I know that unless they work this way, they are almost certainly going to go out of business.

In great organizations teams are there to come up with solutions that customers love, but also work for the business. This is fundamentally different to teams which are just there to serve the business.

Truly empowered teams – this is not even new, this is old news. Here are some books that talk about it:

Why don’t more companies really empower their teams?

It comes down to trust. The leaders don’t trust the teams.

It’s also fair that they are mostly right – the product managers are mostly not the right ones to trust. But that is also the leaders fault for hiring them.

Amazon, Apple, Google = have consistently proven how to innovate on behalf of their customers. They have very different cultures. But they have something in common: all four founders were coached by the same person, Bill Campbell.

Etsy: Mike Fisher and Marty Abbott. Both went to West Point and served in the military. Examples of great leaders.

The Role of Leadership – five key responsbilities

• Product Vision
• Product Strategy
• Product Principles
• Product Priorities
• Product Evangelism

Great product leaders, at all levels, acknowledged what they don’t know, and what they can’t know. They are humble.

The Role of Management – the three key responsibilities

• Staffing
• Coaching
• Objectives

Most product managers are not competent. So who is helping them? It’s not their fault, it’s their managers fault. This is where I would point the finger the most – the managers of product managers.

Worry less about the company, but rather find a manager who has been there and done it, and is committed to coaching you for the next year or two. That’s the best way to learn product. The vast majority of people however, have never seen and done it.

New Zealand All Blacks have the No Asshole Rule. They’ve figured out that no matter how skilled you are, you can’t be an asshole.

Designers should sit right next to the product managers. The best ones are not just graphic designers, they are product designers.

Findings from Google Project Aristotle – it’s not the team of rock-stars that produces, it’s the team of ordinary individuals who happen to really trust each other, where they don’t have an asshole on the team making them feel unsafe or uncomfortable.

The true test of empowered teams:

• Is the team staffed with competent people with character, covering the necessary range of skills.
• The team is assigned problems to solve, and they are able to decide the best way to solve those problems. (This is the best test of whether you have an empowered team or not).
• The team is accountable for solving the customer or business problem (outcome vs output)

Key Points:

• Criticism of SAFE framework – it’s absolute nonsense. Banks and finance companies use this. Recommend to stay away from this.
• Find the best techniques used by the best companies and share them. Over time this builds up a body of knowledge we have at SVPG.
• People want a silver bullet. Something that works every time. None of these things work for every situation though. When is it appropriate or not, that is the question for each technique.
• Don’t recommend OKRs to product teams in most cases, because most teams are feature teams, not actual product teams. You need to have the empowered teams model to make it work. You get a complete mess when applying OKRs to feature teams. OKRs worked at Google because of empowered teams.
• The weak link in most companies is not the engineers or the designers, it’s usually the product manager.
• But I never blame the product manager. It’s really the fault of the managers of those product managers.
• There are so many people trying to tell PMs how to do their job. But they’re basically telling them how to be a project manager. No – that is not the job.
• Marty tries to give guidance based on what the successful teams do.
• Very smart people who know how to get things done. This is what Google originally looked for in PMs.
• APM programs are a good way to coach people. Define what it means to be a competent product manager. Being customer focused is key. The litmus test: your CEO should believe you as a PM know as much about the customer as anybody else in the company. This is critical. If they believe the sales people know more than the PM about the customer, they’re not going to listen to you.

The four most important aspects to the PM role:

1. Deep knowledge of the customer is always first.

Example when Marty was learning as a PM – his superior wouldn’t let him make a single decision until he had visited 30 customers face to face. 15 in the US, 15 in Europe.

2. The PM needs to become an expert in the data that’s generated.

It’s great to have a data analyst on the team. But it’s not enough. The PM needs to be an expert on how the product is used.

3. PM needs to understand your business.

Not your customers business (that’s no.1), but your business. A PM needs to know all aspects of the business. How it generates income, how marketing works, legal issues, ethical issues, etc. The PM really understands your business.

4. Understand your industry.

The trends, the landscape, the competitors.

It’s your managers job to get you competent on these four things before you can really make decisions.

Working remote can be OK. Lots of tools to enable customer testing and interaction. What is challenging is being remote from your engineers. You end up reverting to sending the engineers specs.

The four risks PMs should focus on:

• Value risk: would somebody even buy this product?
• Usability risk: could they figure out how to use this product?
• Feasibility risk: can our engineers figure out how to build this product?
• Viability risk: would this product be legal in the EU (for example)?

When thinking about prototypes, you have to ask which risk is it trying to address?

Empowerment means: who gets to decide?

In a feature team, management decides. The team is really just there to build.

In an empowered team, the team gets to decide.

Consensus model: I hate this model. Everybody has to agree to decide. It comes from people who have a good heart, they want people to feel included. But it goes wrong, I never advocate it.

The opposite end, the dictatorship model. The PM just says I decide. This is no good either.

The middle model is the collaborative model. The person who has the expertise makes the decision. If it’s technical, engineer lead decides. If it’s business viability, the PM decides. If it’s design, the designer decides. And run tests to prove it as much as you can.

An experienced PM can move between different industries. We’ve learned that domain expertise is less important than what people thought. It’s usually much easier to take a PM from a good team, who knows how to do product than to take a domain expert who doesn’t know product. Good product people love to learn new spaces.

There are some domains where the PM will need access to a subject matter expert though. Example of building a product for surgeons, you don’t have to be one yourself, but you need access to them to learn.

The most common reason people leave their job is because of their manager.