1 / 18

Adventures in Product Development

Adventures in Product Development. Cory von Wallenstein VP, Product Management Dynamic Network Services Inc. December 7, 2009 – ECE 2799. Product Leadership: Creating and Launching Superior New Products – Robert G. Cooper Photo Credit: http://www.flickr.com/photos/idletype/526824467/.

burnsrobert
Download Presentation

Adventures in Product Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Adventures in Product Development Cory von Wallenstein VP, Product Management Dynamic Network Services Inc. December 7, 2009 – ECE 2799

  2. Product Leadership: Creating and Launching Superior New Products – Robert G. Cooper Photo Credit: http://www.flickr.com/photos/idletype/526824467/ “Truly Superior, Differentiated” Productshad an average 98% success rate and 53.5% market share. “Me-Too” Products averaged an 18.4% success rate and 11.6% market share.

  3. Overview • Relevancy • Before • Team selection • Understand requirements • Leave no question unanswerable • During • Testing • Importance of iteration • Keep it simple • After • Embrace failure • Accept responsibility

  4. Relevancy • Small companies: < 50 folks • Small budgets: ~ $1 million • Fast turnaround: 6 months or less • Corporate culture: • Aspire to be the best. • Never be outworked. • Welcome failure.

  5. Team Selection • No greater project impact. • No greater return on investment. • Individual differences: • Count on the best people outperforming the worst by about 10:1. • Count on the best performer being about 2.5 times better than the median performer. • Count on the half better-than-median performers outdoing the other half by more than 2:1. Source: Peopleware: Productive Projects and Teams; Demarco, Lister

  6. Understand Requirements • Alleviate pain, receive compensation. • Talk to your customers. • What are they paying for now? • Why should they pay you? • Listen. • Focus on a niche. Be the best in that niche. • Polarize.

  7. Leave No Question Unanswerable • Discover problems when they are cheap to fix. Source: Code Complete; McConnell

  8. Leave No Question Unanswerable • How does… ? • When should… ? • What happens if… ?

  9. Testing: Invert the Goal • Typical Goal: • Build a widget that measures light intensity. • Inverted Goal: • Build a widget tester that generates light of varying intensity, and can connect to a widget to verify the measured value of intensity. Oh, and along the way, we’ll have built a widget that measures light intensity. • Shocking fact: Roughly the same cost.

  10. Testing: Invert the Goal • Time typically used for: • “It was working yesterday…” • All-nighter debug sessions. • “When I touch this wire, it works…” • “It worked on batteries…” • “WTF?!?! Why isn’t it working?” • “We’re 95% complete.” • Real world: • “You know, everything would be fine if the stupid customers would stop breaking it.”

  11. Testing: Invert the Goal • Time is now used for: • Iteratively building a repeatable test suite and test harness. • Provides confidence that what you built yesterday, still works today. • Easy progress indicator… if there’s a passing test for it, it’s complete.

  12. Iterate, Don’t Waterfall • Waterfall model – Six week duration: • Weeks 1 and 2 – Spec out requirements for features A, B, C and D • Weeks 3 and 4 – Build features A, B, C and D • Weeks 5 and 6 – Testing and quality assurance for features A, B, C and D

  13. Iterate, Don’t Waterfall • Waterfall model – Nine week duration: • Weeks 1 and 2 – Spec out requirements for features A, B, C and D • Weeks 3 and 4 – Build features A, B, C and D • Weeks 5 and 6 – Testing and quality assurance for features A, B, C and D • Weeks 7 and 8 – Fix bugs found in features B and C. Feature D only works when not used with feature A. • Week 9 – Fixes break feature A. Fix feature A. Test.

  14. Iterate, Don’t Waterfall • Iterative model – Six week duration: • Weeks 1 and 2 – Spec out feature A. Build feature A. Work with Q & A to test feature A. • Weeks 3 and 4 – Spec out feature B. Build feature B. Work with Q & A to test features A and B. • Weeks 5 and 6 – Spec out feature C. Build feature C. Work with Q & A to test features A, B and C. • Deliverable product, albeit missing feature D, but it was low priority anyway.

  15. Simple as Possible, But No Simpler • Simpler products get built sooner. • Put into customers’ hands more quickly. • Feedback arrives earlier. • Market traction takes hold. • Use feedback to decide new priorities.

  16. Embrace Failure • Failure is an opportunity to learn from your mistakes. • Regrets turn into lessons. • Failure is different from negligence.

  17. Accept Responsibility • The only way to improve is to accept responsibility for what needs improvement. • Point criticism inward, before you point it outward. • More constructive, since it gives you something you can actually control. • “I’m sorry. I messed up. I’ll fix it.”

  18. Summary • Before • Team selection – Greatest indicator of success. • Understand requirements – Build the right thing. • Leave no question unanswerable – Save time and money. • During • Testing – It sure beats debugging. • Iterative development – You will be happier. Trust me. • Keep it simple – You can always add it in later. • After • Embrace failure – It’s an opportunity to improve. • Accept responsibility – Actionable criticism is good.

More Related