32
PM 101 Prepared by: Zal Bilimoria

PM 101

Embed Size (px)

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

Citation preview

PM 101Prepared by: Zal Bilimoria

The Role of a Product Manager

Helps their teamship the right productto 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 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

The PM’s Framework

Quantitative Qualitative Collaborative

Your Own Gut

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.

Use Checklists

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