Cracking the PM Career: Chapters 1, 2 and 6

September 16, 2021

57 min read

Share on

Gayle Laakmann McDowell

Gayle is the author and creator the best-selling Cracking the Interview and Career series: Cracking the Coding Interview, Cracking the PM Interview (co-authored with Jackie Bavaro), Cracking the PM Career (co-authored with Jackie Bavaro), and Cracking the Tech Career. Gayle has worked as an engineer for Google, Microsoft, and Apple and is a consultant, and founder focusing on improving tech hiring for both the interviewer and the candidate.

Jackie Bavaro

Jackie is Co-Author of Cracking the PM Interview, Cracking the PM Career, and Head of Product Management at Asana. During her time there, Jackie has grown the team and helped Asana go from $0 to more than $100 million in annual recurring revenue. She also launched Asana's associate product manager program. Prior to working at Asana, Jackie was a Product Manager at Google and a Program Manager at Microsoft.

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	User insights Data insights Analytical problem solving Technical skills Product and design sense
Execution Skills	Project management Minimum viable products (MVPs) Scoping and incremental development Product launches Time management Getting things done
Strategic Skills	Strategy Vision Roadmaps BUsiness models Goal setting Objectives and key results (OKRs)
Leadership Skills	Communication Collaboration Personal mindsets Mentoring
People Management Skills	Do you really want to be a manager? How to become a manager Recruiting Coaching Performance reviews Product process Team organisation

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.²

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:

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:¹

PMs often have two streams of work going at a time: one closer to discovery, and one closer to delivery.² 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 sprints³

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.⁴

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!

Chapter 6

ANALYTICAL PROBLEM SOLVING

THE GOOD THING about the Google APM program was that I got to take on opportunities outside of my comfort zone. The bad thing was that, well, I had to take on opportunities outside of my comfort zone.

And so was the case with my upcoming rotation. The Search team had a reputation for requiring strong analytical skills—skills that I wasn’t so sure I had. I’d struggled with analytical interview questions in the past. In fact, I was still feeling a little burned by a recent consulting interview where I was asked to pull new revenue opportunities out of a stack of spreadsheets. Let’s just say that did not go well.

Still, I proceeded with the rotation. The only failure is the failure to try, right? Let’s hope!

It turns out that my fears were unfounded. Not only did I excel on the Search team, I became known specifically for my analytical skills. It wasn’t that I became a spreadsheets whiz, or that I could immediately extract meaning from numbers.

Rather, it was my tenacity and pursuit of understanding. I followed my curiosity and never rested until I had a firm mental model of a program. I browsed thousands of random search queries to see where we should have been showing images, and then developed a framework for understanding why and how. I worked with diary studies to figure out what people really wanted when they searched for restaurants. I double-checked the accuracy of hundreds of local listings once I realized that, even when the web address was correct, the phone number or physical address could be wrong.

Creating these mental models wasn’t always a quick or solo activity; it was a process, often team-wide. At Asana, I created giant spreadsheets laying out the tradeoffs of each solution, and often they felt like a mess at first. But diligently, and with my teammates’ help, I’d bring order to these spreadsheets, distilling them down to their deciding factors.

Analytical skills aren’t about sudden strokes of genius—bursts of insight—when faced with a problem, they’re not about solving math equations in your head, and they definitely aren’t about PMs blazing into the room to conquer the problem. Rather, they’re about structured problem-solving.

Great PMs have these skills, and know how to use them effectively. They detect when their team is stuck, clear away the noise, ask the right questions, come up with a framework for decision-making, gather the information to apply this structure, and drive good decisions. This is what analytical problem solving is all about.

RESPONSIBILITIES

IDENTIFY AND STRUCTURE AMBIGUOUS PROBLEMS

BRINGING CLARITY TO AMBIGUITY

French or German? Asana was locked in a contentious debate over which language to pick for its first translation. Does it look at the number of speakers worldwide? Or within its user base? Or perhaps where it wants to grow the most?

Lili Rachowin, a PM Lead at Asana, took charge of the decision-making process. She showed up to the hour-long review with a table of possible considerations—all the expected facts and numbers, along with some new items we hadn’t considered. She argued that, with this being the first translation, the most important factor was the willingness among the respective customer base to tolerate translation mistakes. The team hadn’t thought of that, but agreed. Her proposal was approved on the spot.

Rachowin brought clarity to the ambiguous problem.

Product managers continuously face ambiguous problems. They must learn to recognize when they have an ambiguous problem and how to apply structure to it. Without this skill, they might try to solve problems based on their own intuition, or push these problems onto other people because they feel stuck.

Consider these ambiguous problems:

Should we delay the launch to include new features or to polish the product? • Which metrics should we be trying to improve?
Which user problem should we focus on?
How can we increase revenue?
How can we increase the usage of this feature?
Do we build our own solution or should we buy one?
Why did the graphs show a drop on a particular day?

At a high level, these and other ambiguous problem break down into two core types:

Exploratory problems: We have a question or problem, and we don’t have a good idea of the potential answers. “How can we improve revenue?”
Decision-making problems: We have an idea of what the potential solutions could be, but we don’t know which one is the best. “Which of these features should we launch first?”

Let’s consider them both.

Exploratory problems

Although exploratory problems are, by definition, wide open, you can still apply structure. Structured brainstorming can help.

Think of a few ways to slice up the problem space, and then brainstorm solutions inside each slice. As a PM, it’s usually your responsibility to set up the structure. You can then bring more people into the loop and let them share their thoughts on the current slices, add additional slices, or offer any other relevant ideas.

For example, with the, “How can we improve revenue?” problem, here are a few slices:

New versus existing customers: Consider how to increase the number of paying customers versus how to encourage existing customers to pay more.
Size of bet: Consider what small optimizations and big new initiatives you could make.
Revenue stream: Consider how to increase subscription revenue versus how to increase advertising revenue.
Customer type: Consider revenue improvements for each persona or user profile.

For the question, “Why did our metrics drop all of a sudden on this day?” here are a few ways to drill down:

Internal versus external changes: Did we do something such as launching a feature or changing our ad spend? Or did something in the external world happen, such as an international holiday or a competitor announcing a new product?
Geographically: Did we see a change in different countries?
Product line/product area: Did we see a drop across all of our products (or all parts of our product), or was it localized?
Funnel: Was the drop in only one part of the funnel?
Source: Did we see a drop coming from a particular referral source?
Customer type: Was a particular type of customer affected more than others?

Sometimes, simply brainstorming the slices will solve the problem. For example, in the metrics question, you can look at each slice and, eventually, you’ll find the culprit. For the other cases, you’ve just transformed your exploratory problem into a decision-making problem.

Decision-making problems

Once you’ve got some options for solutions, you have a decision-making problem. As with exploratory problems, you want to try a few different ways of structuring the problem, and then evaluate which method seems the most helpful.

The goal with ambiguous decision-making problems is to simplify the problem down to the core, important tradeoffs.

The main issue with an ambiguous problem is usually information overload. There are so many potential facts and tradeoffs that it’s difficult to figure out what really matters.

One approach is to structure the options in a continuum across categories. You can then evaluate the decision at the category level rather than the individual solution level.

Low risk versus high risk
Low investment versus high investment
Short-term benefit versus long-term benefit
Growth focused versus revenue-focused
Build versus buy
… or any problem-specific categorization

If you just have two options, this approach will often illuminate a third, middle option that you might have missed.

For more approaches to structuring problems, see “Concepts and Frameworks” on pg 71.

LOOK INTO THE DATA YOURSELF

Great PMs are willing to get their hands dirty. They want to see the raw data for themselves. And the better their analytical skills are, the more likely they’ll be able to spot something for themselves that other people missed. That’s why great PMs don’t delegate fact gathering to other people; they want to do this themselves.

A year before Lili Rachowin solved the problem of which language to launch first (see “Identify and structure ambiguous problems” on pg 64), she solved another problem by looking at the data herself. She had stepped in as the PM of a product as it was getting ready to launch. Nearly a dozen people were stuck arguing over the launch date for weeks. She opened up a spreadsheet, walked over to the finance department, and calculated how much money was being lost every week the launch was delayed. When people saw the results, the disagreements stopped.

HELP TRIAGE AND REPRODUCE BUGS

Once your product is launched, bug reports will start coming in. Some will indicate severe issues and others will be mild. Some impact many users and others just a few. Some will be easy to fix and others require more work. For some, the problem will be immediately obvious and others will be harder to diagnose.

As a PM, you’ll consider all of these factors and decide what to do with the bug. Some of the bugs wouldn’t be worth the time they would take to fix, and so you close them as “won’t fix.” Many of them will be slotted in to be worked on in the coming weeks or months. For the worst ones, you might ask an engineer to stop what they’re working on and fix it. This process of prioritizing which bugs to fix and how quickly to fix them is called “bug triage.”

To prioritize bugs, consider the following factors:

Damage to users: Can this bug cause any large or lasting damage to users? Does it expose them to a security or privacy issue? Could they lose data?
Damage to company: Can this bug cause any large or lasting damage to the company? Could it damage the company’s reputation severely
Impact on metrics: Does this bug have a large impact on key company metrics? Does it hurt costs or revenue? Does it hurt activation, adoption, revenue, retention, or referrals? Is it causing a large number of support tickets?
Scale of impact: How many users are affected by the bug or exposed to the bug? Does the bug disproportionately affect important customers (e.g., paying customers or large customers)? Will more or fewer users be affected in the future?
Workarounds: Are there workarounds? Would a user discover the workaround on their own? • Ease of fixing: Is the bug easy to fix? How long would it take to fix?
Now vs. later: Is it timely to fix the bug now? Is it cheaper to fix the bug now than it would be later? Is there marketing planned around that part of the product?
Cost/benefit relative to other work: How does the cost and benefit of fixing the bug compare to the cost and benefit of focusing on new feature work?

As part of the triage process, a good PM takes a first pass at the bugs to understand them, clarify them, and resolve them as quickly as possible. This is where analytical problem solving can come into play.

Perhaps you’ve seen a similar bug before and you have a guess about what the problem is and how the user can resolve it (for example, by turning off a particular chrome extension or requesting a new password). Otherwise, you can try to reproduce the bug and narrow down the circumstances in which it occurs (for example, only on one browser, or only when your shopping cart is empty). Depending on your technical skill, you might even look at logs to identify the error or crash.

The more detailed and specific you can get the steps to reproduce the problem, the faster the engineer will be able to fix it.

SYSTEMS THINKING ⚡

Imagine you’re working on a new type of user-generated content, and an engineer asks you if it’s critical for this type of content to show up in search. A few days can be saved if you skip it.

This might sound like a simple prioritization decision, but the implications can be much larger. The engineer didn’t mention this, but if you say no to search, the feature will be built in an entirely different way that makes it much more expensive to add search later on. It also won’t let the content show up in any dashboards or pick up any premium functionality. In an ideal world, the engineer would have explained the repercussions of the decision, but in this case, they wrongly assumed you already knew them.

Systems thinking is the skill needed to see how different parts of a system (like a product or company) connect to each other, to ask the right questions, and to make decisions that account for how those interconnected parts will be affected.

People who are strong at systems thinking will play out scenarios in their minds to see all of the repercussions, and then adjust plans to optimize for overall success.

Some types of interconnectedness to think about can be found below:

Feedback loops: Will the results of this also act as inputs in the next round?
Cannibalization: If one product is successful, will it decrease the usage of another?
Funnel stages: If you widened the top of the funnel to bring in more signups, could those users behave differently later in the funnel?
Product components and functionality: What impact does this new functionality have on other components such as search, notifications, permissions, or onboarding? Are there implementation choices that affect what ‘nice-to-have’ behaviors you’ll get for free?
Incentives: Does success in one part of the product change user behaviors elsewhere? • UI components: Will changes in this one place work everywhere the component is used?
Platforms: Does this new functionality work the same on mobile, on desktop, and via the developer API?
Flexibility: What changes become easier or more challenging in the future? Are you locking yourself into certain decisions?
Resource requirements: Will this cause scalability issues on the backend or for customer support?
User life cycle: If you make a change, such as giving new users unlimited space, what impact will that have in the long run?

If this is an area where you need to improve, the best way is to get as many examples as possible. Ask a mentor or a coach to point out opportunities where you could have used more systems thinking.

Improving your systems-level thinking often means deepening your understanding of the underlying infrastructure—for example, by talking to the engineers on the infrastructure team. Ask questions about the options and their implications. Draw diagrams or create visual models to help you understand how everything connects. That will help you recognize the cases where product decisions seemed straightforward but actually have important side effects. While you’re building up your understanding, you can create a safety net by specifically asking about the repercussions of your choices.

Another approach to systems thinking is to improve your ability to learn from past experiences. Rather than predicting all the things that might possibly happen in an interconnected system, you can keep checklists of the mistakes you and your teammates have made in the past and scan through them when building a new feature. You can sit in on experiment analysis meetings and read blog posts from other PMs to build up your internal library of possibilities to consider.

GROWTH PRACTICES

BE CURIOUS: PREDICT AND EXPLORE

Curiosity is a key element of problem-solving; not only does it help you notice the problems, but also guides you in figuring out the details that will help you solve them.

Start by predicting what you expect:

If you’re about to look at experiment results, make a quick estimation of what you think the numbers might be.
If you’re about to attend a meeting, try to guess what each person will say.
If you’re about to go to a training session, hypothesize what the advice will be. This will help you notice when something is interesting and unexpected.

If you don’t make these predictions in advance, your brain could trick you into thinking that the answer was exactly what you expected. It’s easy for “that makes sense” to feel like “that was expected,” after the fact.

Once you notice something unexpected, take some time to explore it. Draft some questions and seek to answer them. This is where you’ll start to expand your knowledge, which will help with future problem-solving.

DON’T JUST POINT OUT PROBLEMS

Some PMs take “constructive criticism” a little too far. This isn’t necessarily out of cruelty. Sometimes it’s because they take great pride in their ability to identify problems, to the point that they believe they’re being helpful by pointing out everything that could possibly go wrong (particularly with other people’s work). Needless to say, this is the wrong approach.

While it’s important to be aware of problems, PMs need to find solutions to overcome these problems and find a way to keep teams moving forward. Also, remember that you don’t get credit for having the “right” solution if you’re not able to convince people to adopt it. This largely involves a shift in your mindset.

Instead of assigning value to the problems you spotted, assign value to the good outcomes you drove. It’s easy and not especially valuable to say, “Here are all the reasons that won’t work.” It’s harder but much more useful to say, “I can find a way to make that work.”

It’s important to note that once you advance into leadership positions and are responsible for reviewing other people’s work, this advice flips. You might just want to point out problems so that you encourage teams to take ownership over finding their own solutions.

ARTICULATE YOUR FRAMEWORKS ⚡

Frameworks are a product manager’s secret weapon. You’re already creating and using frameworks—they’re just the logic you’re using to make decisions—but you might not be articulating them.

If I were to ask you why you ordered your team’s roadmap in a particular way, or why you made a specific product decision, you could think about it and then give me an answer. Perhaps you only considered one factor, like what the engineers wanted most, or you might be using a different ad-hoc framework for each decision. Nonetheless, as imperfect as they are, you have created frameworks.

Articulating your frameworks is important because it shows people the logic and consistency behind your decisions. Writing them down gives you something concrete to improve upon.

This leads to many benefits, including:

Building credibility: You will build credibility because people will understand the knowledge and critical thinking behind your decisions. They’ll have more trust that you’re making the right calls because they will understand the context behind every decision you make.
Less team frustration: Your teammates are likely to be less frustrated when new information comes in that changes a decision. If they are only aware of the decision change, they might think that you hadn’t thought through your original decision adequately. But when they see that the framework is consistent, they can anticipate the kinds of changes that might come up, and have a better understanding of why the initial decision had to change.
More constructive feedback: You’ll get more constructive feedback from people because they’ll be able to spot missing information or incorrect assumptions within your frameworks.
Greater efficiency: You will save time because your teammates can use your framework and answer some of their own questions rather than always having to come to you for answers. Sometimes, you’ll even save time for yourself because you’ll realize you can reuse a pre-existing framework rather than creating a new one from scratch.
Improved decision-making: Your frameworks will improve as you articulate them. For example, you might be thinking that your new team needs an easy project to get started. You then explain that it’s useful to have a trial run of working together (PMs, engineers, and designers) without needing a lot of executive buy-in, both to get to know each other and to learn the new codebase. All of these extra details help narrow down what kind of “simple” project is best. You might not have thought of them if you didn’t take the time to articulate your framework.

Here’s an easy way to articulate your framework: Whenever someone asks for your opinion or a decision, instead of just sharing it, also include the factors that would lead you to a different decision. For example, if someone asks which privacy setting should be the default, you could say:

We should set the default to share full profile information because this feature is only available in our enterprise tier and profile information is not sensitive within a company.

If you, later on, decide to move the feature to another tier, or you learn that profile information is sensitive within a company, your team will understand why the decision changed.

In addition to communicating your own frameworks, you’ll also want to identify the frameworks others are using. You can try to reverse engineer their frameworks or ask them directly how they’re making decisions. This will sharpen your skill and expand your repertoire of possible problem-solving approaches.

OPTIMIZE ACROSS PRODUCTS AND OVER THE LONG TERM ⚡⚡

Consider this scenario: Your company offers a suite of products, and you are lead PM for one of them. Each product in this suite offers a consistent in-product dashboard, but you have an idea for a special dashboard that would be even better suited for your product. Should you do it?

Sometimes, yes. But proceed with caution. That mindset of “even better for your product” can be problematic. You need to think about what’s best for the company, not just your product. Will people get confused by an inconsistent dashboard? Could it hurt the sales motion to have an outlier?

You also need to think long-term. Who will maintain this “special” dashboard? Will it take longer to ramp up new teammates if your product works differently?

It is certainly normal for a junior PM to optimize around just their product. However, as they get more experience, they need to expand their perspective to optimize across many products—including those that aren’t “under” them. They also need to take into consideration the future. What will be the best for the company, in the short and long term?

VISUALIZE HOW IT’S BUILT ⚡⚡

One day, I saw a surprising bug: a user’s notifications were getting archived as soon as they arrived. The on-call engineer looked into it and was perplexed; the notifications didn’t appear to be marked as archived. I thought back to how the notification system was built and remembered that there were two ways to archive notifications—individually, and by pressing “archive all.” I suspected that the user’s “last archived” date was somehow set to the future in our database. We looked, and that’s exactly what had happened! We fixed the date and the problem was solved.

Problem-solving can often feel like a guessing game. How could you predict what decisions might have surprising side effects? How can you guess what’s causing a bug? The most reliable way is to have a deep understanding of the underlying system and visualize building the solution yourself.

Familiarize yourself with what the records look like for the main objects in the database. What information is directly available on the record, what would need to be looked up separately, and what isn’t there at all? The information that’s directly available will be easy to use, while other information might be harder or slower to use. You might find all kinds of useful details precalculated and ready to use, for example, data on how active the user is or where they’re located.

Learn about the components in the framework. This could involve UI components (such as color selectors or buttons) and infrastructure (such as Amazon’s Elastic Search). Each component will be able to do some things easily, some things with more expensive customization, and some things not at all. If you can visualize which components you’d use to build a feature, you can predict what strengths and limitations come with it.

CONCEPTS AND FRAMEWORKS

THE 2X2 MATRIX

A 2×2 matrix is a very popular framework. It’s incredibly simple, but works really well for evaluating options or organizing information.

A 2×2 is just a square divided into four quadrants, where each axis represents a dimension you care about. Potential solutions are slotted into the appropriate quadrant. The diagram highlights the tradeoffs and helps you uplevel the conversation from specific solutions to higher-level decision criteria. Sometimes a 2×2 even helps you find a “best of both worlds” solution.

Let’s say your product is an online art gallery, and you want to make it easier for people to find art they might like. The designer comes up with a beautiful design with nine preset categories (contemporary, pop-art, impressionism…), each of which leads to a themed category page. The engineer feels that predefined categories are too limiting and wants to implement search across the comments on each piece of work in order to be more flexible and extensible. The designer pushes back, saying more users will benefit from browsing a list of recognizable categories than if they needed to think of their own search terms.

If you pull away from the specific solutions, then fundamentally, your decision criteria is around this: Do you want browsable or searchable? Do you want something more limited or something extensible?

You can lay these criteria and options out in a 2×2 to make the problem easier to reason about.

This diagram highlights the conflict and you could lead a discussion about whether it’s more important to have a browsable or extensible solution. But, the diagram also prompts you to consider solutions that get the best of both worlds. User-generated tags would be both browsable and extensible!

RED/YELLOW/GREEN TABLES

If you have three or more decision-making criteria, you can create a table where the columns are the criteria and the rows are the options. The squares are filled in red, yellow, or green (or checks and x’s, if you don’t have colors), depending how well each option does on the category. You might be able to see that only one option has no red squares, or that every option that’s good on cost is bad on long-term benefit.

IF WE’RE OPTIMIZING FOR…

Another way to structure a problem is to identify which choice is the best for each potential optimization. This helps people to make decisions based on their values and goals rather than needing to understand each option.

If we’re optimizing for…	The best choice is…
Launching as quickly as possible	Preset categories
Scalable discoverability	Tags
Incremental learning	Preset categories, then tags
Finding individual pieces	Search

DECISION TREE

When you have a complex problem, diagramming the problem via a decision tree can be useful. Each node in the tree represents a question, and the branches represent possible answers. This helps people understand your thought process and ensures that you’ve planned ahead for different possibilities.

In text, you can use a bulleted list with indentation to represent the tree:

If the A/B test result is…

Positive

» If there are customer complaints…

+ Interview customers and iterate

» If there are no customer complaints…

+ Launch it

Negative

» Do not launch it

Neutral

» If there are customers who love it…

+ If there are no complaints…

♢ Launch it

» Otherwise…

+ Do not launch it

EIGENQUESTIONS

When Shishir Mehrotra, now co-founder and CEO of Coda, was a PM at YouTube, there was intense debate that wasn’t getting anywhere. The engineers wanted to link out to other websites when the user searched for TV shows that weren’t available on YouTube. The business people disagreed. Should they link out or not?

As he searched for ways to solve the problem, Mehrotra realized that framing the debate around a different question could help. A few weeks earlier, he’d sat in as an observer on a product review of Google Product

Search, and heard the executives discussing product choices in terms of consistency vs. comprehensiveness. He realized that framing might cross-apply to his product as well.

At the next leadership team off-site, he kicked off a discussion with a new question: would the online video market be one that rewarded consistency or comprehensiveness? Unlike the earlier question, this new question could be resolved. After much discussion, they settled it; consistency was more important than comprehensiveness.

Surprisingly, not only did this decision answer the original question, it also resolved several other issues that hadn’t seemed related previously. They ultimately decided that they would not link outside of YouTube for search results. They also removed the ability for creators to opt content out of different devices and removed all third-party embed players. They even decided to take back control of the YouTube iOS app from Apple.

Mehrotra named this kind of root question an “eigenquestion,” a question whose answer likely answers subsequent questions as well.1

To use the eigenquestion methodology, follow these steps:

Diagram your questions and options with your team. Spend extra time making sure you’ve gotten all of the important questions out. Look outside to other teams or industries for alternate framings.
Walkthrough each question and ask, “If we decided this, which other questions would be answered?” Find the question that answers the most other questions. This is your eigenquestion.
With your team, list the range of options that could answer the eigenquestion, and identify the pros and cons of each one.
Align on a decision. Check in with your teammates on how they feel about the options. If people are uncomfortable with your proposed option, take the time to fully understand why.
Commit and determine accountability. Make sure you know who is responsible for communicating the decision and making it happen.

It may feel like this methodology is a long, even burdensome, process, but it can help you make more robust decisions that save time in the long term. If you start with the eigenquestion, you will not only answer that question, you’ll answer a dozen subsequent questions as well.

FIVE WHYS

“Five Whys” is a useful framework to conduct a retrospective analysis of a problem. If you practice Five Whys across a range of problems, you’ll hone your problem-solving skills, and learn to go beneath surface factors to identify the root cause.2

You can run a Five Whys for many different problems. For example, site downtime, missed OKRs, failed launches, cross-functional collaboration issues, or any other issue that’s causing problems or frustration. The problem is usually a brief statement like, “The site was down for three hours,” “the sales team wasn’t told that the launch was happening this week,” or “we missed the OKR to raise adoption by 30%.”

To run a Five Whys:

Schedule time with the people involved in the problem.
Explain that the goal is to learn about deeper systemic issues, and not to assign blame.
Create a detailed timeline of what happened. Timelines can be very illuminating as it gives people the full picture of what happened.
State the problem and ask, “Why did this problem happen?” Write down all the first-level answers.
Go back to each first-level answer, and ask why it happened or any related questions around why the problem wasn’t caught or fixed sooner. For example, if a developer submitted code that crashed, why wasn’t it caught by test cases.
Keep going deeper until you feel like you’ve uncovered the root cause. Often, a process failure is identified as the underlying issue.
Record the lessons learned and decide on appropriate action items to prevent similar problems in the future.

Be careful not to overreact with your solutions. If a problem has only happened once, adding a heavy process to prevent it might be worse for your team than doing nothing.

KEY TAKEAWAYS

Lead your team through effective decision-making: As a PM, you don’t need to solve every problem yourself, but you do play a key role in structuring the problem. When you frame a problem in a way that surfaces the underlying issues, your team will come up with better and more robust solutions.
Draw it out: Tables and diagrams are surprisingly helpful for analyzing problems. If you’re stuck, try organizing the pros and cons in a few different formats until you find one that resonates.
Pay attention to the whole system: Most interesting problems have interconnected impact and require systems thinking. Make sure you understand the broader context. Don’t oversimplify the problem into an isolated decision. Instead, make a list of possible repercussions and check your solutions against them.
Articulate your frameworks: Share the thought process and structure behind your problem solving instead of just the solution. This helps people trust the solution you came to and enables them to make aligned decisions in the future.

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.

Chapter 6

1 Read more about eigenquestions at https://coda.io/d/Eigenquestions-The-Art-of-Framing-Problems_dQnxKKTYZ4r.
2 Read more about Five Whys at https://wavelength.asana.com/workstyle-ask-5-whys-to-get-to-the-root-of-any-problem/.

Explore all topic content