Product Management Or.. The most important thing most startups forget to do

Me I have a CS degree (and started life as a software engineer) I have run marketing I have run engineering I think like a product manager CTO/Co-Founder, Service Metrics (sold to Exodus) – VP Research, Exodus CTO in Residence, Mobius Venture Capital Venture Partner, Fidelity Ventures CTO/Co-Founder, Newmerix Have made 7 angel investments (2 sold, 2 profitable, 2 TBD, 1 dead) Helped open two bars/restaurants (Boulder/Boston)

My Philosophy I learned a long time ago to fall out of love with technology and fall in love with solving real customer problems I never need to have an original idea if I keep talking to my customer base I believe product development is a science not an art (although there are elegant parts of it) and it’s definitely not a crap shoot

Survey How many of you do active product management?

Product Management Rule #1 There is no wrong way or right way to do product management – you should do what gets you the result you want. So what is the result you want??

What is Product Management A process for delivering the right features at the right time Corollary: Product Management is NOT about extensive documentation!!

The Role of the Product Manager Sales Engineering Roadmap Competitors QA Customers/Users Visionary

Product Management Basics The primary job of the product manager is to clarify

Product Management Basics The secondary job of the product manager is to be the person who says “no” (and have good reasons for saying it)

Product Management Basics Everyone must write things down!

A Basic PM Process Sales Engineering Competitors QA Customers/Users Visionary Feature List Feature Review Broad Scoping Requirements Specifications Clarification of Requirements Clarification of Specs

Basic Documents Feature List – A loose list of all features that have been requested Overview – A document outlining briefly what features are in a release and their purpose to the release Requirements – A document listing all new requirements for the release – Old requirements are assumed unless changed Specs – A response to requirements with choices and consequences

How to Write A Good Requirement It’s easy – just finish this sentence, “The user should be able to…”

How to Respond With a Good Spec It’s easy, just finish the sentence, “The user can do X by..”.. and then list all the exceptions As a side note, a specification is well written when a QA person can figure out how to definitively test if a feature is working or not.

The PM/Engineering Clarity Continuum Specificity/Clarity Feature A Feature B Feature C Feature D Feature E Feature F Feature G Spec A Spec B Spec C Spec D Spec E Spec F Spec G Concept

My Secret Tip: The Feature Review 1.Demonstrate each requirement 2.Clarify any changes needed 3.Clarify any differences accepted 4.Release feature to QA

I Know What You’re Thinking, But.. Don’t tell me you do agile development so your short time boxes alleviate you from having to do formal product management Don’t tell me that product management is something you do when you’re a bigger company and have more product complexity Don’t tell me you do product management as a group (if you’re not comfortable giving one person the reigns then you don’t know what you’re building) Don’t say you’re climbing a mountain one step at a time – you’re assuming you’ve picked the right mountain

Remember… Its take 30 seconds to write a requirement It takes 2 minutes to clarify it in discussion It takes 5 minutes to write the specification It takes hours to prototype, write code, integrate and test it Where in the process would you like to discover a communication issue?

Top Reasons Why PM Fails 1.Some team members think they don’t need it 2.The process and documents are not designed by the whole team 3.Teams don’t evolve the process over time 4.Too much documentation is created (and thus has to be updated) 5.The PM does not balance short and long term priorities 6.The PM doesn’t have the cajones (or good data) to say “no” 7.Engineers get lazy and argue their time is better spent coding or prototype and not writing anything down 8.Teams get lazy and skip steps (e.g. Feature Review) 9.The PM starts dictating design and architecture 10.People don’t empower the PM with the authority they need

How to Pick a Product Manager – Engineering background/interest (this is not required but can be helpful to call BS) – Someone who listens – Someone who debates – Someone who can think big picture and at the same time can handle incredible detail – Someone who likes to be in the field (talking to people about what you’re doing) – Someone who can defend their decisions and does not mind having to disappoint some people every once and a while

Top Mistakes PMs Make They insist on too much documentation They think everyone will just follow the process so they don’t ride herd on everyone They don’t know how to say “no” They allow the process to move forward without fully completing each gate They have no clue the complexity they are asking for They make choices without talking to their constituencies and letting those discussions drive their choices

IMHO The Product Manager should be the most empowered employee in your company!! - Yes, even more than the CEO -

Closing Thoughts I have worked with a lot of startup companies now (my own, others, as a board member, investor, etc…) and the #1 thing IMHO opinion that goes wrong is that there is poor product management. You cannot hire the right team if you don’t know what you are building

Founder Teams – Key Personalities Team Building Product Management (Strong Operational Experience in Key Area)