PM 101

  • View

  • Download

Embed Size (px)


Some basic principles for being a great product manager. It should be a good primer for new PMs as well as a good refresher for existing PMs. This is a compilation of 10 years of working as a PM and consuming dozens of blog posts over the years about being a great PM. Special props go to Ben Horowitz, Adam Nash, and Hunter Walk. Note: as always, these are my own thoughts (not of a16z's).

Text of PM 101

  • PM 101 Prepared by: Zal Bilimoria
  • The Role of a Product Manager Helps their team ship the right product to the right audience
  • What Is Product Management? A good product manager is the CEO of the product is the glue that fills the gaps within a team defines and manages the delivery of the what (not how) builds the right process to collaboratively decide on the right priorities, making sure the entire team is onboard can articulate how exceeding the goals and metrics of their product would bolster the companys overall strategy thinks about the story they want written by the press is constantly shipping new and/or improved products
  • What Is Product Management? A bad product manager... Doesnt communicate enough with team & stakeholders Misunderstands and/or assumes user goals & desires Puts out fires all day vs. leveraging their knowledge Makes excuses for not shipping the right product Constantly wants to be told what to do Lets engineering build what they want Combines all problems into one Never explains the obvious
  • How Google Defines PM The Product Management team works closely with our engineers to guide products from conception to launch, and with our business partners to generate profitable streams. As part of the Product Management team, you bridge technical and business worlds as you design technologies with creative and prolific engineers and then zoom out to lead matrix teams such as Sales, Marketing and Finance, to name a few. You have a bias for action and can break down complex problems into steps that drive product development at Google speed. As a Product Manager, you can be part of shaping Google's next game-changer. Through your leadership, you'll leverage your technical expertise to identify setbacks and roadblocks within a project and generate solutions for resolving them quickly, build and manage a product team to recruit the best-suited engineers, and evaluate feedback from support teams to identify product errors and gaps. You'll also work closely with senior Googlers in support of your product.
  • Responsibilities Being a PM can be reduced to 3 sets of responsibilities: 1) Strategy 2) Prioritization 3) Execution
  • Strategy Strategy is generated from answering two questions: 1) What game are we playing? 2) How do we keep score?
  • Strategy Comes down to defining the goals and how to measure those goals Regularly engage with and learn from customers and stakeholders Identify pain points and opportunities to make their lives better Define the metrics that will make your product a success Overall, determine where the product needs to be in 6-12 months Results: 1) aligned effort, 2) better motivation, 3) innovative ideas, and 4) products that move the needle
  • Prioritization Ideas will seemingly come from everywhere As a PM, prioritize projects based on metrics, time, and effort PMs are geared toward making an impact and shipping products The faster you and your team can make an impact (positively move the metrics), the more leeway and credibility youll have Additionally, youll get a good grasp for how a full cycle of product development will look like Also, launches build team-wide motivation (move fast, break things) Thats why its best to get a few quick-n-easy wins under your belt if youre just getting started as a product manager
  • Prioritization Whats the best way to bucket ideas? 1. Customer requests 2. Metrics movers 3. Customer delight
  • Execution Implement what youve learned, which is formalized in a PRD Find edge cases and move through them quickly The best PMs are the best QA people on a team Once engineering starts building the product, work on the next product, but remember that a v2 iteration of the current project might be required
  • Some Daily Task Examples Over-communicates with all stakeholders Regularly learns new things from users -- and teaches that to others Takes and circulates detailed and action-oriented notes Draws mocks, rough designs, or workflows for a future product Coordinates constantly with other product managers Seeks buy-in for the overall direction from management
  • Simplicity Which products are winning today? The simplest and easiest-to-use products Why is that? 1) Fatter pipes 2) Instant gratification 3) Supercomputer in your pocket
  • The PMs Framework Quantitative Qualitative Collaborative Your Own Gut
  • Communication Over-communicate. As a rule. Always. Status updates, progress reports, snippets, etc. rule. Whether its email, phone, IM, messaging app, or just walking over to your team, manager, etc., just do it. Dont make assumptions: verify. Write it down and verify.
  • Single POC For your product and features, everyone should know (including other PMs) that those are your responsibility. You are the single point of contact and own it end to end. Having multiple PMs on the same product can spell disaster.
  • How Do You Prioritize? Metrics: which features will positively impact metrics? Bugs: if its painful and more than 10% of users complain about it, fix it fast. Otherwise, put it in a queue. Strategy: stack rank and prioritize against strategy, data, metrics, bugs, user feedback, and your gut.
  • Your Gut Will Develop Over Time Part of it is really understanding your users. Understanding how they work How they use your product When they use your product Where they use your product Why they use your product Borrow my copy of the Four Steps to the Epiphany if you havent read it yet. Every founder and PM should read it.
  • Your Elevator Pitch Maybe not 30 seconds, but 2 minutes This will help you, your working team, your users, and all others who want to understand what youre building. If you cant say it in 120 seconds, go back to the drawing board. Physically write this down, word for word. It will help. Trust me. And certainly edit/improve it.
  • The Mandate of a PM The clearer the PMs mandate, the more successful the PM. PMs often encounter 1. Too many barriers 2. Organizational silos 3. Vagueness on what they can do and cannot do Once ambiguity is reduced around deliverables or specific authority, performance will improve for the entire team.
  • The Typical Product Cycle Research Theorize Build Mocks User Testing Strategize Finalize Design Build Test Beta Rollout Measure Iterate Write PRD Estimate Resources Prioritize Allocate Resources Launch
  • The PRD Can Be A Powerful Tool Team Timelines Metrics Deliverables/Goals Platform Availability Targeted Problems Product Description Primary Use Cases Secondary Use Cases Edge Cases Mocks/Designs Cross-Device Functionality Testing Plan GTM Plan Checklist Design Spec Eng Spec Tracking Spec PRD = Product Requirements Document
  • Methodology Agile vs. waterfall Daily standups Sprint planning Tools (GANTT, Asana, Trello, Spreadsheets)
  • Stories Stories: As a user, I want to be able to do X. Then, break it down into elements. Have your eng team (or you) identify the specific work items. Build a working prototype is not specific enough. Plug in SFDC API in order to surface name metadata is better.
  • Expectations Even the smallest task can take time for an engineer to complete. Consider the following: engineers need to... 1. Understand the problem 2. Understand the best solution 3. Write the code 4. Test the code across platforms 5. Launch and/or iterate on it 6. All while suffering distractions and constant context switching The questions that all engineers hate when PMs ask them: How easy would it be to do X? How long would it take to do Y?
  • T-Shirt Sizing Assumption: 1 sprint = 2 weeks XL = takes 1 engineer 2 weeks (1 sprint) L = takes 1 engineer 1 week M = takes 1 engineer 3 days S = takes 1 engineer 1 day XS = takes 1 engineer 4 hours
  • Bugs vs. Brand-New Features This is a constant balancing act. Very generally, I try to follow the 80/20 rule for a few reasons, where 80% of my time is spent on new features and 20% on bugs: 1. There will always be bugs, especially with edge cases 2. Many bugs are automagically squashed when new features are added 3. You never want to take your eye off the longer-term goals
  • Measure! If you dont measure i