Marty Cagan, founder of Silicon Valley Product Group, is the renowned writer of ‘Inspired‘ the bestseller for product managers who want to build tech products customers love. With ‘Empowered‘, Marty, with the help of Chris Jones, writes the blueprint product leaders need to transform their organizations, and empower their teams to deliver on that inspiration. It gives the tools, mindset, and practical insights to excel as a product leader, and create the environment for success. I strongly advise to read this book which opens new horizons for product management, and innovation.
I read this book in 3 days in a row, stopping watching TV series or other entertainment! I’ve noted a few punchlines, energizing ‘mantra capsules’ to keep in mind for my practice, and I would like to share them with you. I’ve kept the People-related section to conclude, because, as they say: you always save the best for the end! It is worthy of mention that Marty always speaks of the product leader person as a ‘She’.
Product
Tech companies are from a peculiar type. Strong product companies differ from the rest in the way they view the role of technology, the role their product leaders play, and the purpose of their product teams (product managers, designers, and engineers).
So many companies have some similar sort of stakeholder-driven roadmap process, where they basically are trying to find a way to fairly divide up the engineering capacity across the different business stakeholders. This is very much what I mean by feature teams striving to serve the business, versus product teams striving to serve the customers in ways that work for the business. This is an especially clear example of the lack of product strategy, a lack of focus, and more generally, a lack of product leadership.
Feature teams look superficially like a product team. In strong product companies, teams are not given features to build, but problems to solve, and most importantly they are empowered to solve these problems in the best way they see fit, discovering a solution that customers love, yet works for business. Project management is not product management.
The four big risks that every product team needs to consider are:
- Will the customer buy it, or choose to use it? (value risk)
- Can the user figure out how to use it? (usability risk)
- Can we build it? (feasibility risk)
- Can the stakeholders support this solution? (business viability risk)
A fifth one should be: should we build it? (ethical risk).
A good product vision keeps us focused on the customer. It serves as the North Star for the product organization so that we have a common understanding of what we are hoping to accomplish together. It inspires ordinary people to create extraordinary products. It provides us with meaningful work. Be stubborn on the vision, but flexible on details.
Product strategy answers the questions: how do we decide which problems product teams should solve? How do we make the product vision a reality, while meeting the needs of the company as we go? It requires making tough choices, leveraging insights, converting them into actions (OKR), and active management. A true product strategy is based on focus and insights.
Risk management or (or innovation portfolio) is about placing a series of nets, knowing that only some will pay off.
Product knowledge covers user and customer, data, industry and domain, business and company, product operational knowledge. The purpose is to establish the reputation of the product person as someone who has a deep and personal knowledge of the company’s users and customers. Her job is not to ask her customers what to build: it is to innovate on behalf of the customers.
User research is all about insights, evaluative and generative.
A new product leader can start on business knowledge by filling out a business model canvas. He needs to understand the entire funnel from awareness to trials to on-boarding (AARRR). An analysis of the product data relates to your business model, your acquisition funnel, your customer retention factors, your sales execution data, and hundreds of other important indicators of the state of your company.
Half the battle, especially in larger organizations, is getting the relevant insights into the right minds at the right time. The head of product should aggregate the key learnings and insights from all the different teams in her areas, and at the weekly or bi-weekly all hands, summarize the most important learnings, and share them with the broader organization.
A product manager must be an expert user of her own product, using your own product on a daily basis (dogfooding), in order to be trusted.
In each and every case I know of where the company truly cares about theirs customers, it’s clear that it comes from the very top.
Learning from failure: have the team discuss what they believe was the root cause of their failure. Team objectives postmortems are not fun for the team, but they are typically very constructive and helpful.
Process
Process skills and techniques cover product discovery, product optimization, product delivery, product development.
Product discovery aims for a solution that is valuable, usable, feasible, and viable.
The 6-pages written narrative describes in narrative form the problem you’re trying to solve, why this is valuable for your customers and for your business, and your strategy for solving the problem.
Modern product management is all about true collaboration between, product, design, and engineering. The very act of creating and discussing prototypes and story maps facilitates true collaboration. They can also serve as an artifact, capturing the learning and decisions from the discovery work.
Product teams are all about problem solving: tackling risks early, solving problems collaboratively, and being accountable to results. How teams make decisions is often what separates the best from the rest. We want the parties to fell genuinely heard and respected, even if the decision ended up not going their way. We want the team, especially the product manager, to go one step further, and agree to commit to the decision that was made, even if they disagree with it.
Good decisions, especially in risky, consequential situations, begin by creating a plan of attack. In terms of specific decisions, I want the product manager to depend on, and usually defer to, the expertise and experience of her team. If you make collaborative-based decisions, and run tests for cases with disagreements, there will be very few situations of the product manager needing to override her team or escalate a decision up to senior management. For major decisions, I am a very big fan of the written narrative.
True collaboration on an empowered product team has a form of magic.
A product organization’s team topology answers questions such as:
- How many product teams should our organization have?
- What is the scope of responsibility of each team? (platform team, customer experience team)
- What are the skills required for each team, and how many of each skill?
- What are the dependencies between the teams?
The topology helps answer the question of how a company should organize its product people into teams to best enable them to do great work.
A topology can be aligned by customer:
- By user type or persona;
- By a market segment;
- By customer journey;
- By sales channel;
- By business KPI (new-user growth team, conversion team);
- By geography.
In term of actually getting the benefits of OKRs, there are 3 critical perspectives:
- Move from the feature team model to the empowered product team model;
- Stop doing manager objectives and individual objectives, and instead focus on team objectives;
- Leaders need to step up and do their part to turn product strategy into action.
Team objectives are comprised of an objective (the problem that needs to be solves), and some measures of progress (the key results). Back and forth is normal between product leader and teams, and there’s nothing wrong in assigning assigning the same objective to multiple teams, nor asking multiple teams to collaborate on the same team objective. The essence of effective team objectives is simply having a knowledgeable leader sit down with the product team, and explain the strategic context. Then explain the problem he needs the team to solve, and how success is measured.
People
People skills and responsibilities include team collaboration, stakeholder collaboration, evangelism, leadership.
Leadership is about recognizing greatness in everyone, and creating an environment where it can emerge. Help the person to first reach competence, and then to reach her potential.
Product Leader enables design, tech, product people to work together to solve hard problems, and create extraordinary products. They are responsible for the product vision, principles and strategy, evangelizing and converting the strategy in actions, organizing teams topology, staffing and coaching the product teams, and managing to results.
We want to hire product people that think like an owner and not like an employee. We want a team of missionaries, not mercenaries. We’re not hiring smart product people to tell them what to do: we’re hiring them to solve hard problems in ways our customers love, yet work for our business.
If you are a manager, you should be spending most of your time and energy on coaching your team. For product leaders, the product team is your product. You are not taking over control and telling the teams what to do, you are responding to their request for help. It’s more accurately described as servant leadership and you’re being asked to help remove an impediment.
Good people know they will get the best results when they are able to consider diverse points of view. They encourage their people to stretch beyond their comfort zone. They don’t hold back if someone is doing particularly well. They express a genuine interest in the person as a person, and not just as a member of the team. They look at people’s problems as opportunities to develop. They ‘walk the talk’ about team development. Most people in the product world want their work to be meaningful: this is usually the largest factor in happiness, even more than compensation.
Integrity is the foundation for good decision making in an empowered product team. Dependability (high-integrity commitment): it’s not sufficient to ship something when promised, it must actually work, solve the problem for the customer and the business. This is much more difficult. Rather than having personal agendas or ‘fiefdoms’, be perceived as not only understanding the overall objective of the company, but as sincerely committed to doing everything in your power to help the company succeed. Accountability for a product manager of an empowered product team means a willingness to take responsibility for mistakes. Optimizing for empowerment requires balancing between three interrelated goals: ownership, autonomy, and alignment.
The key to successful working relationships with stakeholders is establishing mutual trust. It’s about creating a foundation for trust.
It takes strong managers to be self-confident and secure enough to truly empower the people that work for them, to stand back, and let the team take credit for their successes. Reversely, you will find it very hard to retain people when they have so little sense of ownership over their work. Remember to praise publicly but criticize privately.
People join a company but leave their manager.
Leadership must be earned. It does not come with the title.
You don’t have to choose between empathy and authority.
Empowered product teams don’t need less management, they need better management.
Product leadership is based on sharing: sharing the vision, where you’re heading through prototypes, sharing the customer pain you’re addressing, sharing the learnings and insights from product discovery, sharing credit generously, sharing the value of the product through great demos, sharing your expertise on your users and customers, your data, your business, and your market, sharing genuine excitement, and sincere enthusiasm, sharing attention, spending a few minutes with every last person of the product team.
Rapid Innovation in Digital Time 
2 Comments