Cracking the PM Interview by Gayle McDowell & Jackie Bavaro

• A PM is responsible for making sure that a team ships a great product.
• The PM needs to set vision and strategy.
• The PM defines success and makes decisions.
• The day-to-day work of a product manager varies over the course of the product life cycle, you’ll be figuring out what to build; in the middle you’ll help the team make progress; at the end you’ll be preparing for launch.
• During implementation, one of the most important parts of the job is helping the engineers work efficiently. The product manager will check in regularly with his team and learn how things are going.
• For mature products, such as market leaders, most of the work will be iterating on the product and trying to improve it. PMs often have feedback from previous versions as to which areas need the most improvement and can focus on them.
• As a PM on a mature product, it can be very important to make sure you don’t get stuck making small incremental improvements.
• Often, a mature product’s biggest competitor is the last version of that same product. At the same time, mature products often have the luxury of time to make big bets on new ideas.
• PMs are responsible for seeing the entire project through to a successful completion.
• Product managers are able to reduce the number of meetings their teammates need to attend because they’re able to represent the team to other groups and find productive ways of communicating that don’t require meetings.
• Not trusting the engineers’ estimates and promising other teams that the work will be done sooner than the engineers agree to it is one of the fastest ways to ruin your relationship with the team.
• 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 of failure of your product, and no job is beneath you.
• One of the best ways to get a signal on the culture at a startup is to look at where the founders, PMs, and early employees came from.Since product management doesn’t have a single, well-known definition, teams generally bring along the definition that they learned from their past companies.
• The big difference in being a PM at a startup comes from the scale.
• Since startups don’t have large management structures, the PMs naturally become important leaders for the company. Additionally, startups have fewer resources, so there’s more “white space” for the PMs to fill in and more of a need to be really scrappy.
• Engineers at startups love shipping code quickly and are very wary of overhead, so it’s important to be careful when adding processes like Agile.
• If you ask interviewers what they're looking for in PM candidates, they’ll unusually say that they are looking for smart people who get stuff done.
• One of the best ways to rise above the crowd is to have a side project like a mobile app. This gives you a chance to show your customer focus and product design skills.
• LinkedIn is one of the most valuable sites to focus on for recruiting.
• The most important way a product manager is judged is by the products she’s launched.
• Many people without a background in computer science struggle to form strong working relationships with engineers.
• Great product managers are action-oriented and passionate about delivering results. They will try to take care of what they can themselves, whether that’s gathering data or fixing typos in the product. This frees up development from the more tedious tasks so they’ll be able to do more valuable work.
• Customer Focus is the most important thing to develop when moving from engineering to product management. Engineers and developers can usually pick up most of the other important skills on the job, but a customer focus is one of the defining characteristics of good PMs.
• Many engineers are comfortable in the world of analytical thinking. As an engineer, it’s better to prove things through data than charisma. As a product manager, you need to master both.
• It will be hard to be successful as a PM if you’re still handling a lot of engineering responsibilities; you need to pick up some escape velocity. Consider taking time off between the role switch or having some kind of hand off or party to mark the transition. Then you can dive into your new PM role fully.
• One of the best ways to improve your candidacy for a product management position is to start a side project. This side project gives you a chance to gain experience shipping a product, builds up your resume, shows off your technical skills, shows off your product design skills, and gives you a lot to talk about during your interview. If you hired people to help you, it might also give you a chance to show leadership skills.
• As a PM, the biggest measure of your success will be the products you launch.
• At a growing company, new opportunities are always opening up, and you quickly become one of the more senior employees. This means that even if you had to join a different team or take on a different title from what you wanted, you’d likely get a chance to transition soon.
• Infrastructure teams often don’t sound like a fun place to be a PM, but they’re critically important to the company. The improvements you make as an infrastructure PM can be magnified throughout the company, so they can be a great place for career advancement.
• At some point in your career, your visibility across the company is going to matter if you want to be promoted to higher positions.
• The most straightforward way to build credibility is delivering results. Your teammates all want a good outcome, so they'll naturally start out second guessing your opinions, asking lots of questions, and suggesting different ways of doing things. However, over time they’ll start to see that you’re showing good judgement and getting things done, and they’ll feel comfortable trusting you.
• Another way to build credibility is paying attention to people’s perceptions of you and ensuring that you’re creating the perception you want.
• Make sure you’re building a reputation as a smart, skillful, competent, and dependable person with good judgement.
• Getting an MBA just for the sake of getting an MBA is not worthwhile in tech, at least not in silicon Valley.
• It’s not your experience that lands you an interview; it’s how your resume presents that experience. Even the best candidate in the world won’t get an interview with a lousy resume. After all, a company wouldn’t know that she’s the best candidate in the world.
• A resume isn’t read; it’s skimmed. A resume screen will glance at your resume for about 15 seconds (or maybe less) to make a decision about whether or not to interview you.
• A good rule of thumb is to limit your resume to one page if you have less than 10 years of experience. In more than 10 years, you might be able to justify 1.5 or 2 pages, particularly if you’ve held many different jobs.
• Focus on what is important, and leave out the rest.
• Read through your resume. Anything that’s three lines of text or more should be condensed. Additionally, you should aim to have no more than 50 percent of your bullets expand to two lines. That is, at least half of your bullets should be just one line, with the remainder being two lines.
• People don’t care what you were told to do; they care what you did.
• You want to focus on your accomplishments. Prove to the resume screener you had an impact.
• As much as possible, quantify your accomplishments.
• A good resume is reasonably compact and quickly showcases your highlights.
• Employers want PMs who have technical skills, love technology, possess initiative, are leaders, and will have an impact. A resume is a chance to showcase these parts of your background.
• Don’t list something from a long time ago unless it really makes you stand out.
• You should understand what the company is doing at a deep level.
• You should know not only what the company is doing, but why it is doing it. Knowing the “why” will help your answers fit the company’s view of the world.
• Successful people tend to know where they’re going in life. If you don’t have a plan, an interviewer might worry you’re not very serious about your career.
• Understanding other people is a fundamental part of teamwork, leadership , and persuasion, and therefore a fundamental part of a product management role.
• Failure is okay; helplessness is not.
• Here’s a fun and useful tip: if you need to calculate how long until something doubles, divide 72 by the percent increase.
• Interviewers are looking for structured thinking. The easiest way to show this is to give a structured answer and call out which part of the structure you’re on.
• Strengths are the internal factors that benefit a product. This can include anything about the costs, product features, company culture, reputation, infrastructure, or other aspects.
• SWOT Analysis: strengths, weaknesses, opportunities, threats.
• The two most common good ways to sort an array are quicksort and merge sort. The others are less efficient in general or only work with specific assumptions.
• Big O notation is a way to express the efficiency of an algorithm. If you’re going to be working with code, it is important that you understand big O. It is, quite literally, the language we use to express efficiency.
• Recursion can be a useful strategy to solve a large number of problems. It works well when the solution to a problem can be defined in terms of the solutions to subproblems.
• Any problem that can be solved recursively can also be solved iteratively, although sometimes doing so is much more complicated. However, recursion comes with a drawback, which is memory usage.
• The top 10% of product managers excel at a few of these things. The top 1% excel at most or all of them.
• Think big - A 1% PM’s thinking won’t be constrained by the resource available to them today or today’s market environment. They’ll describe large disruptive opportunities, and develop concrete plans for how to take advantage of them.
• Communicate - A 1% PM can make a case that is impossible to refute or ignore. They’ll use data appropriately, when available, but they’ll also tap into other biases, beliefs, and triggers that can convince the powers that be to part with headcount, money, or other resources and then get out of the way.
• Simplify - A 1% PM knows how to get 80% of the value out of any feature or project with 20% of the effort. They do so repeatedly, launching more and achieving compounding effects for the product or business.
• 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.
• Forecast and measure - A 1% PM is able to forecast the approximate benefit of a project, and can do so efficiently by applying past experience and leverage comparable benchmarks. They also measure benefit once projects are launched, and factor those learning into their future prioritization and forecasts.
• Execute - A 1% PM grinds it out. They do whatever is necessary to ship. They recognize no specific bounds to the scope of their role. As necessary, they recruit, they produce buttons, they do biz dev, they escalate, they tussle with internal counsel, they…
• Understand technical trade-offs - A 1% PM does not need to have a CS degree. They do need to be able to roughly understand the technical complexity of the features they put on the backlog, without any costing inputs from devs. They should partner with devs to make the right technical trade-offs.
• Understand good design - A 1% PM doesn’t have to be a designer, but they should appreciate great design and be able to distinguish it from good design. They should also be able to articulate the difference to their design counterparts, or at least articulate directions to pursue to go from good to great.
• Write effective copy - A 1% PM should be able to write a concise copy that gets the job done. They should understand that each additional word they write dilutes the value of the previous ones. They should spend time and energy trying to find the perfect words for key copy, not just words that will suffice.