What does it take to become a great product manager, or to lead and inspire product teams? When do you know that people management the right career move for you? How do you build your product intuition, hone your execution, strengthen your leadership, and develop your strategic skills?
In our book Cracking the PM career we try to answer these questions and more and here we're giving you an exclusive look inside the cover.
Below, read chapter 1, Getting Started, and Chapter 2, The Product Manager Role, and, if you're a Mind the Product member, you can also read Chapter 6, Analytical Problem Solving.
Chapter 1
GETTING STARTED
UNICORNS. I NEVER thought that I'd be at this point in my career and trying to justify their existence, but PMing is funny that way. Sometimes your product needs a mythical beast. Or, at least I thought so.
Let me explain.
At Asana, we had a secret feature where users could turn on unicorn celebrations when they completed a task. Customers were delighted. Who wouldn't love a literal unicorn flying across their screen?
It turns out that the people who thought it was a virus weren't so crazy about the introduction of this possibly diseased beast. Also, it did seem a bit goofy for our business customers.
I was stuck. Logically, their points made sense. It could be jarring for our more serious users, and I could see where a less tech-savvy person might reasonably mistake our clip-art unicorn for a symptom of a computer issue.
At the same time, I believed in this feature. It offered a little treat for a "job well done." The reception was fairly positive, and I thought this feature would boost word of mouth.
My believing in it wasn't enough though; it's not like I could demand that everyone do what I wanted.
As I had instructed my mentees so many times, a PM can't just issue orders. They have to develop the frameworks, gather the data, consider the risks, and motivate people to align along some vision, goal or task.
This is the essence of what makes PMing so thorny. There are such a variety of multifaceted problems with so many stakeholders. Sure, we get more skilled as our career progresses—but then we face more complex problems and bigger goals. It's like we're perpetually fumbling in the dark for the light switch, but only finding a little flashlight.
A HOPE THAT THIS BOOK ILLUMINATES.
A good PM has goals, and this book—being a product itself—is no exception. These are our goals.
Our goal is for this book to be the guide we never had.
As a fresh PM, starting out at Microsoft, I had mentors and advice—but it wasn't comprehensive. No one could sit me down and teach me all of what it means to be a PM, and what it takes to become a fantastic one. It's not that they didn't try; there's just too much to say. I couldn't envision how the complexity of my problems would evolve with my career path.
While I was at Google—starting in the APM program—I continued to learn a great deal about building awesome products. But the complexity of the decisions grew. No longer did my work fit into a clear structure with defined projects and preset deadlines. I now needed to work with my team to decide what projects to tackle and when they should ship. I was expected to manage stakeholders and strategy—as well as my own career. I gobbled up all the information my mentors fed me, but I still felt like I was messing it up as often as I got it right.
Our goal is for this book to be the guide our mentees never had.
I joined Asana as their 13th employee and first PM. Now, it truly felt like it was all on me. No longer did I have premade launch checklists and spec templates. There was no super senior PM I could look to to see if I was on the right track. I was wearing those shoes now.
Over eight years, as Asana grew to more than 500 employees, I rose into the head of product management role, overseeing the product roadmap and a team of 20 PMs. I launched Asana's APM program and aspired to do everything right that my mentors had, nothing they did wrong, and then add on a few bits of awesomeness too.
That's a ridiculous, lofty goal—impossible to achieve—but that's okay. I'd like to think that I came pretty close.
Over the years, I've learned and grown so much. I've been mentored and supported by amazing people. I've made mistakes and learned from them. I've had major successes and learned from them. I've written job ladders and hired PMs. And I turned all of this into mentoring and supporting PMs—as APMs freshly out of college, as PMs growing into more senior roles, and now in the form of this book.
Our goal is for this book to help more people become great product managers.
This book shares the skills, frameworks, and practices that my peers and I have painstakingly learned and honed over the years, so that PMs can spend less time reinventing the wheel. It delves into the mystery and ambiguity surrounding career progression so that PMs can focus on the right areas and reach their potential. It connects the dots on how to develop each important PM skill so that mentors can point their mentees towards actionable feedback.
Of course, there is no such thing as a perfect PM, and there's no such thing as a perfect mentor. But we hope that this book will make things a little bit easier. Read it cover-to-cover, or sample the sections you like, or let it sit on your desk as a reference to flip to—or have your mentees flip to—as needed. The choice is yours.
ON MYTHICAL BEASTS
As for the unicorn celebrations, it launched in the end. We aligned the team together under a broad agreement about testing and measuring customer reactions. A designer worked to make the design match our brand and added an explanation on the first unicorn, so it didn't get mistaken for a virus. And we launched initially just for personal use cases, though we promoted it to organizations later. Internal stakeholders were happy and customers were delighted.
Now, years later, as I write this book, I'm on the other side—checking tasks off on Asana, and watching unicorns shoot across the screen. Perhaps I'm biased, but it does give me a little smile every time.
HOW TO USE THIS BOOK
This book is for anyone who wants to become a great product leader. You might choose to read it straight through, but you can also skip around—we give you some pointers on doing that (pg 11).
In the book Peak: Secrets from the New Science of Expertise, Anders Ericsson and Robert Pool study the question of how people develop their potential and achieve greatness. The key takeaway is that your expertise is driven by the quality of your mental representations. For example, when chess grandmasters look at a chessboard, they don't see a scattering of pieces; they see an in-progress game where white played the queen's gambit and black declined.
To get the most out of this book, focus on developing your mental representations around products, businesses, and people. Create and refine your own frameworks. Apply deliberate practice by comparing your intuitive behaviors to those of the best PMs. When you do this well, new situations you're faced with won't feel like total unknowns. Instead, they'll each feel like a variation of a pattern you recognize.
With practice, you too will hear an engineer complain about technical debt and say, "Ah, this is the classic roadmap conflict caused by prioritizing disparate goals in a single ranked list, and easily solved with a balanced portfolio roadmap."1 It doesn't quite have the ring of "the queen's gambit declined," but it will do.
PM SKILLS
Every company uses different top-level categories to describe the skills and attributes of great PMs. Fortunately, the underlying elements are remarkably consistent. All companies want you to efficiently deliver high-quality products that create customer and business impact without causing problems.
In this book, we've grouped the skills it takes to be a great product leader into five categories:
- Product skills help you design a high-quality product that delights customers and solves their needs.
- Execution skills enable you to run and deliver your projects quickly, smoothly, and effectively.
- Strategic skills improve your ability to set direction and optimize for long-term impact.
- Leadership skills allow you to work well with others and improve your team.
- People management skills come into play when you have an official responsibility to hire and develop people.
If your company organizes the skills differently, this chart will help you find the relevant section.
| Skill Area | Includes |
| Product Skills |
|
| Execution Skills |
|
| Strategic Skills |
|
| Leadership Skills |
|
| People Management Skills |
|
For each skill we've highlighted:
- Responsibilities: things you're expected to do.
- Growth Practices: mindsets and exercises you'll work on over time to improve the skill.
- Frameworks: mental models, tools, and reference material. This section comes first when the frameworks are a prerequisite to understanding the responsibilities.
Responsibilities and growth practices that only come into play at more senior levels are marked with ⚡
You can read through the PM skills in order, or jump to the area that you want to focus on. They can also serve as a starting point for conversations with your manager such as, "When you said I needed to be more user-focused, did you have one of these in mind?"
CAREER SKILLS
Being an excellent PM and launching great products isn't always enough to have a successful career.
In Part H: Careers, we'll cover everything you need to know about managing your career so you can translate your efforts into the recognition you deserve.
Topics include:
- PM career ladder
- How promotions work
- Setting career goals
- Working with your manager
- Optimizing review cycles
- Networking
- Career options beyond PMing
- Q&A with successful product leaders
PM Career Ladder
Unlike most leveling frameworks and PM career ladders, this book does not create a rubric that describes what each skill looks like at every job level.
Why?
Those types of rubrics are either unhelpfully vague or misleadingly specific. They either use subjective qualifiers or list bullet points that aren't applied consistently. Often, they just self-referentially describe the scope you've been assigned.
The underlying truth is that PM skills don't translate directly into levels. Instead, your level is determined by your scope, autonomy, and impact. The way you earn a promotion to the next level is by demonstrating autonomy and impact at your current scope and building trust that you can perform at a larger scope.2
The PM skills are incredibly important for becoming a better PM and launching great products, but they don't create a guide for how to advance.
In Chapter 32: The Career Ladders (pg 343), we paint a picture of what each level looks like, and how to advance to each one. We cover levels from associate product manager (APM) to head of product and describe the typical scope, autonomy, and impact expected at each level.
IF YOU'RE SHORT ON TIME…
If you don't have time to read this book cover-to-cover, here's where to start:
I'M NEW TO PRODUCT MANAGEMENT
If you're new to product management, congratulations, and welcome!
- Start with Chapter 2: The Product Manager Role (pg 13) to learn the basics about the product life cycle and what a PM does during each phase.
- Read Chapter 3: The First 90 Days (pg 21), focusing on the introductory meetings. The PM role is slightly different on each team, so these conversations are critical for learning what your teammates expect of you.
- Scan the "Responsibilities" for each PM skill to get a deeper understanding of the role.
I'M HAVING TROUBLE GETTING PROMOTED
Don't worry, this happens to many PMs who go on to have highly successful careers.
- Start with Chapter 32: The Career Ladders (pg 343) to learn the differences between each level, and concrete tips on how to get promoted.
- Read Chapter 34: Working with your manager (pg 378) (and other parts of the same chapter).
- Ask your manager or a trusted mentor to direct you to the PM skills you should focus on.
I'M A SENIOR PRODUCT LEADER
You can skip the basics, we've still got plenty of information for you.
- Take a look at Chapter 32: The Career Ladders (pg 343) to get a sense of how the roles change in the upper levels of product leadership.
- Scan each PM Skill for the responsibilities and growth practices marked with !. Strategic Skills (pg 166) are especially important as you advance.
- Read Part G: "People Management Skills" (pg 282) for help with the operational excellence side of product leadership.
I WANT TO DEVELOP MY SKILLS AS A PM
You can focus on the areas you want to develop.
- Read the "Growth Practices" for each PM skill.
- Scan the "Responsibilities" and "Frameworks" for anything unfamiliar.
- Take a look at "Learning from feedback" (pg 385) to make the most of personalized feedback.
I WANT TO LAND A PRODUCT MANAGER JOB
This wasn't our core use case, but that doesn't mean you're in the wrong place.
- Read the core skills in Product Skills (pg 32), Execution Skills (pg 110), Strategic Skills (pg 166), and Leadership Skills (pg 214)
- Check out Chapter 49: Landing a Product Manager Job (pg 481) to learn a bit about interview questions
- Check out our first book, Cracking the PM Interview, which focuses on interview prep
ENJOY!
We hope you enjoy this book. We know it's a big one, so skip the sections that aren't as relevant. You can always come back to them later.
Feel free to drop us a line at gayleandjackie@careercup.com or find us online:
- twitter.com/jackiebo
- facebook.com/jackie.bavaro
- https://medium.com/@jackiebo
- twitter.com/gayle
- facebook.com/gayle
- https://medium.com/@gayle
Chapter 2
THE PRODUCT MANAGER ROLE
IF YOU ASK five people what a product manager is, you might get six different answers.
Some people say a product manager is a mini-CEO. Others say they're the advocate for the customer. Some say they're the glue that holds the team together. Others say they're the conductor of an orchestra. Some people say they're responsible for strategy, while others focus on user research and execution.
Why so many answers? For one thing, the role is complex and multi-faceted. For another, the role really is different at different companies. Product management is a "whitespace" role—the PM is responsible for anything that isn't covered by other people. Some PMs work with dedicated researchers, data scientists, product marketers, and copywriters, while others have none of those, or limited access to one.
Here's our answer to what a product manager is:
A PM is the person on a product team who is responsible for choosing the right problems to go after, defining what success looks like, and guiding their team to achieve successful outcomes.
They are responsible for the overall success of their product. It's a hugely influential role because the PM is the main person who decides what the product teams actually work on.
This role is all about outcomes, not output. To be a great PM, you can't just follow the steps; you need to reliably build and ship successful products.
THE PRODUCT TRIAD
One of the best ways to understand the PM role is in relation to the other roles at a company. As a PM, you work with many teammates who each have parts they're responsible for. You are responsible for making sure everyone's vision is aligned, all the parts fit together, and that nothing slips through the cracks. If there is a problem, it's your responsibility to—diplomatically—ensure it gets fixed. You must lead without authority, influencing people by using your vision, research, and analysis.
The core product team at most modern tech companies is called the triad: Engineer (or Tech Lead), Designer, and Product Manager.
- Engineers are responsible for the technical solution. They'll plan the data structures and algorithms that will make things fast, scalable, and maintainable. They'll write the code and tests.
- Designers are responsible for the solution from the user experience perspective. What will it look like? What are the flows, screens, and buttons? They'll make mockups or prototypes of how the feature should work.
- Product managers are responsible for selecting and defining which problems the team is going to solve, then ensuring the team solves them. They'll define what success looks like, and plan how to get there.
There are many ways to divide work within the triad. The split can vary depending on each person's level of experience, time at the company, skills, interests, and how heavy their workload is. For example, a junior designer might expect the PM to entirely define the problem and constrain parts of the solution, while a senior designer might be very involved in shaping the problem. It's helpful to have a detailed discussion about this when you start working with new people to ensure there aren't any mismatched expectations.
On the best teams, the triad works together in a close partnership. All three are involved from the very beginning. They share context, give each other feedback, and problem-solve together. Many times, they all agree on a decision, but if not, they should trust each other enough to defer to the person who is most responsible for that problem. They help each other out.
THE PRODUCT LIFE CYCLE
The day-to-day work of a product manager varies over the course of the product life cycle. Modern product development doesn't follow a strict linear structure, but in order to understand the PM role, it's helpful to group activities by phase.
In reality, these phases will overlap, occur out of order, and happen in iterative cycles. Every company has its own version, but this is the general pattern:1
PMs often have two streams of work going at a time: one closer to discovery, and one closer to delivery.2 This helps ensure that when the engineers finish their current work, there's no gap while the PM figures out the next thing to work on.
Please note: determining key assumptions, creating hypotheses, and validating hypotheses occur during all stages.
Early on, the key hypotheses focus on the problem, customer needs, business needs, and market sizing. Later, the hypotheses center on the solution, usability, feasibility, and launch plans.
DISCOVER
Imagine your VP stops you in the hall one day and tells you that you need to add "export to PDF" functionality to your product this quarter. It's a straightforward idea, but it will take a few weeks to build in the existing codebase. You put your team on it and launch it without bugs, but no one uses it. Your annual review comes around, and you're blamed for the flop—not the VP who actually gave the order.
What went wrong?
You skipped product discovery and took your VP's solution too literally. The better path would have been to dig deeper and understand the underlying problem that they were trying to solve.
This is a process called product discovery—when you figure out what problem you should go after.
All products start with an initial idea. It might be a problem you notice, a feature request, an underperforming metric, a new market to go after, or any number of other sources of inspiration. During discovery, you take that initial idea and expand your understanding of the customer's needs, problems, and goals.
You're looking for a problem that's large enough to be worth solving, while feasible enough for your team to be successful.
Many launches fail because the team focused on the wrong problems. They misunderstood critical details of what the customer had told them, the pain of the problem wasn't big enough to overcome inertia, or they missed the bigger picture and only solved part of the problem.
A great example of this was the VHS versus Betamax video recording format war during the 1970s. Betamax clearly had better picture quality, but it turned out customers cared more about affordability and being able to record a full 2-hour movie. Betamax only had 1 hour of recording time. Better product discovery could have steered Betamax in the right direction.
Common tasks during the product discovery phase include:
• Reading through feature requests
• Analyzing funnel metrics
• Interviewing customers
• Testing concept mocks
• Discussing long-term strategy
• Researching competitors
• Doing market analysis
• Holding brainstorming sessions
• Running design sprints3
Discovery is the magic tool for reliably creating successful products. Without product discovery, you're just hoping that the first idea you came up with, or that your executive told you to build, is a good solution for an important customer problem.
DEFINE
Imagine that you've invested a lot of time in product discovery, and brought your whole team along to many customer visits. Everyone is feeling great about the customer problems. When you start working with the designer on the solution, however, there are disagreements. Your designer came up with a beautiful solution that would take six months to build and is insisting that cutting anything means you don't care about customers.
What went wrong?
What went wrong here is that you weren't clear enough during the define phase. You didn't get alignment on the scope of the problem and what success actually looks like. You might have assumed that you'd start by tackling a small part of the problem in the first release, but your designer didn't know that.
The define phase is when you narrow down the problem space to a specific, feasible slice, and frame it so it's ready for the team. You might have a hypothesis for a solution at this point, but it's just an illustration, not something you're committed to. During this phase, you'll be shaping the outcomes you're going after, and outlining the big picture so your team understands where this project fits in.
Common tasks during the define phase include:
- Prioritizing the problems identified in discovery
Add Betamax vs. VHS - Picking a target customer
- Mapping the customer journey
- Defining success metrics
- Creating a product vision
- Proposing a high-level roadmap
- Drafting an initial timeline
The culmination of the define phase is often some kind of review where the team gets the go-ahead for the work and people are assigned to the team.
DESIGN
Imagine your team is ready to start working on a well-defined problem of getting user photos during the sign-up flow, and your designer quickly sketches up a solution. It looks good, so, you give the go-ahead and the team builds it. Unfortunately, customers are confused by the flow and keep writing into customer support. You realize a different approach is needed, and you rewrite the whole thing. What went wrong?
What went wrong in this scenario is that you didn't consider multiple solutions and test paper prototypes during the design phase.
The design phase is not just about putting your ideas into pictures; it also includes expansive thinking and validating your ideas with real people. This includes both the user experience (e.g., mock-ups and visual prototypes) and the technical solution (design docs and technical prototypes).
Common tasks during the design phase include:
- Writing a spec
- Deciding what functionality is in or out
- Negotiating dependencies with other teams
- Whiteboarding with designers and engineers
- Giving feedback on design
- Running usability studies
Design activities usually start a bit before the develop stage, but for larger projects, they tend to overlap. For example, engineers might be implementing one part of the solution while the designer continues to work on another part. Or, the engineers will prototype a basic design and then work hand-in-hand with the designer to figure out how it should look and behave.
DEVELOP
Development is where you turn the ideas into working code. Depending on the team, the PM may have a lot of project management responsibilities during this phase, or the tech lead might take that on. In either case, surprises will inevitably come up and the PM will need to handle them to keep the team on track.
Common tasks during the develop phase include:
- Writing stories or tickets for engineering
- Determining which metrics to instrument and track
- Triaging bugs
- Checking in with teammates regularly to unblock them
- Trying out each feature as it's being built and giving feedback
- Keeping stakeholders and approvers up-to-date
The more responsive you can be to your team, the faster they'll be able to build the product.
DELIVERY
Delivery is where you roll out the solution to users. Some changes are quietly shipped without any fanfare, while others have a full go-to-market campaign.
A lot can go wrong during delivery, and it's up to the PM to make sure it doesn't. You don't want to find out that your product is buggy and takes down the servers on launch day. You don't want to surprise the sales and support teams with changes that they can't explain to customers. And you don't want to send out an email to thousands of people telling them to download an app that's not available in the app store yet (been there!).
Common tasks during the deliver phase include:
- Setting up validation phases such as internal dogfooding, beta testing, A/B tests, and stability tests • Organizing the quality assurance (QA) process
- Working with launch partners to ensure everything is ready for launch (including gathering approvals) • Partnering with marketing on the go-to-market plan
- Training salespeople and customer support
- Celebrating with the team.
Product delivery requires a lot of coordination and risk mitigation. Successful launches are a collaboration between product, infrastructure, marketing, operations, and many more departments.
DEBRIEF
While many people are eager to move on to the next new thing as soon as the product launches, it's not over yet. After the launch, it's important to measure how it went and learn from the project. Often, insights from the launch will drive the next round of product innovation.
Common tasks during the debrief phase include:
- Running a retrospective on what went well and what didn't
- Analyzing launch metrics
- Reading customer feedback on the launch
- Prioritizing "fast follow" work based on customer feedback
- Evaluating the launch success
- Sharing launch results with the company
- Planning for the next iteration
The time and energy you put into debriefing will help you grow as a PM and build your credibility.
OTHER ACTIVITIES
Beyond developing products, PMs are also expected to invest in their own personal growth and contribute to the rest of the PM team and company.
These tasks might include:
- Pitching and interviewing candidates
- Mentoring other PMs
- Writing high-quality peer feedback
- Participating in company processes like goal setting and status reports
- Reviewing specs from other PMs
- Answering incoming questions from other teams
- Presenting to important customers
- Meeting with customers regularly
- Sharing best practices and lessons learned
- Running company-wide processes
- Presenting at all-hands
- Participating in strategy discussions
- Attending industry conferences
- Staying up-to-date with PM best practices
HOW DO I BECOME A GREAT PRODUCT MANAGER?
Great product managers are those who reliably ship great products. Early in your career, you can get credit for developing your skills and showing potential, but eventually, your greatness will be measured by the impact of the products you ship.4
Luckily, to ship great products, you don't need to be a creative genius who's struck by inspiration in the shower.
There are a lot of reliable frameworks and best practices that will improve your chances of shipping a successful product. The frameworks won't transform you into a great product manager overnight or guarantee that your products never fail, but they'll help you avoid the most common problems and give you some structure to start experimenting, reflecting, and improving. They are not a replacement for good judgment.
Becoming a great product manager can take years of practice and experience.
At first, you might feel like there are so many frameworks and best practices that it's impossible to know which one would be helpful at any given time. You might get caught up in the surface-level trappings of finding the right template or using the best agile methodology. It will take a lot of time to run your team because you won't have the intuition on what steps can be skipped, or how to quickly get people on board with a plan. You'll catch some problems in later parts of development when they're more expensive to fix. Sometimes, product leadership will throw a wrench in things and require massive changes.
You might misunderstand part of the customer problem, or mess up part of the execution, causing the launch to miss its goals.
Over time, you'll build up strong mental representations that help you quickly identify the right approach to any given problem.
You'll find that the PM work for each feature takes a lot less time as you hone in on the key pieces of work and need fewer iterations. You'll notice problems earlier, and learn to validate ideas to improve the quality and speed of your launches. You'll start to accurately predict what product leadership cares about, and learn to show your work early to avoid wasted work. You'll get better at digging deep into customer problems and executing smoothly, and you will hit your launch goals.
Then, when you feel like you can launch features with your eyes closed, your role will change and you'll be a beginner again.
You'll be expected to take on more strategic responsibilities. It will feel like you need to prioritize apples against oranges while predicting the future of the fruit market. You'll be taking on multiple projects at once, many of which will require significant tradeoffs. There will be no way of pleasing all the stakeholders. People will ask for roadmaps and visions. With your team being asked to sign-up for absurdly ambitious goals, you'll wonder how you'll possibly find the time for everything.
You can make it through that adjustment period by getting comfortable with ambiguity, tough problems, and tradeoffs. You'll come to understand the company's business strategy and drive product strategy from it. Projects will take less of your time as you learn to empower the members of your team and earn the trust to take shortcuts. Stakeholders will feel like you understand them, so they'll be okay with the tradeoffs you have to make. You'll remove ego from the equation, and become okay with submitting work that's below your regular quality standards in order to make more time for strategy and vision. You'll figure out what it would take to make a significant impact, and drive conversations on the best path to follow.
Around this time, you'll start to feel like a great product manager.
You can relax and enjoy your success, or take another leap into leadership roles. Good Luck!
Buy Cracking the PM Career
Cracking the PM Career will teach you the reliable frameworks and best practices that improve your chances of shipping a successful product. Buy your copy today.
References
Chapter 1
- 2 For higher-level promotions (such as to VP), there also needs to be a business need for a person of that level.
- 1 See "Prioritize competing goals with a balanced portfolio" on pg 200 if you're eager to jump ahead to this solution.
Chapter 2
- 1 These phases expand upon the UK Design Council's "Double Diamond" model: https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond
- 2 Marty Cagan calls this "Continuous Discovery and Delivery" or "Dual Track Agile": https://svpg.com/continuous discovery/
- 3 A design sprint is a great step-by-step process for pulling together all of the pieces of discovery: https://www.gv.com/sprint/
- 4 There's no scientific way to separate the impact of a PM from the strength of the rest of the team. In practice, managers give a lot of weight to peer reviews to understand how much the PM contributed to the results.
Source: https://www.mindtheproduct.com/cracking-the-pm-career-chapters-1-and-2/
Posted by: kendallkendalldekaye0269001.blogspot.com
0 Comments