Advertisement
Advertisement

More Related Content

Similar to Couples Counseling for Product Development(20)

Advertisement

Recently uploaded(20)

Couples Counseling for Product Development

  1. Couples Counseling for Software Development Joe Stump, CEO of Sprint.ly
  2. • Early employee at three startups ranging from bootstrapped to venture funded. • Angel investor in three startups. • Advisor to seven venture funded startups. • Cofounder of three venture funded startups (SimpleGeo, attachments.me, & Sprint.ly).
  3. “The best products in the world start out as features.” Kevin Systrom, CEO of Instagram
  4. Warring Factions
  5. Check Your Ego
  6. EVERYONE IN YOUR COMPANY IS CAPABLE OF HAVING A GREAT IDEA.
  7. Managers
  8. Quickly Correctly Cheaply
  9. YOU CAN’T HAVE YOUR WINE CASK FULL AND YOUR WIFE DRUNK.
  10. “Want to increase innovation? Lower the cost of failure.” Joi Ito
  11. ALLOW ENGINEERS TO INVEST IN AUTOMATION & TESTING.
  12. Why? • Iterating on your product is all about shortening feedback loops • Continuous deployment allows you to ship on code commit • Automated testing allows for aggressive refactoring with confidence
  13. Makers
  14. “You should get a CS degree. It's the only degree that automatically makes you an expert on politics, finance, religion, and economics.” @thejayfields
  15. YOU ARE NOT AN EXPERT IN SALES, MARKETING, NOR BUSINESS DEVELOPMENT.
  16. A Sampling of Non- Technical Product TODOs • Financial model creation for pricing • Messaging • Documentation • Customer development • Copywriting • Screencasts & Videos • Marketing plan for launch • Marketing materials • Public relations • Capturing requirements • Support • Business development • Community development • Funnel analysis • Sales training • Market research • Managing beta testers • Blog announcement • Contract negotiation • Newsletter announcement
  17. SIMPLEGEO’S PRODUCT LAUNCH CHECKLIST HAD 41 NON-ENGINEERING ITEMS ON IT.
  18. YOU ARE NOT A DESIGNER. (SERIOUSLY. JUST LOOK AT THAT SHIT.)
  19. YOU ARE NOT THE TARGET CUSTOMER. (NO, REALLY, NOBODY CARES ABOUT KEYBOARD SHORTCUTS.)
  20. “Focus on the problem. If you’re only excited about the solution, you’ll lose interest when your solution doesn’t fix the problem. ” Adil Wali, CTO of ModCloth
  21. Delivering Product
  22. Implementing vision takes time Inception Your brain Funding v1.0
  23. “If you’re not embarrassed when you ship your first version you waited too long.” Reid Hoffman, Founder of LinkedIn
  24. Product is Trench Warfare
  25. BE MILITANT IN YOUR MINIMALLY VIABLE PRODUCT (MVP).
  26. Approaching Product 1. Focus on a single use case that addresses the problem 2. Start with a minimal core set of features 3. Release and listen to your users 4. Question your initial assumptions based on feedback 5. Rinse and repeat
  27. Iterating on Your Product 1. Have a great idea 2. Wireframe in Balsamiq (or whatever) 3. Designer creates a static mockup 4. Static mockup is thrown “over the wall” to engineering to implement
  28. Seriously?
  29. Oh, whoops. • Turns out static mockups are ... static • Engineers implement it only to find out the UX is terrible • Engineering is unable to implement critical features
  30. INVOLVE ENGINEERING IN THE PRODUCT DESIGN PROCESS.
  31. Why would I do that? • Nobody knows your data better than your engineers • You likely aren’t an expert at data algorithms • They are your company’s best technologists
  32. Iterating the Yardsale Way™ 1. Have a great idea 2. Wireframe in Balsamiq (or whatever) 3. Engage engineering to build a vanilla prototype (e.g. Default Bootstrap or iOS/Android UI components) 4. Play, tweak, rinse, repeat 5. Once UX is nailed have a designer polish to perfection
  33. Promote Ownership Yay!
  34. Why is this better? • Designer’s time is not lost on features that are not shippable • Timelines will not be disrupted by unforeseen technical hurdles • Avoids pissing off the engineers
  35. Process Interrupts
  36. PRODUCTS ARE EITHER DATE- DRIVEN OR FEATURE-DRIVEN.
  37. Non-Blocking Development (NBD) 1. No sprints, milestones, or dates are tracked by engineering 2. Items are scored, velocity is tracked 3. Each developer works on an item to completion in a feature branch 4. Pull request via GitHub for review 5. Feature deployed immediately upon approval via continuous deployment
  38. Why is this better? • Shares reactive qualities of Kanban • Velocity metrics allow you to do reasonable capacity planning • Features ship in real-time as they’re completed
  39. “You can’t ship process.” VP of Product, Live Nation Labs
  40. @joestump
Advertisement