You have lots of responsibility with little authority: not a people manager
If it needs to get done, it’s part of your job: could be designing, coding, meeting with execs, anything. Will need to ask for help
You are in the middle: much of job is translating between needs, perspectives and skills of stakeholders and users
What is not product management?
You are not the boss
You are not building the product yourself
You can’t wait around until somebody tells you what to do
Good PMs don’t come from a particular profile. They just like to solve interesting problems, like to work with great people and learn new things
Bad PM archetypes:
Jargon Jockey: entirely obsessed over Scrum verbiage
Steve Jobs Acolyte: acts like Steve Jobs (but not really)
The Hero: always has some idea to save the day, even though team knows it won’t work
The Martyr: feels entirely responsible for project failure and puts pressure on others
Nostalgic Engineer: would rather write code than be stuck in meetings
Hard to quantify the impact of PMs, which leads to PMs following the archetypes and causing self-sabotage
Welcome unambiguity and learn to sail with it
Summary:
Accept that PMs will have to do lots of different things. No such thing as ‘only PM responsibilities’
Find ways to align, motivate and inspire team without needing authority
Be proactive about finding ways to improve team success
Be a connector
Remove miscommunications
Don’t get hung up on typical profile of PMs.
Don’t let insecurity turn you into a bad PM archetype
Ch. 2: The CORE Connective Skills of Product Management
The common UX - Development - Business Venn diagram for PM isn’t entirely accurate
The skills to create alignment between different functions is not the same as the skills needed to be part of a function
Varies from company to company
Communication:
Most important skill of a PM
Guiding principle: clarity over comfort. Should always risk discomfort for clarification
Organization:
PMs must organize their teams to work well together
Don’t want to be the bottleneck of your team. Team should know what is the highest priority and what they should be working on at all times
Guiding principle: change the rules, don’t break the rules
Research
PMs need to seek out and synthesize multiple perspectives
Should know their users and markets deeply. Requires asking difficult questions and challenging assumptions
Without research, your team will go along a pre-determined path but not understand why. Will always be playing catch-up with market and users
Understand that user’s do not have the same experience as you, so you need to experience, understand and advocate their realities
Execution:
Do what needs to be done
Hard skills are not as important as they seem, because the vast majority of daily work is not technical at all
Ch. 3: Showing Up Curious
Generating trust between different stakeholders requires curiosity in what they do
Pros of curiosity:
Able to learn hard skills contextually: understand why they are doing the things that they are doing and what skills are most important to them. You can take these skills and use it in other scenarios
Build bridges before you need something: relationships won’t be as transactional
Expand influence: network effects
Ground reports: can get the actual story of what is happening vs. a canned version from the top
Try to reach out to people who are not immediate members of your team. Doesn’t have to be totally pragmatic (i.e. could be someone from a wholly different part of the org)
Growth mindset is really important for PM success, because it will be near impossible to launch products without growth and learning
Being the smartest person in the room is not a path to success. You need to get rid of ego and ask for help from all parts of the company
Useful when dealing with ‘politics’. People are probably acting in a certain way for a certain reason. As a PM, be curious why they are acting that way, it could lead to a different result. Always ask: “what are their goals” and “what are they trying to optimize?”
Accept the gift of being wrong. If another decision is more closely aligned with company goals, then there is no good reason to simply reject it. That’s just being egotistic. Be willing to adapt and learn from why you were wrong
Great product managers should encourage the entire team to be curious:
Never shun away people who are asking questions, even if you’re trying to get your work done. Communication is your job!
Don’t feel shy to ask questions to anyone
Cross-polinate skills by asking different functions to work together/learn from each other. Eg: cross-functional pairing day, where designers and devs pair up and learn
Demo days are super useful
Ch. 4: The Worst Thing About “Best Practices”
Often times, PMs want to do product management like how it is done at big companies. This is bad for a few reasons:
Leads to an incurious mindset: you become more reliant on best practices rather than the messy and human elements of being a PM. Anything that doesn’t conform to best practices becomes a threat
Best practices focus on operations, not user value: focusing on best practices will shift focus away from users and more on streamlining processes, which isn’t always needed
May lead to disappointment: might feel jaded that you weren’t able to implement the best practice and you start to blame the company. Often times, there’s more to why you weren’t able to implement the practice
Shouldn’t avoid best practices, but need to keep the following in mind:
Don’t believe the hype: best practices are usually recruiting propaganda, so talk to actual PMs. The view from the inside is very different from the view from the outside
Not everything that worked before will work again: best practices may have worked in the past due to particular situations that cannot be replicated in your company.
Lots of trial and error to get to the best practice and this needs to happen at every company.
Changing the company into past company will not lead to success
Spend more time learning about the org before attempting to implement practices
Goals first, then practices: make sure that practices align with need of organization; otherwise, it will be met with resistance
Remember that best practices are places to start but no guarantee of success. Always keep the org goals in mind
Ch.5: The Art of Egregious Overcommunication
The downside of undercommunication can be reduced team trust and can even hurt you career. The downside of overcommunication is simply mild annoyance, which is far better
Err on always clarifying the obvious. It might seem condescending or a waste of time, but it is usually the fundamental issue of teams
Don’t approach meetings as something that needs to be fixed. There’s often a need for meetings and biasing people against them is not useful at all. Instead try to make sure the meeting is extremely productive
Seek out dissenting opinions and get commitment at the end of meetings. Silence should be intrepreted as disagreement. Try to set up small goals to test and learn if a decision cannot be made
Informal communication is often critical for team success. You can try to set up informal meetups on some cadence at non-productive times
Distributed teams:
Keep meetings short and to-the-point
Document everything
Call people to get that 1:1 talking time
Make space for informal communication
Try to be direct in your communication and don’t give room for ambiguity. Always back up with why you are communicating or making a request
Note that you often have to cater to different styles of communication:
Visual communicators like diagrams and quick prototypes
For asynchronous communicators (like to take their time before coming to a decision), try to give them a heads up before a decision is being made, or give them time
If some people don’t like to say no, ask questions that would prevent them from saying yes
Scenarios:
One stakeholder wants one feature to be done soon, the other stakeholder says that the feature can be done but needs much more time:
Best: try to find out why the feature needs to be done and explore other solutions to potentially speed stuff up
Avoid: agreeing to both sides, getting into the weeds about the time frame, relying on the roadmap to avoid the feature
Designer makes three different versions of same feature:
Could be emblematic of issues where designer not clear on project goals
Best: go through goals and get designer to make the best choice or try to see how to test the options
Avoid: choosing a version (skipping over the issue), decision by committee, “i don’t care, choose” response (kind of insulting)
If designer only chose one version, ask why they chose to go with that design. Could actually reveal miscommunication
Developer hates all processes that you have put
Signal that you did not communicate why the processes are important or you have put in the wrong processes
Best: take their feedback and make sure group knows so that you can act on feedback
Avoid: asking them to try it for a while (dismissive), completely skipping process (engineer becomes disconnected with users/business), self depreciation (doesn’t solve the problem and shifts blame)
Always choose clarity over comfort
Ch. 6: Working with Senior Stakeholders
PMs need to be skilled at managing up and making sure senior stakeholder wins are in line with user and business wins
Product becomes difficult when senior stakeholders cannot agree on a strategy & vision
Remember there’s no job a PM can’t do. Step up and voice your opinion on strategy and vison and let the senior stakeholder take the win. Better than having no vision
Be willing to push back and challenge if senior stakeholders are advocating for a decision that might not be best
Show the different options and tradeoffs that you need to make. It then becomes a group decision and not a us-vs.-them decision
Don’t shift blame on the senior stakeholders because that ruins the team’s connection with the rest of the org.
Instead, manage up for clarity and tell them why decision is not great. Even if the decision is forced, you will have an understanding as to why the decision was made. You can then take ownership and let your team know
Don’t create surprises for senior stakeholders. If needed, walk them through your decision and get buy-in. Remember, senior stakeholders always win; you just need to make sure your idea wins along with them
Big reveals of a decision usually don’t work. It’s much better to incrementally get buy-in and slowly change
How to stay user-centric amid company politics:
Use your users’ needs to make the case for why certain decisions should be made
Try to connect user needs and business objectives. They don’t need to be in opposition to each other
Include senior leadership when you are navigating user problems
Avoid compromises that will affect user experience negatively: manage up and get clarity
PMs need to resist the temptation to show off ability to work hard or ability to sacrifice their personal life when given a hard deadline by senior stakeholders
This doesn’t make anyone feel good
Better approach: ask senior stakeholders which current tasks could be deprioritized in order to meet the deadline. Much better than setting unreasonable demands on team
Scenarios:
Exec sees work of designers/engineers and doesn’t like it
Real problem: exec is not kept in the loop.
Best: apologize and try to figure out a strategy to keep the exec in the loop
Avoid: argue, mention past communication that exec never responded to or was lukewarm (remember, you always need to get affirmative commitment), change to exec’s opinion or just completely ignore the comment
Exec wants to reprioritize to another product
Best: understand motivations and discuss why it was not prioritized in the first place. Build a strategy to make sure exec has some voice when prioritizing on new features to prevent overriding current work
Avoid: agreement or disagreement (hurts team/exec), maybes (missing opportunity to understand why the exec wants to reprioritize)
Ch. 7: Talking to Users
Techniques to talk to users and vastly different to internal stakeholder management
When talking to users, your job is not to convince/impress/align. Your goal is to learn as much as possible about their needs, world and perspective.
Often, this means you need to play dumb and allow users to communicate as much as possible
Will probably need to work with UX designers or user researchers. They are extremely useful and should try to learn as much as possible from them
Even if someone else has the mandate of talking to users, you should still do it
Specific tricks:
Ask about specific instances, not generalizations: users find it much easier to describe their last instance (eg. what do you eat for lunch vs. walk me through last time you ate lunch)
Don’t get too excited if you hear what you wanted to hear: this biases the user and you don’t get a clear understanding of why they said what they said
Don’t ask users to do your job: users can rattle off feature requirements, but they might not have a good idea on the tradeoffs or if there is a better way. Understand their needs, not solutions
Don’t just listen to power users, listen to your entire audience
Questions with ‘why’ leads to defensive responses. Try to categorize your questions into either zooming into details or leveling up their goals and experience
Leveling up questions is basically asking ‘why’ questions and allows you to get to the higher goals and aspirations of the user
Ch.8: “Data, Take the Wheel!”
The idea of being ‘data-driven’ revolves around making better decisions using data. However, data can only drive decisions by so much
What the decision is or why we are making the decision cannot be decided by data.
Not all data and decisions are equal
PMs cannot just rely on data. We need to live the user’s reality, which is not consumed by dashboards and data reports
Don’t use data as a crutch to justify things; describe why and how the data supports a thesis
State assumptions when using data (often requires you to share contradictory data)
To find assumptions, ask: “What things need to be taken as true for intrepretation to be correct”
Encourage colleagues to note down your assumptions, as you might be blind to them
Focus on a single success metric for your product (Lean Analytics book)
Justify why you are using this metric and share. If company strategy is making it difficult to use metric to align with goals of company, ask yourself why and if you should change
Prevents vanity metrics which have no meaning and only make your product look good to outsiders
Data-driven experiments often involve intuition and then testing if intuition is correct
Even if things are going well, you need to understand WHY. Just saying a metric is moving up and right does not cut it
Need to supplement quantitative data with qualitative data
Sometimes, PMs are held accountable for particular increases in metrics even though a large part of what drives the metric is out of control
Rather than being accountable to the actual value of the metric, be accountable for the processes that change the metric. Understand what affects the metric and what your team can do about it
Some companies are taking one success metric too literally and trying to put all quantifiable info into one metric, which has no meaning outside of the company
Understand how the metric is constructured and what assumptions it uses
It might be useful, but its not very usable. Change way that you use the metric
Ex: NPS is useful for high-level indication of attraction of product, but it’s not very helpful when you try to use it to change behaviours. It’s also very easy to game (eg. different interpretation of question, different intrepretation of values, etc.)
Make sure to always tie technical details to product goals
Ch. 9: Realistic Roadmaps and Painless Prioritization
Roadmap: what you plan on building in the future
Prioritization: process of figuring out what is worth building now
Almost always roadmaps and prioritization don’t work so well in orgs with changing goals or powerful stakeholders
Everyone in org needs to intrepret roadmaps in the same way. Understand how roadmaps are used, who has access, frequency of change
Product managers rarely overtly own a roadmap since so many stakeholders have opinions on what should be built next
This should be a company-wide exercise. All relevant stakeholders need input
Create templates and define criteria to determine what can be added to roadmap
Don’t think of yourself as the “idea” person of the company. What matters much more than your ego is company success
Product specs don’t need to be ultra complex and should be conversation starters
Include questions that devs can think about when building
Perpetuates assumptions that you already talked to users and prioritized
Ensure that you are writing specs to communicate and tie to goal, not for the sake of writing a great spec
“Writing a long and detailed spec might help you feel like you’re doing a lot of work toward building a product, but it isn’t always the right work.”
Prioritization: most important thing is to make goals extremely clear. Prioritizing work will then be extremely clear
Involve devs and designers when prioritizing
Lots of goal-setting processes (SMART, CLEAR, OKR). Choose one that works well for your team
Radical Focus (book for OKR)
Implementing OKRs company wide is a little painful, so do it slowly, starting with your own team
Tip: test your goals by pairing up with senior leadership and prioritizing with features against goals
What do you do if your ideas that you need to prioritize are more shiny or new rather than useful and goal oriented?
Don’t dismiss new and shiny ideas. Understand why team thinks it’s cool, which can be pretty useful for other features
Make and protect time for team to learn, research and experiment (called spike in Agile parlance)
Sometimes, prototypes are really useful in validating ideas!
Emergency features from other stakeholders: ask them to write out a template describing why it must be fixed now and the impact
Significantly filters off requests that are actually not emergencies
Tactics for prioritizing: stack ranking and impact-effort matrix
Ch. 10: The Wonderful, Horrible Truth About Agile
Debunking Agile myths
Agile is a rigid and prescriptive methodology
Agile is not even a methodology, it’s a movement
Look at Agile values to determine if something is actually ‘Agile’
Agile is a way to do more work, faster
It’s about working differently. Might even be slower because needs some reflection
Agile is only for software development teams
Not true
Requires thorough reflection and improving specific parts of your workflow. Just implementing some methodology won’t solve all your problems
Implementing Agile
Figure out your process North Star: why do we even need Agile?
Pick some methodology: it doesn’t really matter what you choose because you will change stuff anyways
Regularly evaluate specifics of methdology against North Star: be serious about this because it can give you lots of improvement ideas
Improve the process with the help of your team: might even require killing ‘required’ parts of Agile methodology. That’s fine!
Caveats about Agile
Agile does not always address the ‘why’
Just because you are using Agile processes doesn’t mean you are solving user needs
Use the process to build the right things, not as a crutch
Agile rituals can become a false stand-in for user centricity
Agile needs to extend beyond your product team
External teams don’t need to adopt, but they should be aware
Ch. 11: In Good Times and Bad
Great product managers work on products that fail all the time. No magic set of guidelines that guarantees product success
PMs on established products have their own set of challenges: slow-moving, bureaucratic, hard to stay ahead of user needs
Sometimes, team goes into autopilot mode when no external challenges are detected and metrics are moving in the right direction
Extremely important to seek out challenging ideas & alternative explanations. Complacency is a disease
Use time-boxed prototypes to completely rethink products (might lead to far better consequences than autopilot product)
Signs that product management is improving organizational practices:
Conflicts discussed without any personal attacks
Everyone feels invested in work that they are doing
People see new info as opportunity rather than threat
Due to connective nature of role, you often feel responsible for organizational upkeep. When things start to fall apart, it can be overwhelming. Some strategies:
Recognize what you can and can’t control
Look for opportunities to delegate
Protect routines & rituals that bring your team together and always attend!
Ch. 12: Conclusion - Whatever It Takes
PM title does not give you authority, control over product or ability to get things done
You must work through influence and trust
You will make lots of mistakes, but product management will teach you how to be wrong, how to back up words with action, teamwork and more
You do whatever it takes to create success for your team