Cracking the PM Career

The problem it solves

Ask five people what a product manager does and you get different answers. As the authors put it, "If you ask five people what a product manager is, you might get six different answers." That is a real problem if you are the PM. Nobody hands you a list of what to learn, and the feedback you get is often vague, such as being told to be more strategic.

The book gives that vague feedback a shape. It splits the role into skill areas, and for each skill it lists responsibilities, frameworks and ways to practise. You can find the gap, then work on it.

What changes after you read it

You stop treating the job as a pile of tasks and start recognising situations. The authors suggest you compare what you do by instinct with how strong PMs act, and refine your own frameworks as you go. Their chess comparison is that, with practice, a new situation looks like a variation of one you have already seen.

That is slow work, but it is a method you can repeat.

How it connects to running a business

You do not need a product manager title to need this book. Anyone who decides what gets built, what gets cut and what gets launched is doing the job. The chapters on user insight, data insight and scoping apply to a five-person company as much as to a big one.

The strategy chapters are the ones I would read first in a small company. They show why a team that works hard in the wrong direction gets nowhere, and how a vision, a framework and a roadmap fit together.

Decisions you can log and work you can repeat

Many chapters turn on explicit choices. Which problem comes first, what success looks like, which goal wins when two goals clash, what you decided not to build. Those are decisions, and they are much more useful when you write them down with the reason.

Several chapters also work as playbooks, such as the launch checklist and the plan for your first 90 days. Once you have written a playbook like that, a junior colleague or an agent can follow it, and you check the result instead of doing the work again.

When to read it, and when not to

Read it when you start a product role, when you are about to ask for a promotion, or when you are stuck at a level. Start with the chapters on the first 90 days and on the career ladders.

It is a big book, and the authors tell you to skip the sections that do not fit. If you need to prepare for interviews, use their earlier book, Cracking the PM Interview, because this one only has a chapter on landing a role. The stories come from tech companies such as Asana and Airbnb, so a reader outside software will have to translate some of them.

The book argues that product management can be learned. The authors say you do not need a flash of inspiration to ship products that matter, because frameworks and deliberate practice get you there. They group the skills into five areas: product, execution, strategic, leadership and people management. A final part covers careers, with Q&A interviews with product leaders and a few extra essays.

The Product Manager Role

In the authors' definition, the PM picks which problems the team tackles, sets the measure of success and leads the team to it. They call it a whitespace role, because the PM covers whatever nobody else covers. The PM sits in a triad with an engineer and a designer, and the chapter walks through the phases of a product: discovery, define, delivery and debrief. Their warning about skipping discovery is that you end up relying on the first idea you or an executive had.

The First 90 Days

The chapter opens with Claire, a new PM who rushed in with new processes and a spec, upset her team and her manager, and then apologised and started over. The advice that follows is to spend the first three months learning the team, the product and the customers rather than finishing your first project fast. Meet people one to one, ask what each of them expects from you, get expectations and deadlines from your manager in writing, and pick up one small, uncontroversial quick win.

User Insight

The author's early habit was to study personas instead of talking to customers. She later saw small wrong assumptions turn into big problems for real customers. The chapter says to speak with users on a regular basis, and to treat what they say as raw material, because people ask for features that solve only part of their problem. Research is cheap next to months of engineering time.

Data Insight

Interviews cover a few people, and what people say they do often differs from what they do. Numbers fill that gap. The chapter tells you to learn which success metrics your company uses and to check that they match its strategy. It also says to make sure the product logs usage, look at the data often and follow your curiosity. Experiments help, but running too many random ones raises the chance of false wins.

Analytical Problem Solving

You need not solve every problem yourself. Your job is to give it structure. Frame the problem so the underlying issues show, and draw it as a table or diagram when you are stuck. Look at the whole system and list the likely repercussions before you settle. Then share the framework behind your answer, so the team can check it and reuse it.

Product and Design Skills

Product sense covers far more than looks. Start each piece of work by agreeing the goals with everyone, and revisit them. Run at least some cheap validation even when an executive tells you what to build, because many disappointing launches trace back to an untested assumption about users. Then prioritise using what you learned from users and data.

Scoping and Incremental Development

Scoping means deciding what goes in and what stays out. Release a small first version that still has value to real people, because you are probably wrong about some assumptions. There is a limit. As the book says, "Don't ship a burnt pizza and declare no one likes pizza." Cut functionality before you cut polish.

Product Launches

A launch involves many teams, and the PM keeps them in step. Templates stop you forgetting a step. Share the launch date as a window between the best and worst case, since some teams need the earliest date and others the latest. Take direct responsibility for quality as well, even when a QA team exists: try the product yourself and check it works from end to end.

Product Strategy Overview

The authors put strategy ahead of feature work, because a good feature in a product heading the wrong way still fails. They say strategic skill is learned and split a strategy into three pieces. The vision gets people excited, the framework gives the reasoning behind it and the roadmap lays out the work needed to deliver it. Then you keep repeating the strategy until it sticks.

Vision

The vision is the place to be ambitious. Start from the ideal experience and work back, ignoring the constraints for now and build a practical plan afterwards. The chapter opens with Airbnb, where nearly half of booking attempts ended in a rejection or no reply from the host. After a year of small fixes, the team asked what the ideal product would be and bet on Instant Book. The authors compare a good vision to an infomercial: it sells the pain first and the solution second.

Strategic Framework

The best product does not always win, so the framework adds market, pricing, competition and company goals. Its most useful part is where it takes a stance on trade-offs. With a clear strategy, most hard product choices can be settled by looking back at it. It also tells each person where their own work fits.

Roadmapping and Prioritization

Plan a roadmap for the long term, knowing it will shift. It shows whether your plans reach your goal fast enough, and it feeds into hiring and budgets. There is no magic formula for ordering work, so you use judgement. Treat the roadmap as a balanced portfolio, and check that it matches your vision and framework. Where it does not, you may need to say no to work that is off strategy.

Team Goals

The chapter opens with an engineer who spent weeks rebuilding a text editor while a revenue experiment waited. Goals keep people pointed at the same thing and back up the strategy. Paired goals help two teams agree on the priority of shared work. Success is more than launching something, so write goals around the benefit you want and avoid bad incentives.

Influencing without Authority

Engineers do not report to the PM, so you persuade. Find out what matters to each person, say it back to them and show how your idea helps them too. Involve your teammates, but do not always wait for everyone to agree. Sometimes you decide, and sometimes you need full buy-in. Timing matters, because a team is easier to convince at the right point in its planning cycle.

Ownership Mentality

The chapter opens with the college group project where you end up doing most of it. Its point is that, for a PM, nothing is outside the job. If a gap exists, you make sure it gets filled, with kindness and diplomacy. People who show this attitude get pulled into the important conversations, and people who do not get left out.

Becoming a People Manager

Managing people looks more attractive than it is. The author stayed an individual contributor for extra years and counts them among the best of her career. You should have solid PM experience first, and chasing the move early pulls attention from skills you still need. If you want it, tell your manager.

The Career Ladders

Your level, not your title, sets your seniority, pay and expectations. Doing the current job well is not always enough to move up. In the middle levels the focus moves to product strategy and in the upper levels to the organisation, and each move leaves you feeling like a beginner. Levels rest on three things: scope, autonomy and impact. The book gives impact as how meaningful the improvement is multiplied by how many people feel it.

What to do with it

• Pick the skill area where you are weakest and read only those chapters first.
• Write down your goals for the next level, and ask your manager which skills to focus on.
• Book regular conversations with users and set a habit of reading your product data each week.
• Write your strategy as a vision, a framework and a roadmap, then check your current work against it.
• Choose one chapter practice per month, try it, and note what happened.