product management_spark_finalonline

Product Management 101How to Build and Deliver Great Products

ANAND SUBRAMANI

LAURA MARINO

STVP SPARK

SPRING 2015

STVP - Stanford Technology Ventures Program

Agenda

What is Product Management?

Product Lifecycle

Phases of the Product Lifecycle

Product Management – Other Considerations

Working with other groups

Other responsibilities

Paths to PM and Important Skills

Q&A

What is Product Management?

I thought it was this

Product Management Venn

Diagram

As a Product Manager you are:

a) Responsible for defining success

b) Responsible for getting the product built

c) Responsible for delivering that product to market

d) The person responsible for the full product lifecycle

e) The CEO of the product

The Product Lifecycle

You come up

with a great idea

for a productYou guide the

team to build the

product

Your customers love it!

PM - How hard can it be?

There is a little more to it …

Identify Market/ Vision

Evaluate Opportunity

Design Solution

Build it

Deliver ‘Whole Product’

Measure

Retire


Typically this has

been defined by the

CEO/executives



Design Solution

Build it


Measure

Retire


What problem are

you trying to solve,

and is it important?



Design Solution

Build it


Measure

Retire


How should

you solve the

problem?



Design Solution

Build it


Measure

Retire

You think you know

what to build. Let’s

build it




Design Solution

Build it


Measure

Retire

Do you have all the

pieces needed to

make a customer

successful?




Design Solution

Build it


Measure

Retire


Did what you

shipped solve

the problem?



Design Solution

Build it


Measure

Retire


Learn and Iterate

quickly and deliver

a new release

There should be iteration

and validation in each step

Opportunity Evaluation

Opportunity Evaluation

I have an idea…

Assess Opportunity

Design

Build


Measure

Where do ideas come from?

You

Executives

Customers

Sales and marketing

Product team

Customer service representatives

Operations staff

Industry analysts

Competitors

Competitor’s customers

Customers’ customers

Assess Opportunity

Design

Build


Measure

What’s the difference between an

idea and an opportunity?

An opportunity is an idea that has been validated to be both good for the user and good for the company

Guy Kawasaki on product development

Assess Opportunity

Design

Build


Measure

http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1176

How do you validate that something

is “good”

Separate the “problem space” and the “solution

space.”

An idea usually tangles up the problem you’re

trying to solve and how to solve it. Avoid this at all

costs.

Get outside the building and talk to your users.

When they ask for something, figure out why.

Assess Opportunity

Design

Build


Measure

Tips and tricks

Make sure whatever you build has impact. Avoid optimization early

on and go for global maxima.

This step is often mistaken for prioritizing feature requests.

Information should come as much as possible from outside your

company. No product survives a collision with reality unscathed.

Very important to define what you aren’t solving.

Assess Opportunity

Design

Build


Measure

Design the Solution

Design the Solution(How should we solve the problem?)

Moving from the Problem Space to the Solution Space

Minimum Viable Product

User Personas (and Buyer Personas)

User Experience Design

Early Validation

Assess Opportunity

Design

Build


Measure

From Problem to Solution

Problem/ Need Solution

Manage Client

Obligations



Manage Client

Obligations

Manual +

Excel

Terms of

Business

How people

solve it today

The new

product



Manage Client

Obligations

Centralize

Get visibility into

commitments

Enforce across

business

Manual +

Excel

Terms of

Business

Master DB,

Document Upload

Categorization & modeling of

individual commitments

Reporting

API’s for integration

Next level

of detail



Manage Client

Obligations

Centralize

Get visibility into

commitments

Enforce across

business

Manual +

Excel

Terms of

Business

Master DB,

Document Upload



Reporting


Review

pre-signing

Approval

Notifications

Review

Workflow

Approval

Workflow

The scope

of the

problem

can be

broader …

… needing

a broader

solution

Key Risk # 1

You are not able to limit the scope of the problem you are solving in v1



Manage Client

Obligations

Centralize

Get visibility into

commitments

Enforce across

business

Manual +

Excel

Terms of

Business

Master DB,

Document Upload



Reporting


Notifications

Review

pre-signing

Approval

Review

Workflow

NLP

‘Deep’

integration

Automated

Diff

Analytics

Approval

Workflow

There are

always more

features to solve

the problem

better…

Key Risk #2

You try to put every possible feature in v1

“Minimum viable product: version of a new

product which allows a team to collect the

maximum amount of validated learning about

customers with the least effort."

Prioritize based on

Importance and

Customer Value

Must Haves / Basic product

Nice to Have/ Differentiators

Strategic / Delighters

(Customer specific)

Customer Satisfaction

Delight

Frustration

Investment

Low

High

Must Haves

(Basic expectations)

Performance

Delighters

(Excitement

Generators)

Kano Model

Once you have defined the functionality you

should be able to articulate:

Value Proposition

What are the customer benefits you are delivering?

Competitive Differentiation

Why are you better than the competition/

alternative?

User Personas

“Fictional characters, built to identify

real users’ needs, wants and

limitations in order to design best

possible experience for them”.

Goals: set a common understanding of the final

user(s) and put all stakeholders into the user’s shoes

Product should have the minimum number of

personas

Exercise: Identifying User Personas

B2C B2B B2B2C

App to plan, record,

track athletic activity

(Strava)

Solution to increase

efficiency of the sales

force

(Salesforce.com)

Customer experience

management solution

to gather and analyze

customer feedback

Who are the buyer personas?

User Experience Design

Source: Dan Olsen Consulting

How information is

organized, and how

each page is organized

How user navigates

across pages; how

user enters input

How it looks

What’s a “good” design?

Convey necessary information with the least amount of mental overhead

Identify the “necessary information”

What do you want someone to understand?

If they understand everything, the design is doing it’s job.

Now ask if there’s a simpler way to convey the same information

Removes some subjectivity from design

Early Validation

(Getting customer feedback early)

Feedback on:

Functionality/ Feature set

UI/UX Design

Value Proposition and Messaging

Early Validation

Hand Sketch

Increasing

fidelity and

Interactivity

Wireframes

Mock-ups

Prototypes

You should be able to do a lot of

validation before writing any code!

Build It

Assess Opportunity

Design

Build


Measure

BuildWe think we know what to build. Let’s build it

For much of software, “building to spec” is an obsolete idea

Waterfall development and Gantt charts often don’t work well

Notable exceptions like Microsoft Windows

Building to learn and validate key risks increases your

chance of shipping something good

The ‘Traditional’ Waterfall Model

Challenges

• Assumes perfect understanding of the

product requirements at the outset

• No feedback loops

• Does not adapt to changes

Source: http://agilemethodology.org/

Iterative Methodologies

• Loops are designed to

quickly validate key

hypothesis

• Focus is on speed of

validated learning

Source: http://agilemethodology.org/

Common Building Stages

What are the common stages of building/shipping and

why do they exist?

Alpha

Alpha = friendly people you know

Friends, family, power users who write in, etc.

You won’t get good signal on certain things from these people

Tendency to pay for example will be highly skewed

Beta

Beta = self selecting but anonymous people

People who are willing to tolerate some rough edges but

product should be feature complete and as “final” as possible

Iterations and polish should get progressively smaller over time

What kind of signal can you get from beta?

General Availability (GA)

End goal for most projects

Any customer can use your product/feature

Often done in percentage rollouts (1%, 5%)

Be careful of your takeaways from percentage rollouts

GA behavior is what you were trying to validate in all of

the prior steps


Assess Opportunity

Design

Build


Measure

What do we mean with

‘Whole Product’?

Distribution

3rd-Party Add-ons

Installation

Configuration

Integration

Training

Support

Your

(Generic)

Product

Everything else the

customer needs in order

to achieve their

compelling reason to buy

‘Whole Product’ can change based on the stage in the

adoption lifecycle

Whole Product - critical for competitive advantage

The generic product may evolve to incorporate more of

the Whole Product

‘Whole Product’ Launch Checklist

Product Readiness • Functionality

• Quality

• Documentation


Product Readiness

Pricing and Positioning • Price

• Packaging

• Positioning Statement


Product Readiness

Pricing and Positioning

Services and Support Readiness

• Training

• Documentation

• Services Offers

• SLA’s


Product Readiness



Partner Readiness • Partner Agreements

• Training


Product Readiness



Partner Readiness

Operations Readiness

• Sales Operations

• Dev Ops (Cloud)


Product Readiness



Partner Readiness


Sales Readiness

• Sales Training

• Collateral

• Demos


Product Readiness



Partner Readiness


Sales Readiness

Marketing Readiness • Communications & PR

• Mktng Campaigns

• …..


Product Readiness



Partner Readiness


Sales Readiness

Marketing Readiness

You don’t have

to do it all

yourself …

But you need

to make sure it

gets done

Measure

Assess Opportunity

Design

Build


Measure

MeasureDid what we released solve the problem?

Use qualitative and quantitative data

Know the questions you’d like to answer

ahead of time

Understand the impact on the business

Don’t do things on accident

Measurement will inform your next release



Design Solution

Build it


Measure

Retire

Iterate …

Iterate quickly and

deliver a new

release

Product Management

Other Considerations

Operations

Support

Sales

Partners

Interacting with other functional

teams

Engineering

Design

Marketing

Product

Marketing

Services

Executive

Team

Product

Management

PM vs PMM, Design and Engineering

Market Definition

Opportunity

Validation

Competitive

Landscape

User Personas

Feature

Prioritization

Mockups /

Design

Positioning

Roadmap

GTM PlanMarketing

Programs

Prod Owner Role

(Agile)

Technical Training

Documentation

Sales Support

Technology

Assessment

CollateralPricing

Partner Strategy

Ou

tbo

un

dIn

bo

un

d

Strategic Execution

Requirements

PM vs PMM, Design and Engineering

Market Definition

Opportunity

Validation

Competitive

Landscape

User Personas

Feature

Prioritization

Mockups /

Design

Positioning

Roadmap

GTM PlanMarketing

Programs

Prod Owner Role

(Agile)

Technical Training

Documentation

Sales Support

Technology

Assessment

CollateralPricing

Partner Strategy

Ou

tbo

un

dIn

bo

un

d

Strategic Execution

Requirements

PM

PMM

Design

Engineering

Product Management vs Product Marketing Roles

Titles in the industry are confusing, but focus is typically:

Areas of overlap

• understanding market problems

• defining positioning and pricing

• supporting sales

Product Marketing Managers

Go-to-Market activities

Product Managers

Business and Technical activities

Outbound (Business) PM Inbound (Technical) PM

Where do Product Management and Product

Marketing Report into?

30%

24%16%

9%

4%

3%

2% 12%

Reporting Dept

Product Management

President/ CEO

Marketing

Engineering

Product Marketing

Sales

Services or Support

Other

*Pragmatic Marketing Survey 2013 - 1,800 respondents

What else do you get to do as a PM?

Build vs Buy

Technology Partnerships

Managing a portfolio of products

Strategy

So you want to be a Product

Manager?

Important skills

Typical paths to PM

Characteristics of Good Product

Managers*

Personal Traits

Product Passion

Customer Empathy

Intelligence

Work Ethic

Integrity

Confidence

Communication Skills

Knowledge

Know your Customer

Know your Product

Know your Competitors

Skills

Applying Technology

Focus

Time Management

Written Skills

Presentation Skills

Business Skills

Attitude

No Excuses

Defining Success

Nothing Sacred

*Martin Cagan, Behind Every Good Product: The Role of Product Manager

Resources

Martin Cagan, The Role of Product Manager http://www.svpg.com/assets/Files/productmanager.pdf

Ben Horowitz, David Weiden: Good Product Manager, Bad Product Manager http://www.khoslaventures.com/wp-content/uploads/Good_Product_Manager_Bad_Product_Manager_KV.pdf

Kano Model: http://www.uie.com/articles/kano_model/

Clean Up Your Mess (A Guide to Visual Design for Everyone) http://visualmess.com/index.html

Geoffrey Moore, Crossing the Chasm

Tom Kosnik, Lena Rumsfeld, Gear Up: Test Your Business Model Potential and Plan Your Path to Success

Agile Methodology: http://agilemethodology.org/

Pragmatic Marketing www.pragmaticmarketing.com

Olsen Solutions: http://olsensolutions.com/

http://www.svpg.com/assets/Files/productmanager.pdf

http://www.khoslaventures.com/wp-content/uploads/Good_Product_Manager_Bad_Product_Manager_KV.pdf

http://www.uie.com/articles/kano_model/

http://visualmess.com/index.html

http://agilemethodology.org/

http://www.pragmaticmarketing.com/

http://olsensolutions.com/

Contact Information

ANAND SUBRAMANI

[email protected]

www.linkedin.com/in/aasubramani/en

LAURA MARINO

[email protected]

www.linkedin.com/pub/laura-marino/0/214/23/en

mailto:[email protected]

http://www.linkedin.com/in/aasubramani/en

mailto:[email protected]

http://www.linkedin.com/pub/laura-marino/0/214/23/en

product management_spark_finalonline

Documents

product measure

product lifecycle phases

product development

product manager

product lifecycle e

opportunity design build

opportunity design solution

product built c responsible