Product Strategy Pre and Post Launch

Ever had a brilliant app or startup idea? Something you just knew would be an instant hit. You start building. You're the master of your own universe. You launch with an early version – the minimum desirable experience, but you still have plenty of work to do to get the product where it needs to be. You start getting users, great! But naturally, they begin sending you feedback and suggestions for improvement. This is where the challenge is. How do you compromise between your own vision for the product and what your users are asking for? In this talk, Iarfhlaith will share his experiences balancing a planned product roadmap with the continuous flow of user requests. See what tools and techniques are available to help negotiate you through this common issue.

Transcript

1. PHP Dublin – April 16th, 2014. Product strategies, before and after launch.
2. We make sports science software • Reduces injuries and increases athlete availability. • Measures the stresses and stress responses imposed on an athlete. • Base on published scientific research. • Uses statistical analysis and machine learning to generate injury risk alerts.
3. The roadmap to launch December 2012 - July 2013
5. Prototyping December 2012 - February 2013
6. “Success is not delivering a feature; success is learning how to solve a customer’s problem.” Scott Cook – Founder, Intuit.
7. Building the Prototype in 3 months, part time • Git via Beanstalk • Bootstrap (2.3.2) • Highcharts • CodeIgniter • Static app • One controller, lots of views • Hosted on simple VPS • Convincing demo – still used today • Straight to code • Domain expert • Ongoing feedback • Very successful
8. Your technology doesn’t have to be cutting edge. But your product does. Don’t get caught up in bleeding edge tech. It’s called that for a reason. Lesson #1
9. Feedback February 2013 - March 2013
10. Customer feedback confirming our suspicions • Went on the road for feedback • Elite Rugby & Pro Soccer • Calculations • Association Access • GPS Integration • Medical Injury Reports • Video Distribution • Lots of different opinions!
11. No matter how good your product is everyone has an opinion. Product vision is essential. Lesson #2
12. Faking it works. You can give great demos with simple prototypes. Lesson #3
14. Product Development April 2013 - June 2013
15. “If you are not embarrassed by the first version of your product, you’ve launched too late.” Reid Hoffman – Founder, LinkedIn.
16. Product Development • Limited resources. Just 1.5 developers (we were also fundraising). • Immovable deadline, flexible scope. • Focused on what was most important. • Leveraged existing code and libraries. • Lots of decisions. Lots of dropped features. • The product was full of compromises.
17. CodeIgniter – Supercharged • Carabiner – asset management • Pigeon – better routing • DataMapper – Object Relational Mapper • Composer & Sparks – extra libraries • Phinx – database migrations • Extended Jamie Rumbelow’s My_Controller
18. 3rd Party Services • Amazon AWS (S3, EC2, Route53, SES) • Sentry – event and error tracking • Sifter – issue tracking • Intercom – messaging & communication • Woopra – real time customer analytics • Trello / Basecamp / Evernote – Undecided!
19. July 1st – Launch day Pre-season Day 1
21. Life is pretty easy without customers. Profiler was launched on time the night before our deadline. Lesson #4
22. Launch the essentials. Leave the rest. We even launched without alerts! Lesson #5
23. Post-Launch Chaos • More feedback than we could handle • More bugs than we expected • Constant feature requests • Planned product roadmap affected • Lots of firefighting, late nights, and early mornings.
24. Be ready for feedback. Know how to handle it. Have your feedback channels up and running. Lesson #6
25. Three types of feedback #1 Newly Discovered Bugs Urgently fixed #2 Feature Votes Helped priorities #3 New Feature Requests Product vision is key
26. Launching early is embarrassing and stressful. ! But it’s the best way to build a great product. Lesson #7
27. Feedback – by the numbers 134 Feature Requests 222 Sifter Bugs 17k Sentry Events
28. ! Don’t break a live app. Take your time. Be careful. ! Lesson #8 Bugfixing is important, but not at the expense of the existing app.
29. ! Assign a bug fixer and a feature developer. ! It’s almost impossible for one person to do both. Lesson #9 What’s urgent is hard to ignore. Bugs are always urgent and always present.
30. Two tracks Response Team bug fixing minor feature requests configuration database cleansing Roadmap Team Planned feature rollouts R&D projects major feature requests Infrastructure / architecture
32. Handling Feature Requests
33. “Be stubborn on vision, but flexible on details.” Jeff Bezos, Amazon CEO.
34. “If you don’t have any facts, we’ll just use my opinion.” Jim Barksdale, former CEO of Netscape If it’s not verified, then it’s their opinion versus ours. This is why scientific verification is so important for us.
35. Feature Request Sense Check • Is it scientifically verified? Avoiding our opinion versus theirs. • Will it reduce injuries / increase availability / improve performance? • Will it either reduce the friction in gathering the data or improve how the information is interpreted? • Yes? yes? yes? Okay – Let’s build it.
36. ! Product vision will guide you. ! Make sure you have one. ! It helps you decide what to build and what not to build. Lesson #10
37. Summary – 10 Lessons on launching product • Avoid bleeding edge technology. • Everyone has an opinion. • Faking it works. • Life is easy without customers. • Launch only the essentials. • Be ready for lots of feedback. • Launching early is hard. Do it anyway. • Don’t break a live app. • Split bugfixing and feature development. • Product vision will guide you.
38. Building something meaningful keeps you motivated. When it gets hard, remember you’re solving a big problem. It’s worth it. Bonus Tip
39. Thanks PHP Dublin and Engine Yard.
40. @iarfhlaith ik@kitmanlabs.com Any questions?