Initial Impressions from Cracking the PM Career

I recently started reading Cracking the PM Career after finishing Cracking the PM Interview. The first book had a significant impact on how I approached product management interviews because it provided practical frameworks that could be applied immediately. Whether it was product sense questions, execution questions, estimation problems, or strategy discussions, I found myself using concepts from the book during mock interviews, real PM interviews, and even while building side projects.

Naturally, I expected Cracking the PM Career to be a continuation of the same themes. A few chapters in, however, I realised that the two books are trying to solve very different problems. While Cracking the PM Interview focuses on helping aspiring PMs get into the role, Cracking the PM Career appears to focus on what happens after that. Instead of interview frameworks, the book seems more interested in developing the mental models, habits, and ways of thinking that help product managers succeed over the long term.

These are still my initial impressions, so my views may evolve as I progress further. However, there were a few ideas that immediately stood out and felt worth reflecting on.

Product Management Feels Like Pattern Recognition

One theme that keeps appearing in the book is the idea of following breadcrumbs and identifying patterns. Product managers rarely receive perfectly packaged information. Unlike a mathematics problem or a coding challenge where all the inputs are clearly defined, product problems often begin with incomplete information, conflicting opinions, vague user feedback, and messy datasets.

As I was reading this, I was reminded of how I prepared for coding interviews. During my engineering preparation, there came a point where I realised that solving DSA problems was less about memorising solutions and more about recognising patterns. A problem that initially looked unfamiliar often became manageable once I recognised that it was really a sliding window problem, a binary search problem, or a dynamic programming problem in disguise.

Some common examples include:

• Sliding Window
• Two Pointers
• Binary Search
• Dynamic Programming
• Graph Traversal

The actual problem statement changes, but the underlying pattern remains the same.

The more I read, the more I realised that product management seems to operate in a surprisingly similar way. Product managers are constantly looking for recurring signals hidden inside user behaviour, business metrics, support tickets, feature requests, and stakeholder conversations. What separates experienced product managers from beginners is often their ability to recognise patterns that others miss.

A user complaint is rarely just a complaint. A drop in engagement is rarely just a number. A feature request is rarely just a feature request. Each of these signals may be pointing towards a larger behavioural pattern that needs to be understood before any solution is proposed.

That connection between coding patterns and product patterns was one of the first ideas that genuinely resonated with me.

The Product Lifecycle That Stood Out

The concept that caught my attention the most was the product lifecycle described in the book:

• Discover
• Define
• Design
• Develop
• Deliver
• Debrief
• Discover it again

At first glance, it looks like a fairly standard product development process. Most people familiar with technology products have seen some variation of these stages before. However, the more I thought about it, the more I appreciated the way the framework is structured.

The reason is simple.

Most people naturally focus on the middle of the cycle.

When people think about product management, they often think about roadmaps, designs, development, sprint planning, and feature launches. Those are the visible parts of the job. They are also the parts that receive the most attention in discussions, articles, and social media posts.

What stood out to me was the emphasis on the beginning and end of the cycle.

The framework begins with discovery and eventually loops back into discovery again. That may seem like a small detail, but it fundamentally changes how product development is viewed. Instead of treating a launch as the finish line, the framework treats a launch as another source of information.

Every feature release creates new data.

Every user interaction creates new signals.

Every success or failure teaches something about the market, the customer, or the product.

Those learnings eventually feed back into the next cycle of discovery.

That idea feels much closer to reality than the linear version of product development that is often presented in textbooks. Products are not built once and completed forever. They evolve through continuous cycles of learning and refinement.

Discovery Appears To Be The Most Important Stage

If there is one concept that has stayed with me after reading the first few chapters, it is the importance of discovery.

The book repeatedly reinforces the idea that product teams should spend a significant amount of time understanding the problem before discussing solutions. This sounds obvious in theory, but it is surprisingly easy to skip in practice. Most builders, myself included, naturally gravitate towards solutioning because building feels productive.

The challenge is that building the wrong thing efficiently is still a mistake.

What I found particularly interesting is how the book frames discovery as a search for opportunities that are both meaningful and feasible. A problem may affect millions of people, but if it cannot realistically be solved, it may not be the right opportunity. On the other hand, a problem may be easy to solve but too small to create meaningful impact.

The sweet spot seems to be finding opportunities that satisfy three conditions:

• Large enough to matter
• Valuable enough for users to care about
• Feasible enough to execute successfully

When I reflected on some of the products and side projects I have worked on, I realised that many challenges can be traced back to this stage. In hindsight, several execution problems were actually discovery problems that had not been solved properly at the beginning.

The more I think about it, the more discovery feels less like a phase and more like a skill.

My Early Takeaway

So far, Cracking the PM Career feels less like a book about product management interviews and more like a book about product management thinking. The shift may sound subtle, but it creates a completely different reading experience.

Instead of focusing on frameworks to answer questions, the book appears to focus on frameworks for understanding problems. Instead of teaching readers how to perform during interviews, it seems to focus on how product managers develop judgement over time. That distinction alone has made the book interesting enough for me to slow down and reflect on what I am reading rather than rushing through it.

I am still early in the book, and many of my opinions will probably evolve as I progress through later chapters. However, if the first few chapters are any indication, the biggest lesson may not be about product management itself. It may be about learning how to recognise patterns, ask better questions, and spend more time understanding the problem before becoming attached to a solution.

For now, that has been my biggest takeaway.