Category: Product Management

• 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

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