More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
September 12 - October 31, 2022
In the empowered product team model, the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business). Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible, the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility).
There are two fundamental reasons why our customers and stakeholders aren't able to tell us what to build: First, the customers and stakeholders don't know what is just now possible
.c1
Second, with technology products, it's very hard to predict in advance what solutions will work.
.c2
Empowered product teams understand these inherent issues, and product discovery is about discovering a solution that our customers love, yet works for our business. We refer to this as product discovery to acknowledge that we understand what we can't know in advance, and to emphasize that our task is to discover a solution that is valuable, usable, feasible, and viable.
.c3
If you want to have truly empowered product teams, then your success depends very directly on these first‐level people managers.
sourcing, recruiting, interviewing, onboarding, evaluating, promoting, and when necessary, replacing the members of the teams. If you have an HR function at your company, they are there to support managers with these activities, but they are in no way a substitute for the manager in these responsibilities.
When I ask these leaders why they don't put people in place that they do trust, they usually argue that they either can't find, can't afford, or can't attract the level of people that Google, Amazon, Apple, and Netflix hire. I then point out to them the many people I know who have moved from companies like theirs to one of these leading companies, and how their performance dramatically improved in the process. And further, having worked with many people at each of these companies, I point out how ordinary the vast majority of the people on these teams actually are. Maybe the important
...more
If a product team is not effective, we need to look hard at the people on that team and see where we can help them improve as individuals, and especially as a team.
If you are a manager, you should be spending most of your time and energy on coaching your team. This means expending real effort on things such as assessing your team, creating coaching plans, and actively helping them improve and develop.
After a while, giving constructive feedback moves from awkward to second nature. But until then, force yourself to come up with some helpful constructive feedback every week.
Just to be perfectly clear here, at the performance review, nothing should be a surprise—everything should have already been discussed in depth, likely for months.
the product roles of product manager, product designer, and tech lead are not “junior” roles. Someone who needs to be told what to do every day is not cut out for the product person role. And this is also not scalable. You need people that can be developed into capable and competent product people—that can be given an objective and then counted on to find a way to get it done.
This is common but could there be ways to support junior folks in e.g. product management?
I still use this technique frequently. When I am working on a new keynote presentation, I force myself to write out a full narrative first, iterate until it's logical and compelling, test the narrative with people I respect and know will tell me the truth, and only then do I create the actual presentation.
Something I've intuitively done as well when I'm trying to figure out what I want to say with a particular talk.
“There will always be many good reasons not to ship, and it's your responsibility to figure out a way over, around, or through each obstacle.”
in a company, especially a large company, there are many people there to ensure that the assets are protected—the sales force, the revenue, the customers, the reputation—and getting things done in a company means understanding and respecting these constraints by coming up with solutions that work for the business.
If I had to boil it all down, I'd say that thinking like an owner versus thinking like an employee is primarily about taking responsibility for the outcome rather than just the activities.
You've all seen the frenzied product manager that spends her time rushing from meeting to meeting, constantly complaining about not having any time to do “real product work.”
.c1
When I start coaching on this problem, I begin by looking at how she is spending her time, and in the vast majority of cases, I find that the product manager is spending most of her day doing project management work, rather than product management work.
.c2
Of course, the project management work doesn't go away. Which is why my favorite answer to this problem is for the product manager to team up with a delivery manager who can take on the project management, so the product manager can actually focus on her job.
This is where project leads (and to an extent, Tech Lead) can help a lot.
Designers and engineers are skilled at solving for problems with many constraints. It is literally what they do every day. Similarly, product managers must be problem solvers as well. They are not trying to design the user experience, or architect a scalable, fault‐tolerant solution. Rather, they solve for constraints aligned around their customer's business, their industry, and especially their own business.
Good product companies try to determine how well the candidate can think and solve problems during the interview process. The issue is not whether the candidate actually knows the answer to a question. The issue is what does she do when she doesn't know the answer?
My favorite technique for developing good thinking skills is the written narrative that I described earlier. In that chapter, I warned you that for someone who is not used to actually thinking through hard problems, this technique can be truly painful. But those are the people that need this technique the most. And for some people, it is here that you'll realize they are not cut out to be a product person.
trust is most easily built if you do it before you need it. This requires deliberate effort.
I think imposter syndrome is a very healthy and necessary emotion, and an important signal from our minds. But most people misunderstand that signal. They think it's just natural fear and insecurities, everyone has them, and they need to simply overcome their worries and push past them. But I interpret this signal very differently. It is my mind warning me of the consequences if I don't do my homework and truly prepare.
When a customer is at a standstill (often referred to as a “showstopper”) because of some problem with our product, how does the product person respond?
.c1
One of the behaviors I love in companies that are truly customer‐centric is that leaders will usually proactively reach out to the product team and offer to help in any way they can. This sends a very clear message to the team as to their importance without resorting to micromanaging them.
.c2
Intentional Integrity: How Smart Companies Can Lead an Ethical Revolution
Check
Where you have truly empowered product teams, and the teams believe they are doing especially meaningful and important work. They sometimes get so wrapped up in that work that, by the time they look up from their computers, it's late into the evening. Or, a year flies by and they have taken literally no vacation (not so much a problem in much of the world, but a real issue in the United States and China especially). A good manager will notice this and discuss at the 1:1. She will explain how easy it is to burn out, how important it is to play the long game, and how the job is essentially
...more
Again, if you truly care about the happiness of your people, you know your actions speak louder than your words. The manager needs to be sensitive to this, and in fact go out of her way to share how and when she's personally recharging, being conscious about when she's sending emails, and how she's managing her time.
Eric Schmidt, Jonathan Rosenberg, and Alan Eagle, Trillion Dollar Coach: The Leadership Playbook of Silicon Valley's Legendary Bill Campbell
Check
Rules of engagement are simply an agreement with the teams on what type of visibility the leader needs in order to give the teams the space they need to work. What information does the leader need in order to trust? What context does the team need to understand to be successful? What does the team need to feel safe in surfacing risks and problems early or asking for help? It's important to emphasize that these rules of engagement typically evolve as the trust and learning is built over time, but establishing some agreement around what information to communicate when, can help both the leader
...more
Maybe another way to think of my alignment > independence point.
An excellent book to help you learn how to identify competence during interviews is Geoff Smart and Randy Street's Who: The A Method for Hiring (New York: Ballantine Books, 2008).
Check
take reference checks seriously, and do them personally—don't delegate this to anyone else. Be sure to ask if the person would hire the candidate again. One of the most important goals of a reference check is to try to identify candidates that are going to prove toxic due to their personality.
I think it's worth mentioning that I have found this program to be a very effective way to improve diversity in the product organization. This is because, unlike most hiring, you're not selecting people into this program based on their experience. You're selecting them based on their potential.
Re lowerimg the bar imstead of raising it
The manager eventually decides the person is not strong enough, discusses this with HR, and then HR forces the manager to document the issues in a performance review. The employee is then surprised and confused to learn she's not actually meeting expectations.
.c1
Whenever I have learned of this happening to one of the managers that worked for me, I considered it a serious performance problem of the manager and treated it as such. Usually this meant that I wanted to see the preparation notes for the weekly 1:1 going forward, and that I would also be discussing the performance issues with the employee directly (to ensure the feedback is making it to her).
.c2
One special case is worth calling out here, and that is when promoting an individual contributor to a people manager position. This is, of course, not just a more‐senior position, but a fundamentally different job, with very different skills and talents necessary. And it's critical that the person understand what's required and that she want the role for the right reasons. The main reason tech product companies have dual‐track career ladders is because money is not a good reason to make this career change.
While we need to understand the impact on our company, we need to never forget that all of the benefits derive from providing real value to our customers.
Normally, the timeframe for the product vision is between 3 and 10 years out. Very complex products and devices are at the longer end of this range.
Remember: stubborn on vision, but flexible on details. Sharing the vision is fine, but sharing a roadmap is very dangerous.
as an employee I have been most inspired by working for managers like Marty and Hugh Dubberly (and thank my lucky stars that I had that opportunity). One of the things they have in common is the way they inspire greatness. They were a little bit terrifying to work for, for the same reason: they both believed in me in specific ways and to a degree that I frankly didn't believe in myself. But I had so much respect, admiration, and love for them that I was going to do everything I could possibly do to live up to their expectations, however misplaced I thought they were at the time!
First and foremost, your topology choices should be guided by principles that support team empowerment. These include giving teams real ownership of the space of problems they will be responsible for, providing autonomy in their ability to deliver the solutions to the problems they're asked to solve, and alignment with various aspects of the company's customers, business, and technology.
While you should expect that there will always be occasional cases where ownership of work is ambiguous, a good topology should resolve more ownership questions than it raises.
Every team topology will require some sort of inter‐team dependencies, but an empowering team topology is one that minimizes these dependencies.
experience teams are most empowered when they are given as much end‐to‐end responsibility as possible. Such teams have a meaningful sense of ownership, more autonomy, and it's easier for them to see their impact on solving customer problems and achieving business results.
Many strong companies have found that a rich platform is a powerful tool for enabling a broader (end‐to‐end) scope of ownership for the experience teams. Platform teams reduce the load required to use the underlying technology, creating cognitive capacity for experience teams to own more aspects of the customer problems.
Here are a few warning signs that can indicate your topology could use some attention: You are frequently shifting developers between teams You must frequently step in to resolve dependency conflicts Your developers complain of too many dependencies on other product teams in order to ship simple things Teams have very limited scope of ownership Developers must deal with too much complexity in too many areas
As much as possible, you should try to keep your existing product teams intact. Your entire organization has made a big investment in establishing relationships to enable good collaboration.
Move scope, not people
product strategy requires choice,
In pretty much every company I meet, the leaders already believe they are reasonably good at focus. But, often, the company's leaders need a reality check on this topic. The sheer number of things they believe are critically important, and that need to happen this quarter, or this year, are often an order of magnitude too many.
