Product Management

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

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

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

4. Survey How many of you do active product management?

5. 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??

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

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

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

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

10. Product Management Basics Everyone must write things down!

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

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

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

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

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

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

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

18. 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?

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

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

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

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

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

24. Founder Teams – Key Personalities