pm 101
DESCRIPTION
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).TRANSCRIPT
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 company’s 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...
● Doesn’t 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 to3 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 you’ll have● Additionally, you’ll 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)● 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 product manager
Prioritization
What’s the best way to bucket ideas?
1. Customer requests
2. Metrics movers
3. Customer delight
Execution
● Implement what you’ve 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
Communication
● Over-communicate. As a rule. Always.● Status updates, progress reports, snippets, etc. rule.● Whether it’s email, phone, IM, messaging app, or just walking over to
your team, manager, etc., just do it.● Don’t 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 it’s 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 haven’t
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 you’re building. If you can’t 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 PM’s 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 TheorizeBuild
MocksUser
TestingStrategize
Finalize Design
Build TestBeta
RolloutMeasure Iterate
Write PRDEstimate
Resources
PrioritizeAllocate
ResourcesLaunch
The PRD Can Be A Powerful Tool
TeamTimelinesMetricsDeliverables/GoalsPlatform AvailabilityTargeted Problems
Product DescriptionPrimary Use CasesSecondary Use CasesEdge CasesMocks/DesignsCross-Device Functionality
Testing PlanGTM PlanChecklistDesign SpecEng SpecTracking Spec
PRD = Product Requirements Document
Methodology
Agile vs. waterfallDaily standupsSprint 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 problem2. Understand the best solution3. Write the code4. Test the code across platforms5. Launch and/or iterate on it6. 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 weeksXL = takes 1 engineer 2 weeks (1 sprint)L = takes 1 engineer 1 weekM = takes 1 engineer 3 daysS = takes 1 engineer 1 dayXS = 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 don’t measure it, you can’t improve it.● Make sure to include tracking of your most critical user actions.● Your eng team needs to either implement them manually or tag them
using an analytics tool such as GA, Mixpanel, etc.,● Verify that the tagging code is identical to the dashboard language
that you’re using.
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 and the metrics are moving in the right direction. If not, iterate on it. Do NOT move onto another project until you and your customers are happy -- otherwise, your effort in launching that product will have been a waste.
Time Management
PMs gain power via expertise and knowledge.You become the central point for addressing questions.
25%
Learning from your customers,
either directly via focus groups / interviews or indirectly via data analysis
25%
Formulating plans and
strategies on what to do next, writing up PRDs, designing mocks,
etc.
25%
Communicating, prioritizing,
testing, whiteboarding,
and making decisions with
your team
25%
Coordinating with other PMs, cross-functional teams, broader
organization, your users, your
partners, etc.
References
http://benhorowitz.files.wordpress.com/2010/05/good-product-manager.pdf
http://blog.adamnash.com/2011/12/16/be-a-great-product-leader/
Four Steps to the Epiphany by Steve Blank
The Checklist Manifesto by Atul Gawande