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

1. ZAL
BILIMORIA
Partner @a16z
@zalzally
PRODUCT MGMT 101

2.  Lucky enough to have spent 10 years as a PM at:
 Partner on the investing team at Andreessen Horowitz:
BRIEF INTRO

3.  Help your team
 Ship the right product
 To the right audience
THE ROLE OF A PM

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. 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. 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. 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. 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. 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. 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. 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.  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. Which products are winning today?
 Simplest, easiest-to-use products
Why is that?
 Fatter pipes
 Instant gratification
 Supercomputer in your pocket
SIMPLICITY

14. PM’S FRAMEWORK
Quantitative Qualitative Collaborative
Your Own Gut

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.  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.  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.  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. 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. 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. 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. 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. 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. 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. 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. 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. USE CHECKLISTS

28.  Help your team
 Ship the right product
 To the right audience
THE ROLE OF A PM

29. ZAL
BILIMORIA
Partner @a16z
@zalzally
Q&A