What this guide is about
This resource is meant as an introductory guide for people who are either new or aspiring to break into the product management field. It’s focused on PM work at tech startups, but many of the points can be applied across industries. The guide includes some of the best resources from across the internet that I found over the years. There are great contents out there, but they are surrounded by a hell of a lot more noise. What this guide will hopefully do for you is to cut through all the noise and accelerate the knowledge acquisition phase of your learning. It’s not meant to be an exhaustive list of everything you need to know about product, nor will you become a great product manager after reading this. Life isn’t so simple. Think of it as a giant list of what I wish I had known when I first started product management. I hope this helps!
If you find this guide interesting, please subscribe to the blog as well. I’ll be writing separate posts every month that deep dive into specific aspects of product management. you can also find me on twitter @yilunzh.
Table of Content
- Requirement Gathering
- Business Strategy
- Metrics and Financial Economics
Product management is both easy and hard. It’s easy because being one doesn’t require any specialized skills. If you can think, read and write like a competent human being, you can become a product manager.
Product management is also very hard. A product manager is a jack of all trades. While you don’t have to be an expert on any single subject, you absolutely need to be competent in many different areas. The problem is that it takes time to learn a new skill from scratch. Malcolm Gladwell famously said that it takes 10,000 hours of deliberate practice to become world class in any field. Assuming that learning a new skill is your full time job (40 hr/week), that is equivalent to 5 years of your life. At first glance, it seems like product managers are geniuses. They are outliers that can grasp new concepts in days instead of weeks, learn new skills in months instead of years. They are the kids you knew in college who partied harder than you ever did yet still managed to get 4.0s across the board.
While I wish that’s true (I would be flattered), it is simply not the case. I sort of lied when I said that product managers don’t have any specialized skill. They do. All the great ones I know are able to absorb and apply new information at an abnormal rate. In the beginning, I thought they were simply smarter than me. Overtime, I came to realize that like any other skill, it can be learned.
People often think that the pace of learning is linear. For example, if it takes 5 years to master something, then it must take ~2.5 years to be average and 4 years to be good. In reality, this is not the case (in a good way). I want to highlight 2 key points here:
- The 80/20 rule applies to learning. It’s far easier to go from incompetent to good than from good to great. With the right resources and techniques in place, it only takes 20% of the time/effort to get 80% of mastery. I believe that a great product manager doesn’t need to be a master at everything, only competent to good (50-80% mark).
- Learning takes the form of an S-curve. In the beginning, it takes a lot of time to just get the basic theory down. You feel like you are spending a lot of effort for very little gain. This is when many people drop off, because they feel like they are not making any progress. Keep in mind though, nothing worthwhile is easy. I would argue that this is the time for you to double down and power through it. Once you get past the initial knowledge acquisition phase and start integrating them into your knowledge bank, you will notice that the rate of learning becomes exponential.
There is a fair bit of content in this guide. They are categorized and ordered in a way that I think make the most sense. Feel free to skip around and explore as you see fit 🙂
This section is to answer the most common questions people have about product management and introduce the core principles that I think a PM should know. This is the basics of the basics, which is fine. We all have to start from somewhere 🙂
To set the table, I think it’s best to take a look at what other people say about PM. I also put an old blog post I wrote in here as well (shameless plug!). I hope you find it at least somewhat insightful.
Questions to ponder:
- What’s the role of a PM? How does it fit within the larger team/organization?
- How does a PM spend his/her day?
- What makes a good PM?
- What makes a shitty PM?
- What other PM say about PM
- What people that invest in startups say about PM
- What Ken Norton (Partner at Google Ventures) say about PM
- What someone who teaches PM say about PM
- What I say about PM
- Reach out to someone who is currently a PM and ask him for a piece of specific advice on a topic you want to learn about.
If there’s one thing you need to do better than anyone else at the company, it’s to understand your customers. To the engineers and designers, you are the voice of the customer. In order to clearly articulate the requirements to your team, you need to understand their pain points and needs more than anyone else.
This section doesn’t get into any of the tactical advice about conducting customer research (that’ll come later). It’s more about building a foundation and a framework in your mind about how to approach the problem.
Questions to ponder:
- What should you focus on when trying to understand your customer?
- How should you treat a feature request from existing users?
- Why is cycle time for learning important?
- YC lecture 4 – Building Product, Talking to Users, and Growing
- Steve Blank’s customer delivery process
- How to Test Drive Your Business Idea Before Quitting Your Job (Concept applies for testing any new major products/ideas)
- If you work in a B2C company, listen to some customer service calls and writeup your learnings.
- If you work in a B2B company, reach out to a few customers and get their feedback on your product. Again, writeup your learnings.
Discover product-market fit
Product-market fit has become quite a buzzword in recent years. I think it’s often mis-used and misunderstood. Marc Andreessen, the founder of Andreessen & Horowitz, defines it as “being in a good market with a product that can satisfy that market”. Steve Blank, who you’ll read extensively later, refer to it as the step between customer validation and customer creation. To me, finding product-market fit means solving a big enough problem for a subset of people that they are willing to pay you money AND tell everyone how great you are.
Regardless of how you word it, the core idea behind product-market fit is to understand the conditions that your product must meet in order to become a viable and scalable business (i.e. Is the market big enough? Is the problem painful enough? Is the solution good enough? Does the economics work? etc.). These are the questions that you have to clearly articulate whenever you are pitching for resources.
Questions to ponder:
- How do you define product market fit?
- Why is product market fit important?
- How do you know if you have achieved product market fit?
- How do you find product market fit?
- Getting to product market fit
- Doing things that don’t scale
- How to get ideas
- Research a tech startup that’s currently growing exponentially (e.g. Uber, Airbnb, Dropbox etc.). Answer the following questions:
- Why do you think they were able to achieve this level of growth?
- What big hurdles did they have to overcome?
- How did they overcome them?
Be bold and ambitious
This sounds a bit cliche, but it’s one of the most common traits among successful entrepreneurs and PMs I know. To be more specific:
- They tend to have a healthy disrespect towards traditions. “Because that’s how it’s always been” is not an acceptable answer.
- They view problems as opportunities. The bigger the problem, the more lucrative the opportunity.
- They are inherently optimistic and have incredible confidence in their own ideas and abilities. They have so much confidence that they can’t fathom the possibility of failure.
Being bold is contagious. Peter Diamandis, the founder of X Prize, stresses the importance of launching your idea/product above the line of super credibility. His point is that the best ideas are those that are so crazy, but so amazing that people want to actively help you make it happen.
Questions to Ponder:
- Why do people continue to underestimate human progress in the long term, even though all the science and historical data suggest otherwise?
- How can you train yourself to break out of that habit?
- What are some major technology trends right now? How do you think those things will change your life in 10 years?
- Exponential thinking
- 10x Moonshot
- On having optimism for the future
- Write about a new technology or trend you are excited about. how do you think it’ll evolve over time? What market conditions have to be met in order to make that vision a reality?
This section focuses on the fundamentals skills you need in order to become a competent product manager. By the end of this section, you should have the requisite knowledge to perform the major functions that a product manager do on a daily basis.
As a PM, requirement gathering is probably an activity you will spend the most time doing day to day. There are a lot of resources out there on how best to write user stories (some are linked in the readings below), so I wouldn’t get into the weeds here. But I do want to share some rules of thumb I follow when I’m unsure what to do:
- Be precise and clear
- Say exactly what you mean. Don’t use ambiguous terms or acronyms if you can help it. If there are acronyms, clearly define them ahead of time.
- Use everyday language, not big words that nobody understands. Your requirement should read like the way you explain how a product works to a smart friend.
- Be concise
- If there are sections of the requirement that feels repetitive, look to break them out and consolidate them into one section. Then, wherever that is relevant, simply call out that section. This way, the engineers is not reading duplicative information repeatedly. Moreover, whenever there is a change to the requirement (there will be lots), it will also be easier for you to change without forgetting a section. In the programming world, this practice is called keeping your code DRY. It make it more readable and maintainable. The same concept applies here.
- Use ample illustration, especially mockups and flowcharts to communicate complex flows.
- Be thorough
- One of the worst thing that can happen is to have your engineer read your requirement and think of an scenario that you haven’t thought of. It slows down development and kills your credibility in their eyes.
The readings below should help get you started on writing good requirements.
Questions to ponder:
- What are some methods you can use to gather requirements?
- What are the key components of a good requirements document?
- How best to share your requirements with the engineering team?
- Chapter 11: Getting Real by 37signal
- Khosla Ventures, how to write a good PRD
- Effective workflow for writing PRD suggested on Quora
Exercise: Requirements writing
- Think of a product idea, write the necessary requirement documents to be handed off to engineering
The first article in the reading below basically sums up how I feel about writing. I actually never appreciated good writing until I started building my first startup Fleetbit after college. At the time, we were building Uber like apps for the taxi companies so that they can compete against Uber. Taxi companies, in case you don’t know, are incredibly backwards. In order to educate our potential customers on this new technological trend and why that’s going to fundamentally change their business, we started an industry blog. One day, when we were in a meeting with one of the taxi company’s CEO, we noticed that all of our blog posts were printed out and sitting on his desk. Apparently he had been reading them and was planning to share them at the upcoming industry conference he chaired. That was when I knew we had became a credible thought leader in this industry, even though we were a tiny company of 5 and had only been in market for 6 months. It opened my eye to the power of clear writing. Part of the reason I am writing this guide is to help me distill my own thinking and reflect on what my strength and weaknesses are as a PM. It’s been an incredibly rewarding experience to write it. I hope you’ll have an equally rewarding experience reading it.
Questions to ponder:
- What are some of your favorite writing that you had read over the years? Why did you like them?
- Why writing is important
- Write better emails
- One of the best examples of good writing
- Write about something you learned/find interesting once a week
Design is one of those things that many people say is important, but not many people truly invest the time in. It is much more than just making things look pretty. It is about building a holistic solution to a problem that your users are having. It takes creativity to come up with the initial solution, but it also takes rigorous research and testing to validate those designs in the wild. It cannot be done in a vacuum.
When working with designers, I believe it’s important for PM to give feedback as much as possible and push the designer to show/test her work consistently. The cost of change during the design phase is 10x cheaper and faster than cost of change during development. Given that technical resource is typically the limiting factor in startup, prototyping and iterating on design quickly is key.
Questions to ponder:
- What does good design mean for you? How do you know it’s good?
- What are some ways you can test your design quickly?
- How do you balance the wants/needs of design vs the reality of technology development and managing complexity?
- How do you incorporate design into the product development process?
- On design thinking
- My Google Venture Design Sprint notes
- On building designs (this tool is awesome, especially if your designer is resource constrained)
- On presenting design
Exercise: Design exercise
- How would you design the following (draw mockups):
- Alarm clock for heavy sleepers
- Car for the blind
- Others interesting scenarios you can think of
Strategy is a very sexy word, mostly because that’s what you see executives or management consultants in fancy suits typically do. They are responsible for coming up with the “strategy” that the rest of the company then executes on. How they came up with it is often not talked about, but people seem to get paid a lot of money to do it…therefore it must be extremely hard. I want to take some time here to demystify the concept of strategy. Once you break it apart, it becomes incredibly clear what strategy is and isn’t.
In the marketplace, a business always has to evolve. Imagine that there are 2 points on a piece of paper. Point A is where the business is at currently. Point B is where the business wants to go. Usually, point B has more customers, more revenue, and more profit compared to point A. Now draw a line from point A to B. That line is the business strategy. A strategy is a way for a business to go from point A to point B. Now when you drew that line in your head, you probably instinctively drew a straight line. That’s the shortest path to point B and is in theory the best strategy. However, there are literally infinite ways to draw a line connecting point A and B, just like in the real world. There are infinite ways to approach a problem. The challenge is to get to point B in as straight of a line as possible.
To be clear, coming up with a strategy doesn’t mean you got to point B, simply that you identified a potential route. Execution is what actually gets you there. With that said, it is still important to understand strategy, because it’s a PM’s job to make sure your team is working on the right things. You are the guide, and a guide who doesn’t know how to get to the end destination is useless.
Questions to ponder:
- Why do big companies fail when they have so much resources at their disposal?
- In a battle for mobile dominance, why did google choose to open source android? How come Apple can’t do the same thing as Google?
- If you were to disrupt your own company or the company you work for, what would you do?
- Understand the nature of technology market
- Innovator’s dilemma – Chapter 1
- Focus on one thing
- New York Time’s internal innovation report
- On engineering growth
- What other say about growth hacking
- Pick a tech company that has recently been struggling (yelp, twitter, stripe). If you were the CEO, how would you try to turn it around? Make sure to write up your proposal.
Metrics and basic financial economics
It’s fairly obvious why understanding metrics is important. They provide valuable evidence that either supports or refutes your hypothesis. It forces you to be methodical about resource prioritization. It also allows you to communicate effectively with the rest of the “business”. A debate based on metrics is going to be much more productive than a debate based purely on opinions and assumptions. It allows people to check their egos at the door and have a healthy, productive conversation.
With that said, I want to stress that while metrics is important, lack of metrics should not and cannot paralyze you into inaction. By definition, if you wait until you have all the information, the opportunity is gone. If Elon Musk looked at the data at the time and said: “Batteries are too expensive, heavy, and hold little power, using a battery to power a car is a ridiculous idea.” then Tesla would have never came to be. There will be many times you will have to make decisions in the absence of data, and that’s totally fine.
Questions to ponder:
- What are the key levers that drive your company’s business?
- How do you expect it to change overtime? Is that a reasonable expectation?
- If you were the CEO, what would you focus on over the next 12 months based on what you learned?
- Key metrics to understanding a business
- Understand basic financial statements
- How to build a projection
- On telling stories using data
Exercise: investment analysis
- Pick a stock and build a case for why you should/should not invest in the company. Use data to back up analysis, including financial projections
I’ll be the first to admit, I’m not really a process guy. I think they are important, but I tend to be a minimalist in this area. I try to keep a pretty open mind about process. My view is that different people like to work differently. Some people like to have more touchpoint and feedback. Others prefer to be left alone to just do their work. Some people like to think through the problem and solution alone and come back to the team to discuss. Other like to come up with a answer together in a more collaborative approach. They can all be equally productive, but need different process put in place to maximize their potential. The point is that process should be used to make the team more productive.
These days, most tech companies I know are either using agile or is transitioning to agile. In technology, the cost of change is low compared to traditional industries like manufacturing. As a result, it’s better to optimize for velocity. Agile processes are specifically designed to minimize communication overhead, thereby increasing speed and productivity. The readings below should get you a pretty good idea on how the process works. However, as I stressed in the beginning, view them as a template/starting point. Different teams will require you to finetune the process differently to get the most out of them.
Questions to Ponder:
- Who are the typical stakeholders in a scrum? What do they do?
- What is typically the process to roll out a new feature?
- How do different product teams work together on larger projects?
- How do you measure effectiveness of your process?
- 5 minute read on agile
- My notes on scrum
- How to prioritize features
- On managing complexity
- Organize a small group of people and play the XP game, a old and famous game that simulates the value of agile in real life
One of the most common questions that gets asked about PM is “Do I have to know how to code?” The answer is no, you don’t need to know how to code. But is it going to help you become a better PM? Absolutely! The simplest way I can put it is that the top tech companies (i.e. google, facebook, amazon, dropbox etc.), who has access to the cream of the crop talent, wouldn’t hire product managers that can’t push code (at least that I know of). The reason is communication cost. Anytime the engineer has to come up a level and speak in “business” terms, the communication is less efficient. It’s much better if the PM can communicate in the same language as the engineers. Granted, finding people who are well versed in engineering as well as business is difficult. That’s why the starting salary for a PM role at those companies is $150k+.
There are a lot of links and readings in this section. It can be a bit overwhelming if you don’t come from an engineering background and never dealt with computers before. Just stick with it. There are tons of great resources out there to help you along. If you have a question, a quick google search will typically yield the answer you are looking for.
Questions to ponder:
- How does data flow from your computer to the internet and then back to your computer? What systems does the data hit? What does each system do with the data?
- How do one web application know how to talk to another web application?
- How do you think machines and humans will interact with each other once general AI is achieved?
- How the internet works
- How the cloud works
- How web application works
- Learning SQL
- How API works
- What is big data?
- What is AI?
- Building analytics systems
- Finish chapter 2 of Odin Project (Web Development 101)
This section covers the soft skills that are needed to thrive as a product manager. It focus more on effective communication, relationship building, time management, and a number of other areas. If mastered, those skills will take you from being a competent product manager to a great one.
This to me is an entire subject upon itself. Asking good questions is probably one of the most underrated and undervalued skill that a PM can have. Eric Schmidt, executive chairman of Google, once said, “We run this company on questions, not answers.” Asking good questions gets you new insights from your customers, which often uncover new opportunities for the business. However, throughout my entire career, people seem to just expects me to know how to ask questions, like it’s something that should come naturally. Make no mistake, asking good questions is a skill. It needs to be practiced and honed like any other skills.
As a PM, you are going to be spending a lot of time doing user interviews. The readings below should give you some good stock questions to start with. Luckily, this is a skill you will get to practice this a lot on the job. If you put your mind to it, you’ll get better really fast. If you are not currently a PM, then find every opportunity to learn and ask people questions. An interesting way to practice that someone suggested to me is to post questions on Quora and measure how good the questions are by the number and quality of the responses you get.
Questions to ponder:
- What are some of the characteristics of a good question? a bad question?
- Besides the way you phrase the question, what are other factors that could potentially impact the response you get from your subject?
- The question “How are you?” is probably the most common question that get asked in any social interaction. Often the response is not very interesting (99% of the time, it’s “good and you?”). What are some other ways you can ask that question to elicit a more insightful response?
- most common questions asked by PM
- examples of good questions
- examples of bad questions
- Listen to podcasts that you like and focus on the questions that the interviewer asks. If you don’t know what to listen to, I highly recommend the Tim Ferris show on iTunes. He ask some of the best questions to some really interesting people.
- Post 1 question a day on Quora and evaluate the responses you get.
Working with others
An analogy i use quite often is that PM is similar to an amplifier in a sound system. By itself, it’s useless. Paired with the right speakers, power supply, and control unit, it’s the difference between a home theatre system and a sound system at a 20,000 people concert hall. Your ability to amplify your team’s output and impact will ultimately be what you are measured on. As a result, it’s important to understand how to best work with the people that are in the trenches with you everyday.
There are lots of generalizations in the readings below. However, I found that most of them do hold true based on my own experiences. Similar to the process section, use these as a guide and reference, not hard and fast rules.
Questions to ponder:
- How are engineers and designers similar? How are they different?
- How would you change the way you interact with your team?
- Was there anything that stood out to you, or was unexpected?
- Leading a team
- Working with designers
- Working with engineers
- On how to connect with others beyond surface level
- Experiment with at least one of the best practices suggested by the readings above and measure the impact over time.
PM is probably one of the most highly leveraged position at a company. You are constantly being pulled in different directions. One minute, you may be on customer support, the next you are gathering new requirements, until your engineers come to you with a blocking issue you must resolve. If you don’t have a systematic way to triage these requests, they can become overwhelming.
For me, I try to follow 3 simple rules:
- Everyday, have 1 thing I must get done. I don’t go home until either it’s done or until I’m blocked.
- Get in at least 1 hour ahead of my stand up to prep for my day. Those tasks may include answering emails, making sure requirements are in the system and all the tasks are up to date.
- Take a 15 minute break every 2 hours. Go for a walk, play some ping pong, stare into space. Whatever I do, just don’t think about work. I find that this really helps refresh my mind.
In terms of day to day prioritization, there’s not really any hard or fast rules, but I use these heuristics as prioritization guides:
- Putting out fire: This include blocking issues from engineering or production bugs that significantly disrupt business operations.
- Tasks that must be done within the next 2 weeks: These are generally requirements gathering tasks to ensure that design and requirements stay between 1 to 2 sprints ahead of development.
- Other tasks with more flexible timelines: These generally are my research tasks. I usually have a list of key questions I want to answer and I take time to knock those out 1 by 1.
Questions to ponder:
- What is your typical work day looks like?
- What are some of your biggest time sinks in a typical work day?
- How can you eliminate them?
- Maker’s schedule
- 7 things you need to stop doing to be more productive
- 5 ways to instantly become more productive
- Experiment at least 1 recommendation from the readings above and measure the result over time.
Below are some other resources that I found interesting, but didn’t really fit into any single categories. So I thought I would share it here.
- On learning how to learn – Coursera course on learning from UC San Diego
- How to read faster
- Other Great References
- PM Humor