How many pizzas are delivered in Manhattan? How do you design an alarm clock for the blind? What is your favorite piece of software and why? How would you launch a video rental service in India? This book will teach you how to answer these questions and more. Cracking the PM Interview is a comprehensive book about landing a product management role in a startup or bigger tech company. Learn how the ambiguously-named "PM" (product manager / program manager) role varies across companies, what experience you need, how to make your existing experience translate, what a great PM resume and cover letter look like, and finally, how to master the interview: estimation questions, behavioral questions, case questions, product questions, technical questions, and the super important "pitch."
Gayle Laakmann McDowell is the founder / CEO of CareerCup, and the author of Cracking the PM Interview, Cracking the Coding Interview, and Cracking the Tech Career.
Gayle has worked for Microsoft, Apple and Google as a software engineer. She holds a bachelor's and master's degree from the University of Pennsylvania in Computer Science, and an MBA from the Wharton School. She currently resides in Palo Alto, CA.
Required reading for prepping for PM interviews. Delivers on what it promises. But it perhaps underemphasizes that there are many other good ways to skin the cat. In addition to this book, I recommend also reading "Decode and Conquer", which will give you more example answers and offer different solid approaches/ways to think about the interview questions asked.
Will these books alone make you a good PM? No. Gaining mastery over the concepts mentioned in the books and building good product sense and industry knowledge will take much more time. Confidence, clear communication and persuasiveness are skills that are required to ace the PM interview (and be a good PM). Having an extroverted personality and business savvy will also go a long way.
TL;DR - be a wicked smart generalist because the market is still defining the role
Having just added the title of "Product Manager" at my current employer, I needed to know what I didn't know. This book did a fine job of starting that process, but ultimately left me wanting.
The essential job function is to keep your product moving forward. Because the programming staff is the engine for the machine for any software company, the need to "speak programmer" is first among equals. But you also need to speak management to executives, sales to field reps, artsy to design staff, and so on. You'll advocate for scarce resources to keep your ideas alive, own the accountability for any delays in the timeline, maintain vision for the grand picture during every minor release. And you have to do this with every indirect influencing skill in your arsenal. You don't have a staff who reports to you; you have an assembled team who unite (or not) under the common goal you champion.
My chief complaint about the book is actually a complaint about the field. It's not settled yet. The ideal of "big data scientist" went from obscurity to codification in less than five years. The ideal of "product manager" has been around for more than twice that, but nobody quite knows what to do with this need that is neither fish nor fowl. Even the title changes depending on what company you're talking about. Perhaps that's why the interviews revolve around programming, and why the role is customarily filled by a programmer who wanted to stop programming: when in doubt, be the engine.
I read this book and landed the job of my dreams - so how can I possibly give it anything less than 5 stars? :D
To be serious though: my interviewing process was in some ways very similar to what was described here, some aspects exactly the same. But in other ways, it wasn't. Then again, I'm not in the US and I wasn't applying to Amazon/Facebook/Google. So the book will probably be even more accurate for people who do that.
I found this book to be well-structured, concrete, to the point, and very helpful.
It gave lots of examples of questions/problems and possible solutions, as well as approaches and the reasoning behind them. It teaches you to think in a way that will get where you need to be even if your questions will be different.
I would even recommend it to people who are not actually seeking a PM job at the moment. Because I felt like the benefits of this book go beyond getting hired. If you're transitioning into a PM role officially or unofficially within the same company without a formal interview - sometimes it's tough to get the hang of expectations and responsibilities. This is what happened to me a couple of years ago. This book gave me some much-needed clarity and insights. I finally understood what I've been doing for the past 2 years LOL :D
Some phrases hit so close to home I even cried. I highlighted so many passages it's embarrassing.
I will be reviewing this book from two angles - (1) from POV of an aspiring PM and (2) from POV of an investor / a business analyst.
POV of an aspiring PM - an extremely good guide book for all aspiring PMs across seniority that I think have stood the test of time (published in Dec-2013 but many things discussed are still extremely relevant) and should continue to do so. Before going through the book, I myself had spent a few days trying to understand what the PM job entails from PMs and multiple websites but none of them presented the details in a thoughtful manner that is easily digestible. This book managed to do the opposite - it addressed all the gaps that online sources might have missed out / might have presented in a messy manner. Most useful would be the example questions and sample answers. Bottom line - worth reading.
POV of an investor / business analyst - My personal opinion is that a good investor / business analyst should also have a great product sense. In that context, this book allowed me to understand how PMs think / companies want PMs to think. This is a good starting point imho to become someone w/ better product sense. Might consider going through the "Cracking the PM career" book next. Bottom line is the same - worth browsing at the very least.
Ця невелика книга являє собою величезну кількість інформації для продакт менеджерів. Я рекомендую її прочитати, не залежно від того, чи плануєте ви проходити якусь співбесіду чи ні. З цієї книги можна “витягнути” велику кількість нових навичок та прийомів, які допоможуть вам не тільки покращити власну роботу але і почати насолоджуватися нею. Або нагадати собі про вже давно забуті речі. Книга класно структурує інформації і дає чудове підгрунтя для подальшого навачння.
Це дуже освіжає читати книгу, яка говорить дуже конкретні і дуже потрібні речі базуючись на цільовій аудиторії. Чесно, ця книга, напевно, одна з найкращих, які я прочитав за останній час.
Кілька улюблених цитат з книги: "It’s important to know what’s under the hood and have an interest in it. If someone doesn’t have any interest in the technical side, then maybe the technology field isn’t for them. How would you feel about teaching yourself some Java by buying a book, installing eclipse, and building a simple mobile app? If that would excite you, that’s great. If you think, “Do I really have to?” you’re probably in the wrong industry."
"It’s often been said product managers are the “CEO of the product,” but, unfortunately, the popular wisdom here is somewhat inaccurate. You are not the CEO. You will not do acquisitions or mergers. You will not deal with shareholders. You will often not even deal with finances. However, you are responsible for delivering the best product to customers. Note this sentence covers three very important terms: “delivering,” “product,” and “customers.” Most PM questions revolve around these three terms."
Great book for an extensive overview of how to market yourself, CVs and interview processes. Interesting to peak into the Top Tech (Google, Facebook, Amazon, etc) culture and recruitment process - which is not representative of the tech industry.
Lenghty, and anedoctal, description of what is a PM (everything that is in between ~ that makes a product great)
My notes :
What is a Product Manager *PM is responsible for making sure that a team ships a great product.
*Prioritize - A 1% PM knows how to sequence projects. They balance quick wins vs. platform investments appropriately. They balance offense and defense projects appropriately. Offense projects are ones that grow the business. Defense projects are ones that protect and remove drag on the business (operations, reducing technical debt, fixing bugs, etc.).
*The description of product manager as CEO misses the boat: product managers don’t have direct authority over the people on their team. As a PM, you’ll need to learn to lead your team without authority, influencing them with your vision and research.
*One reason product management is such an appealing career is you get to sit at the intersection of technology, business, and design. You get to wear many hats and learn multiple points of view. While the product life cycle varies by company (and sometimes even by team), it usually follows a general pattern of Research & Plan, Design, Implement & Test, and Release. Of course, these frequently overlap and feed back into each other.
*Some companies or teams split the product manager role across two people: the more business-focused person and the more engineering-focused person. When companies make this split, they call the engineering-focused person the technical program manager or technical product manager (TPM), and they call the business-focused person the product manager (PM).
*While most roles on the team are crisply defined, product managers have a more fluid role. When you’re a product manager, your job is anything that isn’t being covered by other people. As a PM, you’re responsible for the success or failure of your product, and no job is beneath you.
On Career *Find teams where you can pick up new skills “Seniority is all about experience, but there’s a catch,” says Chrix Finne, a senior product manager at Optimizely (and formerly Google). “You can control how fast you accumulate experiences.” If you’ve mostly worked on improving a mature product, consider joining a team building a new, unlaunched product. If you’ve always worked on consumer-facing products, consider trying something business facing. Look at your skillset, decide which skills you need, and then find a place where you can learn those skills.
On Telling stories *Situation, Action, Result (S.A.R.) The Situation, Action, Result structure can be used on its own or in conjunction with the Nugget First approach. The S.A.R. (also often called S.T.A.R.—Situation, Task, Action, Result) approach
*Nugget First The “nugget first” structure is a simple one. It means to start off your response with the “nugget”—or thesis—of what your story will be about.
On Estimations / Case Questions *Rule of 72: Here’s a fun and useful tip: if you need to calculate how long until something doubles, divide 72 by the percent increase. That is, an investment, population, salary or other value increasing at x% per year will double after approximately 72/x years. This rule works fairly well (being within 5 or 10% of the true answer) for smaller values of x. However, even up through a 100% annual increase (which is doubling within a year), the result is still within 30% of the actual answer.
*Number of Digits: if you multiplied a and b together to get n, then the sum of the number of digits in the terms should be within one of the number of terms in the result. Or, more precisely: digits(a) + digits(b) = digits(a * b) Or: digits(a) + digits(b) = digits(a * b) + 1 For example, 823 * 1032 will have either 6 or 7 digits. (In actuality, it has 6 digits.) If you wind up with a number like 84936, you’ll know you’ve done something wrong.
*In product design questions, pay attention to the details and be sure to ask probing questions. Microsoft interviewers often enjoy testing how you handle ambiguity. They might, for example, ask you to design a pen and not mention that it’s a pen for astronauts. They want to see that you ask a lot of questions to understand the customer before running down some path.
On Customer Purchase Decision Making Process *There are many frameworks to model the decision-making process, but two of the most common are AIDA and REAN. AIDA models customer decisions as Attention (or Awareness) -> Interest -> Desire -> Action. Attention: You need to get the customer’s attention somehow. A snappy email heading, perhaps? A snazzy ad? Or maybe a mention from a trusted friend or website? Interest: Now that you have the customer’s attention, you need to get them interested in your offering. What are the advantages or benefits of your product? Desire: With the customer’s interest piqued, you need to convince the customer that they want your product. Action: Finally, with the customer desiring your product, they take action to purchase the product. REAN expands this to add on post-purchase behavior. Reach: The customer is aware of your product. Engage: The customer is engaged and considering your product. Activate: The customer takes action to purchase the product. Nurture: The customer has purchased the product, and it’s now your responsibility to nurture this relationship.
On CVs *The Rules Every rule has its exception, but they’re called rules for a reason. Proceed carefully if you think one of these rules doesn’t apply to you. Rule #1: Shorter Rule #2: Bullets, Not Blobs
On the Companies you interview for *Knowing the “why” means understanding the following: Mission: Look up the company’s mission statement. How does it live up to this mission? Be specific. Strategy: What do you think is the company’s strategy? Are there any missteps with respect to that? Strengths: What are the product’s selling points? How does the company leverage those? What about the company or its products has enabled its success? Weaknesses: What are the major issues with the company and its products? How should the company address those weaknesses, or should they just accept them? Challenges: What are the biggest challenges for the company right now? How do you see them addressing them.
Assorted Bits *Personally, I don’t believe linear prioritization is effective in the long term. I’ve written a separate post on product prioritization called The Three Buckets
*This is a good thing to remember: if something continuously divides in half, it is O(log(N)) time.
This book is the complete package for those who are looking for a job in Product Management. It has information about the role, its challenges, how to apply at different firms based on your background, how to make your resume and cover letter, how each firm is different from other and it even has case preparations and coding questions as well. This book is a complete guide on how to get into product management and how to grow as one. Highly recommended to those who are planning to start their career in product management.
A great read to prepare for PM interviews but also to - introspect on one's career - understand one's motivations to apply to a PM role - revisit the way one thinks about product - up one's managements paradigms Great read and highly recommended
Amazing workbook for current or those who want to become Product/Profile/Project Managers, Product Owners, Business Analysts. The greatest thing about book is that it has no redundant information, only the most significant facts and real example which are extremely helpful in preparation to interviews or just getting better. It includes much useful tips and details about FANG and other top tech companies. Good Luck😊
Cracking the PM is a dense workbook/reference that is well-written and fulfills its promise.
Despite its age, it is still an outstanding book to prepare for Product Management interviews, whether you are looking for a job or recruiting professionals that fit your organization's needs.
I would argue that most of the advice also applies to Product Design interviews or any business-centric type of interview.
Please note that the book clearly focuses on Product Management in the context of tech companies and, consequently, has a bias towards engineers-as-product-managers. Nevertheless, technical background of note, there is a ton of value to unpack here.
Such a great resource to crack the PM interview but also for interviewing in general (not just for PM). A must read for many people interviewing nowadays, lots of sample questions and use cases that will make you think and then motivate you to research even more.
I started reading it with not much hopes of it being a good book and actually find it interesting and plenty of thought-provoking items not only for interviewing scenarios (being interviewed or interviewing candidates) but also for re-thinking the product techniques I use at work on a daily basis.
If you are planning or even considering to enter in management, be it as project, program or product management, this book is a perfect guide. The ambiguity of the job and responsibilities had been vague to me, even after acting as all three of the above. But reading it, made me comfortable that this was perfectly fine and sort of nature of the job. This book allowed me to identify what are all the different types of management role, their responsibilities, and most surprisingly, the fact that how different companies have different interpretations for the same job title. I highly recommend reading this book if one wishes to move into management from a technical position. For other folks, the book has covered them too, and has a guide for their transition. For me this book was very relatable as I had experienced it all firsthand. I wish I had found this book earlier and I hope that this review will help you.
the chapters on product and problem solving don't only improve your interviewing skills, it helps you think better and become a better product manager. moreover, this book helped me understand how to find a great pm when hiring. highly recommended for aspiring product managers, product managers, and hiring ceos.
I read this book after some work experience. This book gave me a thorough perspective about the PM job. I had to skim through some sections of the book, but overall it was filled with quality material. I am really glad that somebody recommended me this book. Must read for anyone who is aspiring for a PM role someday.
Really interesting book that covers a variety of areas that different companies ask when interviewing PMs. There are some really great questions and brainteasers which will make your brain busy 😜 overall, It was interesting to see how do most powerful companies interview PM candidates to find the best ones.
This book is very similar to it's much more well-known cousin "Cracking the Coding Interview". But due to the nature of the Product Management role, it doesn't suffer from many of the former's issues.
As an engineer, I've not been paying much attention to the Product Management discipline. To add to that, I've found that this role is called by very different names and carries very different responsibilities in different companies.
Some of the things I've actually learnt from this book: 1. What really is the difference between the Product Management, Program Management and Technical Program Management role? 2. What do PMs actually do? 3. Are PMs even necessary? 4. What makes a good PM?
The book is structured very well. After describing and clarifying the various roles, it describes concrete examples of people working in these roles in well-known companies. It mentions their day to day life and professional histories. It is fascinating to see how people arrive at Product Management following very different paths.
The problem with "Cracking the Coding Interview" was that the book came across as a giant compilation of typical interview questions. I felt that it did not really prepare readers to solve questions they hadn't encountered before.
That is not a problem in this book. Due to the nature of this subject, it is not possible to simply list all questions and fixed answers for each. You really need to explain to the reader how they can answer these questions based on their own experiences. This eventually results in a more generalized book that can actually prepare you for yet-unseen questions.
The sections on resume and cover letter are useful, but a little tedious to read.
The final section lists a bunch of programming questions and how to go about solving them. Considering that this is not a huge focus in PM interviews, the authors have appropriately chosen to not go too deep or tackle overly complicated questions.
In conclusion, for someone curios about the PM role, this was a very useful read.
Disclaimer: I skipped the coding related chapter as I am not a grad in computer science.
The book does a great job in explaining the role of a product manager and explains the kind of questions one might encounter in a PM job interview. Must read for those who aspire to get a job as a PM. You might have to revisit the book again and again.
Note: You won't become intelligent and a competent PM all of a sudden. But the book nudges you in the right direction if you are already smart.
If you're thinking about starting your career on product management this is a great book to start. It not only helps you to know what an interview would be like, it also helps you to understand the position better and to know if it's for you or not.
Great overview of product management and interviews in general. I especially liked the preparation grid idea for preparing for behavioral interviews. There is a LOT of good info in here, and great questions to prepare for a multitude of product related questions.
Quotes - "'Credibility is the currency of a PM.'...The most straightforward way to build credibility is delivering results." Sometimes doing something big once isn't enough for risk averse folks to promote you. - "Its important to realize that, in a lot of PM roles, you get to a tipping point, after which making decisions and working with a team become a lot easier...you cannot speed up time, but you can choose a place where you're more likely to become a senior member of the team.... as an early tip be as much of an observe as you can.... understand the context of things. Be more inquisitive. Instead of telling people what to do or trying to make decisions, try to ask questions.... Another trip to get that tipping point early on is to demonstrate value to people. Make it so the fact that you're there is driving something that wouldn't happen if you weren't there... Another tip for more senior PMs: Figure out your own framework and principles for how you make decisions, and communicate that as often as you can.... Make it clear to the people around you why you're making a particular decision so they see that you're consistent with your decisions. Theres nothing engineers hate more than subjective decisions that change from one day to another." - "... whoever writes things down has the power.... whoever writes things down records history.... Also, writing is thinking. If you go through the details of writing things down, you end up thinking about corner cases." - If you're interviewing to be a PM, it's good to look at every problem starting with 'who is the customer?' And 'what is success?' I do so this all the time." - preparation grid for behavioral questions: leadership/influence, successes, challenges, failures/mistakes, teamwork, add 3 examples of each and use the SAR method (situation, action, result). - "Failure is okay; helplessness is not." [In stories]. - "I often joke that much of the time your job is to be the advocate for whoever isn't currently in the room - the customer, engineering, sales, executives, marketing. This means you need to be capable of doing other people's jobs, but smart enough to know not to."