This document outlines the three main roles of a product manager: executive, sales, and technical. As an executive, the product manager is responsible for defining the market and product lifecycle. In their sales role, they understand customer needs and turn needs into marketing messages. Technically, the product manager focuses on roadmaps and works with the product team. Throughout, an important focus is understanding the problem being solved for customers.

1. BOSSES, DEALS AND CODE MANAGING UP OUT AND IN
Jay Bourland
jay.bourland@gmail.com
http://www.linkedin.com/pub/jay-bourland/4/4/499

2. THREE ROLES OF A PRODUCT
MANAGER
Executive
Sales
Technical

3. EXECUTIVE
Defining a Market - “Is it real?”
Product lifecycle
Operational readiness

4. IT ALL STARTS WITH A
PROBLEM…
What problem are you solving?
Who has this problem?
Who are you selling to?
How many are there?
How much will they pay?
Why will they buy from you?

5. ACT YOUR AGE…
You have to know where you are in
the product’s lifecycle. The decisions
we make in the beginning are very
different from those of a mature
product.
http://www.chasminstitute.com

6. ALL OF THE RESPONSIBILITY,
NONE OF THE AUTHORITY
You need to own (or act like you own) your P&L
Can your organization build, deliver, sell and service the solution?
Do you understand the abilities of engineering, devops/delivery,
marketing, sales and pre-sales, finance, support, services, …?
Can you change them if you need to do so?

7. SALES
Understanding your customers’ needs - “Can we win?"
Turning needs into releases
Turning needs into marketing messages

8. RELIEVING PAIN
Your product is solving a pain point for your user
The critical question - “If there are two solutions to the problem,
how will the buyer decide which one is better?”

9. FEATURE QUADRANT
Differentiation
Plot each feature based on
importance to customer and
differentiation in market
Partner
Why
Bother?
Core
Parity
Importance
The upper right quadrant needs to
align with the core of your product
team
The lower right needs to be good
enough - any more is effort that could
be spent on stuff that matters
Find ways not to spend your precious
resources on the left side

10. A MORE RIGOROUS APPROACH
Interview several users/buyers of your
product (not just your customers)
FEATURE
Develop a set of features that strike a
common chord in the solution
description
A
9
8.5
9.5
B
8
5
11
Survey on the importance of the feature
and how satisfied the user is currently
Look for high importance + high gap
Watch out for high importance with
small or over-met satisfaction
IMPORTANCE SATISFACTION
PRIORITY

11. DON’T BE THESE GUYS

12. PLANNING A RELEASE
Lifecycle is critical
Market matters - understand the uncompromisable parts
You won’t really understand what the customers’ need until they
get it
Whatever you’re planning - it’s too much
A release starts the work - it doesn’t end it

13. TECHNICAL
Roadmaps matter - “Is it worth it?”
Bugs and features
Working with the product team

14. “Plans are worthless, but planning is everything”
– Dwight D. Eisenhower

15. IT’S NOT SHELF WARE (I HOPE)
One customer does not make a
market
Markets are made of single
customers
Turn your customers into
advocates
Be skeptical of buying-cycle bugs,
focus on your customers

16. EMPOWER YOUR TEAM
Engineering practice will tell you to
be available about 80% of the time
Market practice will tell you to
spend 50% of your time in the field
with customers and prospects
Managing all of the reporting will
probably eat another 20%
And then there’s sales, marketing,
support,…

17. PARTING ADVICE…

18. “Fall in love with the problem, not the product”
–Charlie O’Donnell
http://www.thisisgoingtobebig.com/blog/2012/7/12/fall-in-love-with-the-problem-not-the-product.html

19. REFERENCES
Crossing the Chasm - Geoffrey Moore
Dealing with Darwin - Geoffrey Moore
Setting the Table - Danny Meyer
What Customers Want - Anthony Ulwick
Stand Back and Deliver - Pixton, Nickolaisen, Little, McDonald
Is It Real? Can We Win? Is It Worth Doing?: Managing Risk and Reward in an
Innovation Portfolio - Harvard Business Review December, 2007 - George S Day