PM 101

16,051 views

Published on

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).

Published in: Technology
1 Comment
82 Likes
Statistics
Notes
No Downloads
Views
Total views
16,051
On SlideShare
0
From Embeds
0
Number of Embeds
978
Actions
Shares
0
Downloads
444
Comments
1
Likes
82
Embeds 0
No embeds

No notes for slide

PM 101

  1. 1. ZAL BILIMORIA Partner @a16z @zalzally PRODUCT MGMT 101
  2. 2.  Lucky enough to have spent 10 years as a PM at:  Partner on the investing team at Andreessen Horowitz: BRIEF INTRO
  3. 3.  Help your team  Ship the right product  To the right audience THE ROLE OF A PM
  4. 4. A good product manager…  Is the CEO of the product  Is the glue that fills the gaps within a team  Defines & manages the delivery of the product  Builds the right process to collaboratively decide on the correct priorities, making sure the entire team is onboard  Can articulate how exceeding the goals & metrics of their product would bolster the company’s overall strategy  Thinks about the story they want written by the press  Is constantly shipping new/improved products WHAT IS PRODUCT MGMT? Source: http://benhorowitz.files.wordpress.com/2010/05/good-product-manager.pdf
  5. 5. A bad product manager…  Doesn’t communicate enough w/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  Combines all problems into one  Never explains the obvious WHAT IS PRODUCT MGMT? Source: http://benhorowitz.files.wordpress.com/2010/05/good-product-manager.pdf
  6. 6. Being a PM can be reduced to 3 sets of responsibilities: Strategy Prioritization Execution RESPONSIBILITIES Source: http://blog.adamnash.com/2011/12/16/be-a-great-product-leader/
  7. 7. Strategy is generated from answering 2 questions:  What game are we playing?  How do we keep score? STRATEGY Source: http://blog.adamnash.com/2011/12/16/be-a-great-product-leader/
  8. 8. Comes down to defining the goals & how to measure them  Regularly engage with & learn from customers/stakeholders  Identify pain points & opportunities to make their lives better  Define the metrics that will make your product a success  Determine where the product needs to be in 6-12 months  Results:  1) aligned efforts  2) better motivation  3) innovative ideas  4) products that move the needle STRATEGY Source: http://blog.adamnash.com/2011/12/16/be-a-great-product-leader/
  9. 9. Ideas will come from everywhere, so you must prioritize  Prioritize projects based on metrics, time, & effort  The faster you & your team can make an impact by positively moving the metrics, the more leeway & credibility you’ll gain  Additionally, you’ll get a good grasp for how a successfully completed cycle of product development will look like  Launches build team-wide motivation  That’s why it’s best to get a few quick-n-easy wins under your belt if you’re just getting started as a PM PRIORITIZATION
  10. 10. What’s the best way to bucket ideas?  Supports the overall strategy  Metrics movers  User needs  User delight Quick note on bugs:  If it’s painful & more than ~10% of users complain about it, fix it fast.  Otherwise, prioritize it accordingly. PRIORITIZATION
  11. 11. Move fast, break things  Implement what you’ve learned, which is formalized in a PRD  Find edge cases & move through them quickly  The best PMs are the best QA people on a team  Once eng starts building the product, you can begin working on your next product in the queue, but remember that a v2 iteration of the current project will likely be required EXECUTION
  12. 12.  Over-communicates with all stakeholders  Regularly learns new things from users -- & teaches that to others on their team/organization  Takes & circulates detailed, action-oriented notes  Draws mocks, rough designs, or workflows when needed  Coordinates constantly with other PMs  Seeks buy-in for the overall direction from management SOME DAILY PM TASKS
  13. 13. Which products are winning today?  Simplest, easiest-to-use products Why is that?  Fatter pipes  Instant gratification  Supercomputer in your pocket SIMPLICITY
  14. 14. PM’S FRAMEWORK Quantitative Qualitative Collaborative Your Own Gut
  15. 15.  It’s about how well you really understand your users  How they work (“day in the life”)  How they use your product  When they use your product  Where they use your product  Why they use your product  Why they use your product, then stop using it  Why & when they recommend your product to others YOUR GUT WILL DEVELOP OVER TIME
  16. 16.  Over-communicate. As a rule. Always.  Status updates, progress reports, snippets, etc. – whatever works for your team  Whether it’s email, phone, IM, Slack, messaging app, or just walking over to a team member, just do it  Don’t forget to “manage up”: understand the goals of both your manager & their manager, & determine how best to communicate your team’s projects/progress with that in mind  Don’t make assumptions: verify. WRITE IT DOWN. COMMUNICATION
  17. 17.  Maybe not the typical 30 seconds, but 2 minutes  This will help you, your team, management, stakeholders, & all others who want to better understand what you’re building  If you can’t say it in 120s, go back to the drawing board  Physically write this down, word for word  Make it memorable YOUR ELEVATOR PITCH
  18. 18.  The clearer the PM’s mandate, the more successful the PM  PMs often encounter…  Too many barriers  Organizational silos  Vagueness on what they can and cannot do  Once ambiguity is reduced around deliverables or specific authority, team performance will improve THE MANDATE OF A PM
  19. 19. THE TYPICAL PRODUCT CYCLE Research Theorize Build Mocks User Testing Strategize Finalize Design Write PRD Estimate Resources Prioritize Allocate Resources Build Test Beta Rollout Measure Iterate Launch Iterate Launch
  20. 20. 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
  21. 21. WATERFALL VS. AGILE AGILE  Faster  Detailed enough to get started  Open to changes as new info is surfaced  Daily standups for 5- 15 minutes each  Rapid communication WATERFALL  Slower  Wait to start eng until everything is defined  Deep info silos between teams  Weekly team mtgs that last an hour  “It’s on the PRD”
  22. 22. EXPECTATIONS  Remember, even the smallest task can take time for an engineer to complete.  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?”  Consider the following – engineers need to…  Understand the problem  Find the best solution  Write the code  Test the code across platforms  Launch/iterate on it  All while suffering distractions & constant context switching
  23. 23. BUGS VS. NEW FEATURES  This is a constant balancing act  Generally speaking, the 80/20 rule is often a good one  80% of time spent on new features  20% on bugs  There will always be bugs, especially with edge cases  Many bugs are automagically squashed when new features are built  You never want to take your eye off your long-term goals
  24. 24. MEASURE!  If you don’t measure it, you can’t improve it  Make sure to track your most critical user actions  Your eng team will need to either implement them manually or tag them using an analytics tool such as Mixpanel, etc.  Verify that the tagging code is identical to the dashboard language that you’re using
  25. 25. DON’T BE A “WHAT’S NEXT” PM Once a product, major feature, or set of features is launched, validate that it’s working properly & the metrics are moving in the right direction, as expected. If not, iterate on it. Do not move onto another project until you & your users are happy – otherwise, your effort in launching that first product will have been a complete waste.
  26. 26. TIME MANAGEMENT 25% Learn from your users, either directly via focus groups or interviews, or indirectly via data analysis 25% Translate those learnings into a strategic plan on what to build by writing PRDs, drawing mocks, etc. 25% Day-to-day w/broader team on current/upcomi ng product launch, while constantly communicating expectations 25% Constant coordination w/other PMs, x-functional teams, & the broader org to find opportunities to collaborate PMs gain power via expertise & knowledge. You become the central point for addressing questions with respect to your product area.
  27. 27. USE CHECKLISTS
  28. 28.  Help your team  Ship the right product  To the right audience THE ROLE OF A PM
  29. 29. ZAL BILIMORIA Partner @a16z @zalzally Q&A

×