Review

A playbook for setting up empowered product teams inside your organisation. There’s an overlap with Inspired (which came 12 years earlier) but it isn’t awkward, empowered feels like a continuation of the same consistent philosophy.

This book is geared much more toward product leaders - but I’d encourage all Product Managers to read it, as you’ll know what you can expect from a great product leader.

The authors show restraint by avoiding cookie cutter frameworks, instead they favour listing considerations. That’s going to make this book timeless, and it makes the advice more actionable in my mind.

You Might Also Like…

Book Review and Summary: Strategize by Roman Pichler

Get a comprehensive review and summary of the best-selling book "Strategize" by Roman Pichler, the product management and strategy expert. Learn about the key principles and practices for developing and executing effective product strategies.

andrewclark.co.uk

Loved

I didn't enjoy reading this book. I found it to be a bit of a slog. I felt it repeated itself in places and tailed off towards the end. Yet it delivered on 'demystifying the Product Marketing Manager (PMM) role - which is why I picked it up.

andrewclark.co.uk

Inspired

Inspired is the Product Management bible. It covers the breadth of Product Management. Marty details the role, lists the common techniques and articulates the importance of product culture in organisations. Marty's style is to contrast good with bad, which is helpful but can come across as a little pessimistic.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

Lessons from Top Tech Companies

• Technology enables products in ways that are just now possible
• Product teams serve customers by creating products they love AND that work for the business
• Create an environment where everyone’s greatness can emerge. Create empowered product teams.
• Product teams should be..
• given problems to solve NOT features to build
• empowered to solve problems how they see fit
• held accountable for results

Coaching

• Perform a gap analysis → Show expectations (1-10) vs Capability (1-10)
• Then set a coaching plan → limit to 3 areas. Provide coaching, reading, training or exercises

• Anti-Patterns: not caring, micromanaging, talking not listening, skip feedback, not cutting loses
• Use the written Narrative Technique → writing out a narrative explaining your argument and recommendation Write a narrative of a few pages - follow with a Q&A (anticipate objections, write clear answers to them

• Do your homework - to give your product team the context they need to do a good job.
• There’s always reasons not to ship, it’s your responsibility to figure out a way over, around or through each obstacle.
• Performance should be measured by results.
• Give credit when things go well. Take responsibility when they don’t.
• Make time for product management work (don’t get stuck doing just project management work). Your highest-order contribution as a PM is to make sure the engineers are asked to build something that’s going to be worth building. Block at least 4 hours a day
• You need to have the ability to think and solve problems. The written narrative is a good way to develop your thinking skills.

• Channel imposter syndrome into doing homework, preparing, studying, thinking, writing, rehearsing and iterating.
• Demonstrate that you care about customers everyday Minimum 3 one hour customer interactions a week. What have you learnt from customers this week?

• On Decisions: Keep the outcome we’re striving for in mind when making a decision. Help stakeholders understand and respect our rationale. You want people to feel generally heard and accepted.
• Not all decisions are equally important or consequential. Consider the level of risk and associated level of consequence. You may want to collect an essential piece of information - you may be OK to make a decision with imperfect information
• Don’t make decisions by consensus, voting or by dictatorship
• Make collaboration-based decisions. Run tests for cases with disagreements (usually prototypes)
• Types of meetings: communication, decisions and problems. Do communication async, use written narratives to aid decision meetings.
• Ethics applies to every person and product team. Product teams are on the leading edge of where new products are conceived, developed and deployed. So we have special responsibility to consider the implications of our work

Staffing

• Trust is a function of competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive, and your intent with people. Both are vital.
• Don’t focus on ‘cultural fit’ focus on character (cultural fit: hire people who look and think like we do). We want people who think in a different way to us.
• Actively build your network of recruits
• Make recruiting a priority → if you need to hire, it needs to be your number 1 priority - spend 50% of your time it until it’s done.
• Don’t hire for domain knowledge - a great product manager will learn the domain knowledge before an OK product manager with domain knowledge learns to be a great product manager
• Move quickly - strive to offer within 24-48 hours.
• People don’t start with all the information they need. Help them understanding the customer. Get a product person to speak about the company . Workshop to apply what they learnt on the first day- safe space
• Don’t just consider the individual, consider the team. Remove toxic people - everyone has bad days, check if this is chronic or temporary
• Retention: people join a company but leave their manager

Product Vision and Principles

• On creating a compelling vision
• Customer-Centric → use the customer perspective, how will you improve their lives?
• North Star → helps team alignment, common goal, having the same end game
• Scope and timeframe → make it ambitious, 3-10 years, the future you want to create
• Leveraging trends → real trends are not fleeting, customers don’t care about tech
• You can validate the demand for the vision. You can’t validate the solution (because you don’t know that yet). It’s a leap of faith, betting on ourselves that we’ll be able to find the solution.
• On sharing the Product Vision
• invest effort in finding the best way to communicate it (goal is to inspire)
• Visiontype + demo + video → a prototype that’s smoke and mirrors but amazing
• Storyboarding → share an outline of a movie

Team Topology

• Warning signs:
• frequently shifting developers between teams
• frequently step in to resolve conflicts
• too many dependencies
• teams have limited scope of ownership
• developers deal with too much complexity in other areas
• Try to keep existing product teams together. Give existing teams new responsibilities, rather than break them up.
• Your choices should support team empowerment. Balance: ownership, autonomy, alignment
• Tradeoff ownership, autonomy and alignment
• Ownership → Needs to be meaningful - but not an over-stretch
• Autonomy → solving problems the best way they see fit - minimise dependencies
• Alignment → how well boundaries between teams track.
• Align to architecture - based on product vision, can make big decisions.
• Align to the business - how they relate to the organisation, the business units, market segments, customer types
• Experience Teams are responsible for how the product is experienced by users in the form of apps, UIs, solutions or journeys
• Be careful of teams owning just a small part of the end to end experience. Teams struggle to make an impact without coordinating with every other team, even for small changes.
• Give experience teams as much end to end responsibility as possible
• Satellite platform teams unlock empowerment for other teams by allowing them to take on more of the end to end scope and abstracting away complexity
• Experience teams are most empowered when they are given as much E2E responsibility as possible.

• The problem with the internal design agency model is that the designer is not in the room when key decisions get made. Design is too important not to be part of the product team.
• Optimise for the product team above all else

Product Strategy

• Features and projects aren’t strategy. Many leaders unwilling or unable to make touch choices, results in wasted effort.
• Strategy is about how you plan accomplish a goal
• Product Strategy is deciding which problems the empowered product teams should solve
• Strategy doesn’t cover the details → those are the tactics.
• Strategy is the overall approach and the rationale for that approach.

• Focus → Pick your battles. Focus on few truly critical priorities. Don’t let stakeholders buy what you work on! That’s a lack of strategy. You are prioritising but not focusing. WIP limits. You get more done if you limit the number of things in progress. Too many priorities will overwhelm the organisation.

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favourable outcomes Richard Rumelt -

• Actions → Turn insights into action. Give product teams problems to solve - not features to build. Teams will take ownership of the problem - if you give them freedom to pick a solution.
• You don’t actually need OKRs - you need a leader to sit down with teams and explain the strategic context, and tell each team which problems you need them to work on, and what business results they should measure.
• Inevitably - this isn’t going to be a straight line to implementation. Expect to uncover..
• Hidden dependencies, new technologies, new customer issues, senior stakeholders jump in
• Use 121s for coaching PMs through this → servant leadership. Keep checking in on progress - don’t let too long pass. Make sure relevant insights or new information is shared.

Team Objectives

• How to assign work in a way that empowers the team?
1. Give them a problem to solve - rather than a feature to build
2. ensure they have the strategic context - to understand the why and make good decisions
• Focus on a small number of meaningful objectives, and measure results based on business results (not output or activity)
• Objectives should be qualitative → as key results are for the quantitative part.
• Key Results → quantitative definition of success.
• Have a primary measure and some guardrail measures
• Let the team define the timeframe and specific numbers/values (as part of an informed negotiation)
• Don’t let the tail wag the dog → defining something that is easy to measure vs the most meaningful measurement

• It is the responsibility of the leaders to decide which problems go to which product team
• Great when teams volunteer - but the priority is to get as much coverage of the organisational objectives as possible. Somebody has to take the holistic view.
• If the key results provided by the team won’t move the needle - consider removing a different OKR from that team or ask another team to collaborate on the problem
• Align the product teams and the rest of the organisation.
• Allow for some ‘keep the lights on work’
• Make the level of ambition clear - often a relationship between risk and reward. A team might make a portfolio of bets. Attack a problem from different angles to reduce risk. Roof shot or moon shot.
• Empowered teams should be able to provide dates and deliverables when necessary (high-integrity commitment). Let them do discovery first.
• Shared team objectives → create a contract between teams, come back together to test
• Common objectives → pursue the same problem, but each team in does it in their own way. Use for risk management. You’re looking for independent approaches with a cumulative effect
• Active management is still needed in the quarter → Balance keep the lights on work with objectives. What have you done this week? Teams should share their progress regularly. Product manager should communicate important issues . Everyone in the product team needs coaching to overcome the problems they face. Alert early if high integrity commitments are going wrong. Help your colleagues. We all succeed or none of us succeed.

Business Collaboration

• Product leader needs a relationship with the CEO and exec. Need to demonstrate a deep understanding of the business and ensure solutions provided will work for the business.
• Product leaders are judged on: business results, product strategy, product teams
• Feature teams serve the business teams. Empowered product teams serve customers, with products that work also for the business. Treat stakeholders as partners not clients, understand their concerns, find a way to make things happen for the customer.
• Share insights that might help other teams, they might be able to build on your insight with their perspective
• The company needs to know the difference between failing in the market and a prototype failing in discovery.

Inspired, Empowered and Transformed

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Part 1: Lessons from Top Tech Companies

• Strong product companies can have different cultures (Amazon, Google, Apple and Netflix)
• Technology enables products in ways that are just now possible
• Product teams serve customers by creating products they love AND that work for the business
• Create an environment where everyone’s greatness can emerge. Create empowered product teams.
• Product teams should be..
• given problems to solve NOT features to build
• empowered to solve problems how they see fit
• held accountable for results
• Leadership need to inspire and execute.
• Inspire through..
• Product vision → shared goal, 3-10 years out, that describes the future we are trying to create - and how it improves the lives of our customers. Keeps product teams heading in the same direction and is a powerful recruiting tool.
• Team Topology → how we break up product teams across the work.
• Product strategy → the plan for achieving the vision (whilst meeting the needs of the business). Insights + focus → action + management.
• Product evangelism → communicating the vision, principles and strategy across the company.
• Execute through..
• Empowered product teams → are dependent on first-level people managers. These managers need to understand and effectively communicate the vision, principles and strategy.
• Staffing → sourcing, recruiting, interviewing, onboarding, evaluating, promoting and replacing team members.
• Coaching → Develop skills, understand weaknesses, improve them, provide guidance on lessons learned, removing obstacles, connecting the dots
• Team Objectives → ensure each team has 1 or 2 key objectives / problems to solve. Empower them to select measures of success / key results - and choose how to tackle the problems.

Part 2: Coaching

• Coaching is what turns ordinary people into extraordinary product teams
• The Coaching Mindset
• Developing people is job 1 → coach, assess, develop.
• Empower people → create an environment where people own outcomes not tasks
• Cultivate diverse points of view
• Seek out teaching moments → stretch others just beyond comfort zone
• Earn trust → actions speak, commit to develop each member, build rapport, show vulnerability
• Courage to correct mistakes → be prepared to let people go, who are taking too much time and energy

The Assessment

• Based on the three pillars of product: People, Process, and Product.

• Perform a gap analysis → Show expectations (1-10) vs Capability (1-10)
• Then set a coaching plan → limit to 3 areas. Provide coaching, reading, training or exercises

• Anti-Patterns: not caring, micromanaging, talking not listening, skip feedback, not cutting loses,

The Written Narrative

• Technique → writing out a narrative explaining your argument and recommendation
• Helps you move faster and make better decisions.
• Write a narrative of a few pages - follow with a Q&A (anticipate objections, write clear answers to them)
• If presenting - write the full narrative first, iterate until it’s logical and compelling, test the narrative with people I respect and know will tell me the truth, → then make the deck

Strategic Context

• For a product team to be empowered, they need to have enough context to make the right decisions. Here’s what they need:

Sense of Ownership

• Do your homework - to give your product team the context they need to do a good job.
• There’s always reasons not to ship, it’s your responsibility to figure out a way over, around or through each obstacle.
• Performance should be measured by results.
• Give credit when things go well. Take responsibility when they don’t.
• Your responsibility to motivate and evangelise your team.

Managing Time

• Make time for product management work (don’t get stuck doing just project management work)
• Your highest-order contribution as a PM is to make sure the engineers are asked to build something that’s going to be worth building.
• You need to find valuable, usable, feasible and viable solutions in product discovery
• That takes at least 4 hours a day - block the time

Thinking

• You need to have the ability to think.
• Intelligence and thinking are not the same thing. Acquiring knowledge and applying knowledge are two different things.
• Product teams are all about problem solving. Be makers and problem solves.
• Solve for constraints around customers, the business and the industry. Solving for the risks.
• Also have to think collaboratively - with the other disciplines
• Try to work out what your candidate does when they don’t know the problem. Critical thinking and problem solving skills are important.
• The written narrative is a good way to develop your thinking skills.

Team Collaboration

• Collaboration is not about consensus, not about artefacts and it’s not about compromise.
• Together we need to find a solution that works (valuable, viable, feasible, usable) → we need to know what we can’t know, admit what we don’t and focus on discovering something that works.
• True intense collaboration between product, engineering and design.
• Prototype as a team. Discuss the solutions. Design explore UX, engineering tech - PM considers the consequences of taking certain directions.
• Creating and discussing prototypes and story maps facilitates collaboration.
• Each member does their homework, relies on others to have done theirs and bring necessary skills
• Motivated people, skilled in their discipline.

Stakeholder collaboration

• Feature teams view stakeholders as the clients. Empowered product teams serve customers in ways customers love, yet work for the business.
• Don’t gather requirements from stakeholders → understand them and their constraints, treat them as partners that can help you come with a solution that works for customers and the business

Imposter Syndrome

• First → most healthy people doubt themselves - and are insecure about asserting their opinion over others.
• Second → imposters are a real thing.
• Channel imposter syndrome into doing homework, preparing, studying, thinking, writing, rehearsing and iterating.
• Managers and leaders → you’re only as strong as your weakest employee.

Customer-Centricity

• Demonstrate that you care about customers everyday
• Keep the term customer sacred - never use it to describe a stakeholder.
• Minimum 3 one hour customer interactions a week. What have you learnt from customers this week?
• How do you handle difficult or stressful decisions? Do you side with the customer? Are you acting with urgency to come up with an effective solution?
• Learn to like and respect your customers. The job is to innovate on behalf of your customers.

Integrity

• Empowered product teams are predicated on trust - trust is about both competence and character.
• Forces are constantly conspiring to challenge your integrity.
• Identify and avoid landmines, understanding priorities and the larger context and navigating the personalities.
• Dependability → word or commitment is taken seriously. Keeping high-integrity commitments.
• Act in the company’s best interest → not your team’s. Be engaged and committed.
• Accountability → sign up to achieve results. Take responsibility for mistakes.

Decisions

• How a product team makes decisions is often what separates good product teams from bad
• Decisions rest on a foundation of integrity
• Keep the outcome we’re striving for in mind when making a decision.
• Help stakeholders understand and respect our rationale.
• Want people to feel generally heard and accepted.
• Not all decisions are equally important or consequential.
• Consider the level of risk and associated level of consequence.
• You may want to collect an essential piece of information - you may be OK to make a decision with imperfect information
• Don’t make decisions by consensus, voting or by dictatorship
• Defer discipline questions to discipline leads.
• Make collaboration-based decisions. Run tests for cases with disagreements (usually prototypes)
• Make decisions and rationale transparent.
• Important to disagree and commit.
• Jim Barksdale’s 3 rules for decisions:
1. If you see a snake, kill it
2. Don’t play with dead snakes
3. All opportunities start out looking like snakes

Effective Meetings

• Meetings are painful because they’re synchronous. If there’s a way to serve the purpose asynchronously then do that.
• Best for status updates or information sharing
• 3 types: communications, decisions and problems.
• Communications: Only if too important or too complex to be sent via asynchronous means
• Decisions: use the written narrative if it goes beyond your team. Let everyone read it at the start, then discuss and make an informed decision.
• Problems: Get the right minds in the room to solve a problem. E.g. a postmortem
• Organising:
• Be clear on the purpose. Minimise attendees, make it clear who’s essential. Prepare. Facilitate. Follow up.
• Make sure if you call a meeting that it’s needed. Prepare for the meeting to make sure it’s efficient, effective and accomplishes it’s purpose.

Ethics

• Ethical risk can be considered the 5th risk (to value, usability, feasibility, viability)
• Leaders are going to be increasingly held accountable for ethical failures
• Public companies are too short-term focused, which results in compromising ethics.
• Ethics applies to every person and product team.
• Product teams are on the leading edge of where new products are conceived, developed and deployed. So we have special responsibility to consider the implications of our work
• Questions
• Is the solution good for end-customer?
• Does it have a negative impact on the environment or 3rd parties?
• If it and your emails were published on the front page would you be embarrassed?
• How would regulators react if they knew everything?
• Will you be proud of this product? Want it as part of your personal brand?
• Speak up in a thoughtful way, raise your concerns. Anchor in the best interests of the company.

Happiness

• Connect people to the meaning of their work - through their contributions. Reinforce publicly and privately.
• Connect people to their career progress
• Get people to like you because they know you’re committed to helping them succeed professionally and personally. Talk about personal things. Get to know them as people.
• Personal recognition → make sure people feel valued by people they respect.
• Work habits → If you’re working crazy hours, know if you’re doing it because you want to or because you have to.
• Model good behaviours.
• Career planning → acknowledge just how important a role you play in the lives of your employees.

Part 3: Staffing

• Common problems with staffing:
• Confusion about what to look for in product people
• Equating staffing with hiring (don’t just focus on hiring)
• Staffing isn’t the hiring managers responsibility

Trust is a function of competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive, and your intent with people. Both are vital. Stephen Covey (Author of: 7 habits of highly effective people)

• Hiring for competence is table stakes. You can hire based on potential too - if you have somebody who can coach them to competence.
• Don’t focus on ‘cultural fit’ focus on character (cultural fit: hire people who look and think like we do). We want people who think in a different way to us.

Recruiting

• Staffing begins with active recruiting. Identify what you want - go out and recruit.
• Actively build your network of recruits → meet people at meet-ups, competitors, during visits o customers and via introductions from referrals. Host industry talks at your office from industry speaks who will attract candidates. Company blog to the dedication to the craft of great product. Find them in other disciplines in your company. Build a personal brand as a manager.
• Make recruiting a priority → if you need to hire, it needs to be your number 1 priority - spend 50% of your time it until it’s done.
• Don’t outsource product teams → you’ll create mercenaries.

Interviewing

• Ensure you hire competent people of character. Every hire should raise the average.
• Product managers and tech leads are not junior roles.
• Select and curate the interview team - put your best people on it.
• Pass unanswered questions/concerns onto the next interviewer. Goal is to have no un-resolved questions at the end of the interview day.
• Tell the interview team - it’s a ‘competence hire’ or if a ‘potential hire’ is OK,
• Look for people who think differently - who add something new.
• Don’t hire for domain knowledge - a great product manager will learn the domain knowledge before an OK product manager with domain knowledge learns to be a great product manager
• Interview Question: Stack rank yourself against the following in strongest to weakest.
• Execution - getting things done
• Creativity - you are the person in the room with the best ideas
• Strategy - getting up above what you’re working on
• Growth - ways to multiply effort through process, team management and so on
• Self awareness is key!

Hiring

• Move quickly - strive to offer within 24-48 hours.
• Take reference checks seriously - don’t delegate them
• If they have multiple offers - get the CEO to talk to them.

Co-Location

• Co-location is important for discovery, less important for delivery.
• Avoid these remote anti-patterns: using artefacts for communication, trust and psyc safety declining without face to face connection (poorly phrased messages can break trust), hard to get time and space to think through hard problems.

Onboarding

• Put in checkpoints: 1, 7, 30 and 60 days.
• Correct any first impressions that aren’t positive.
• Make an assessment and create a coaching plan.
• Establish solid relationships with the product team and stakeholders
• Gain deep knowledge of customers and business (get out there and meet customers)
• If PMs are in short supply, create a APM program. Gives people an entry point, and a 2 year coaching program to learn how to become an exceptional product manager and leader.

New Employee Bootcamp

• People don’t start with all the information they need.
• Help them understanding the customer
• Get a product person to speak about the company
• Afternoon workshop apply what they learnt in the morning - safe space
• How are big decisions made? How have they been made in the past?
• What is important to the company now? What are we working toward?
• How can I get people to trust me?
• What’s the most important thing to do right now?

Performance reviews

• Would dispense with annual performance reviews.
• Make sure they’re not the primary feedback tool
• Managers need to provide honest, constructive and timely feedback.

Terminating

• Don’t just consider the individual, consider the team.
• Help the effected person find a different role in another company if you can
• Remove toxic people - everyone has bad days, check if this is chronic or temporary

Promoting

• Tangible sign of success as a manager to get people promoted
• If they’re willing to put in the effort, I’ll help them reach those goals.
• Perform an assessment → vs what’s required in the new role
• Discuss how to fill the gaps and demonstrate those skills before
• Approve a promotion - but there’s no open roles.

Retention: people join a company but leave their manager

Part 4: Product Vision and Principles

• A mission says nothing about how we plan to deliver on this mission
• An inspiring and compelling product vision..
• keeps a focus on the customer
• creates a common understanding of where we’re going, a North Star
• inspires people to create extraordinary products
• provides us with meaningful work
• leverages industry trends
• provides clarity about the future which helps with architecture decisions
• is the primary driver of team topology
• is a strong recruiting tool
• is a powerful evangelism tool

Creating a compelling vision

• Customer-Centric → use the customer perspective, how will you improve their lives?
• North Star → helps team alignment, common goal, having the same end game
• Scope and timeframe → make it ambitious, 3-10 years, the future you want to create
• Leveraging trends → real trends are not fleeting, customers don’t care about tech

Sharing the Product Vision

• invest effort in finding the best way to communicate it (goal is to inspire)
• Visiontype + demo + video → a prototype that’s smoke and mirrors but amazing
• Storyboarding → share an outline of a movie

Validating the Product Vision

• You can validate the demand for the vision. You can’t validate the solution (because you don’t know that yet).
• It’s a leap of faith, betting on ourselves that we’ll be able to find the solution.

Part 5: Team Topology

• How to structure your product teams?
• How many teams?
• What is the scope of responsibility for each?
• What skills does each team need?
• What are the dependencies between teams?
• Your choices should support team empowerment. Balance: ownership, autonomy, alignment

Optimising for empowerment

• Balance 3 interrelated goals of ownership, autonomy and alignment
• Ownership → More than objectives. Extends to functionality, experience, quality, performance and technical debt. Teams should make tradeoff decisions within their scope of ownership. Needs to be meaningful - but not an over-stretch (as they require deep understanding).
• Autonomy → solving problems the best way they see fit (doesn’t mean no dependencies). Minimise inter-team dependencies.
• Alignment → how well boundaries between teams track - with other aspect of strategic context.
• Align to architecture - based on product vision, can make big decisions.
• Align to the business - how they relate to the organisation, the business units, market segments, customer types

Team Types: Platform teams and Experience Teams

• Platform teams provide leverage, build common services used in many places.
• They do particularly difficult or specialised things - so everyone else doesn’t have to. Reduce the cognitive load for experience teams
• Existence isn’t obvious to the end customer.
• 50% of teams might be platform teams in a big organisation
• Experience Teams are responsible for how the product is experienced by users in the form of apps, UIs, solutions or journeys
• Maybe divided by user type, market, segment, customer journey step.
• Be careful of teams owning just a small part of the end to end experience. Teams struggle to make an impact without coordinating with every other team, even for small changes.
• Give experience teams as much end to end responsibility as possible
• Satellite platform teams unlock empowerment for other teams by allowing them to take on more of the end to end scope and abstracting away complexity

Empowering Platform Teams

• 10% should be keep the lights on work the other should be..
• Shared team objectives → Same objective as one or more experience teams. Sometimes requires deep collaboration. Determine the appropriate experience and how it should be implemented. Else, an API spec agreement allows teams to work independently.
• Platfrom-as-a-product objectives → External platforms - where your platform is the product. Many companies are managing internal platforms like they are external ones.
• The level of empowerment is comparable to experience teams.

Empowering Experience Teams

• Experience teams are most empowered when they are given as much E2E responsibility as possible.
• Create a topology that’s aligned to the customer.
• by user type
• by market segment
• by customer journey
• by sales channel
• by business KPI
• by geography

The problem with the internal design agency model is that the designer is not in the room when key decisions get made. Design is too important not to be part of the product team.

Topology and Proximity

• Remote offices are good blend of local and remote.
• Co-location of a team is a significant advantage.
• Proximity to other product teams allows for more efficient swarming
• Being close to business partners is an advantage too
• Optimise for the product team above all else

Topology Evolution

• Optimise for empowerment through ownership, autonomy and alignment
• Warning signs:
• frequently shifting developers between teams
• frequently step in to resolve conflicts
• too many dependencies
• teams have limited scope of ownership
• developers deal with too much complexity in other areas
• Try to keep existing product teams together. Give existing teams new responsibilities, rather than break them up.

Part 6: Product Strategy

• Many teams don’t have product strategy - just features and projects. Leaders unwilling or unable to make touch choices, results in wasted effort.
• Strategy is about how you plan accomplish a goal
• Product Strategy is deciding which problems the empowered product teams should solve
• Strategy doesn’t cover the details → those are the tactics.
• Strategy is the overall approach and the rationale for that approach.
• How to make the product vision a reality, while meeting the needs of the company
• Strategy is hard because it requires:
• Making tough choices → focus, not everything is equally important.
• Generating, identifying and leveraging insights (enable decision making and focus)
• Converting insights into action
• Active management without resorting to micromanagement

Focus

• Pick your battles. Focus on few truly critical priorities.
• People thing they’re good at this - they are not.
• Don’t let stakeholders buy what you work on! That’s a lack of strategy.
• You are prioritising but not focusing.
• WIP limits. You get more done if you limit the number of things in progress.
• Too many priorities will overwhelm the organisation.
• There is a real cost to an organisation - especially to the leadership, for each high-priority effort or initiative.

Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favourable outcomes Richard Rumelt

Insights

• There’s no silver bullet for coming up with these insights. It never happens without real preparation. Insights come from anyone or anywhere.
• Quantitative Insights → mine your live data, look for traction.
• Qualitative insights → User research is all about insights.
• Evaluative → what did we learn from testing a new idea
• Generative → uncovering new opportunities that we could pursue
• Look for generative insights even when you’re doing evaluative research
• Technology insights → new tech solving longstanding problems in ‘just now possible’ ways. You need to learn technologies that could be important to your industry
• Industry insights → follow key analysts in the space
• You then need to connect the dots between the insights. It’s really important to share learnings as you go, because leaders are often given the information they request not the information they need.

Actions

• Turn insights into action.
• Give product teams problems to solve - not features to build
• Teams will take ownership of the problem - if you give them as many degrees of freedom possible for coming up with a solution.
• Let them take responsibly for discovering and delivering a solution
• Intention → provide teams with the set of specific problems they each need to solve. Give them the space to determine the best way to solve those problems
• OKRs (Objectives and Key Results) is one of the better ways to manage this
• Objectives are the problems to be solved
• Key Results are how we measure progress
• You don’t actually need OKRs - you need a leader to sit down with teams and explain the strategic context, and tell each team which problems you need them to work on, and what business results they should measure.

Management

• Up to now:
• Focused on a small number of important goals
• Identified key insights that we will leverage
• Converted insights into actions for each product team
• Inevitably - this isn’t going to be a straight line to implementation. Expect to uncover..
• Hidden dependencies, new technologies, new customer issues, senior stakeholders jump in
• Use 121s for coaching PMs through this → servant leadership.
• Keep checking in on progress - don’t let too long pass
• Make sure relevant insights or new information is shared.

Part 7: Team Objectives

• OKR adoption has lead to disappointing results, for 3 reasons:
• OKRs clash with feature teams
• Managers have their own organisational objectives
• Leadership are missing → it’s about better management, not less management
• 3 prerequisites to OKRs:
• Move from feature team to empowered product team
• Stop individual and manager objectives - focus on team objectives
• Leaders need to turn strategy into actoin

Empowerment

• How to assign work in a way that empowers the team?
1. Give them a problem to solve - rather than a feature to build
• people closest to the problem are best to determine the solution
• more likely to take responsibility for achieving the outcome
• can’t hold them accountable if you ask them to build the wrong thing
• space makes room for a sense of ownership
• protection against the first idea not working (they’ll iterate and try others)
2. ensure they have the strategic context - to understand the why and make good decisions
• Team objectives are designed to give the product team space to define the solution.
• Focus on a small number of meaningful objectives, and measure results based on business results (not output or activity)

Good Objectives

• Don’t get too hung up on wording. An empowered product team can tweak the wording going forwards.
• Problems to solve not features to build
• Could be phrased as a customer or business problem.
• Objectives should be qualitative → as key results are for the quantitative part.
• OK if they require collaboration

Key Results

• How we define success.
• Define success by business results (aka outcomes) not activity, deliverables or outputs
• It’s an order of magnitude easier to ship a deliverable than to solve the problem
• 2-4 Key Results for each objective.
• Have a primary measure: Achieve A
• And some guardrail measures: While B,C,D
• Let the team define the timeframe and specific numbers/values (as part of an informed negotiation)
• Don’t let the tail wag the dog → defining something that is easy to measure vs the most meaningful measurement

Sharing Strategic Context

• You need to share context because
• The team need a deep understanding of the goal - and why its important
• Teams need to consider the insights as part of problem solving
• Teams to think through implications of work
• Great if teams express a special interest in solving a problem.

Assignment

• It is the responsibility of the leaders to decide which problems go to which product team
• Strategy tells us which problems to solve - topology will imply which teams are best positioned to tackle each problem
• Great when teams volunteer - but the priority is to get as much coverage of the organisational objectives as possible. Somebody has to take the holistic view.
• First step for a team - that’s assigned an objective is to determine appropriate key results
• if it’s the first time working in that area they’ll need time
• guidance from leadership on how ambitious or conservative to be
• If the key results provided don’t meet the company objective - consider removing an OKR from that team (if they have more than one) or ask another team to collaborate on the problem

Alignment

• Align the product teams and the rest of the organisation. Platform efforts are supporting - sales and marketing aligned.
• Allow for some ‘keep the lights on work’

Ambition

• Make the level of ambition clear - often a relationship between risk and reward. A team might make a portfolio of bets. Attack a problem from different angles to reduce risk.
• Roof shot → low risk, highly tangible results, optimisation
• Moon shot → 10x improvement, but high risk

Commitments

• Sometimes we need a team to make a high-integrity commitment
• Command and control comes form needing to know when things are going to happen
• Empowered teams should be able to provide dates and deliverables when necessary
• Only give dates leaders can count on
• Wait until the product discovery work is done - before making a commitment
• Not all dependencies need to be high-integrity commitments. Reserve them for external commitments, or very substantial internal commitments.
• Investigate the commitment - product discovery (valuable, usable, feasible and viable)
• For high-integrity commitments, the deliverable that is the commitment needs to be tracked independently of results.
• High-Integrity commitments are binary. CTO must agree to each one - their reputation is on the line.

Collaboration

• Shared team objectives → collaborate to create a form of contract with each other, then come together again for testing and deployment
• Occasionally you can swarm - highly collaborative spells where we dive deep together on discovery or a challenging problem
• Common objectives → pursue the same problem, but in your own way. Use for risk management
• teams need to communicate to deduplicate and remove conflicts
• looking for independent approaches with a cumulative effect
• You may have a product attribution problem

Management

• Active management is still needed in the quarter.
• Balance keep the lights on work with objectives
• What have you done this week? Teams should share their progress regularly.
• Product manager should communicate important issues
• Everyone in the product team needs coaching to overcome the problems they face
• Alert early if high integrity commitments are going wrong
• Help your colleagues. We all succeed or none of us succeed.

Accountability

• The companion to empowerment is accountability
• Given space and time to come up with solutions in exchange for responsibility and accountability.
• Accountability is related to ambition - if we calibrated ambition to high risk high reward strategy then it is expected.
• If the team fail - get together and do a post-mortem. Identify the root cause. Where did the leadership or management go wrong too?
• Attribution of key results is important for shared objectives / common objectives
• If you have strong traffic you can A/B test
• Else you can slice - key results by channel or source.

Objectives in perspective

• Keys to objectives:
1. Empower teams by assigning problems to solve - give them space to solve them.
2. Take a holistic view to cover company objectives
3. Allocating objectives to teams is the responsibility of leadership
4. If you don’t like the Key Results - then consider removing objectives
5. Objectives can be assigned to multiple teams
6. Teams can collaborate on the same objective
7. Product teams can only be held accountable if they’re empowered to define solutions
8. Keep the lights on activities need to exist
9. Make real progress. Team objectives need to change during the quarter.

Part 9: Business Collaboration

• Moving from subservient feature team model to collaborative empowered product model begins with trust (between the product org and the rest of the business)
• This is why you need a product exec - as execs will find it easier to put trust into peers
• Product leader needs a relationship with the CEO and other execs - need to demonstrate a deep understanding of the business and be committed to ensuring that the solutions provided will work for the various aspects of the business.
• Product leaders are judged on: business results, product strategy, product teams
• Stakeholder management vs Collaboration
• Feature teams serve the business teams. Empowered product teams serve customers, with products that work also for the business.
• Treat them as partners not clients, understand their concerns, find a way to make things happen for the customer.
• Shared insights and learnings across the business
• Insights might help other teams, they might be able to build on your insight through their lens. They might be able to better explain them.
• The company needs to know the difference between failing in the market and a prototype failing in discovery.
• Be wary of keep the lights on work crowding out the product strategy.
• Evangelism is an important part of the product leaders role:
• Use prototypes
• Share the pain (the customer pain)
• Share the vision
• Share the learnings
• Share credit generously
• Learn how to give a great demo
• Do your homework
• Be genuinely excited
• Learn to show some enthusiasm
• Spend time with the product teams

Part 10: Inspired, Empowered and Transformed

• Inspired with ideas and techniques for quickly evaluating those ideas and discover solutions that work
• Empowered to solve hard problems in ways customers love, yet work for their business

• The empowered team model should save money. Less will be wasted.