Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Startup Product Development

4,340 views

Published on

The product development cycle for startups - everything from coming up with an idea,to validating it, building it, launching it, and measuring how well the thing you built performed against your hypothesis!

  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Startup Product Development

  1. 1. Startup Product Development BY AARON STANNARD, CTO PETABRIDGE HTTP://WWW.AARONSTANNARD.COM/
  2. 2. Agenda  The Product Development Cycle  Pre-launch  Implementation  Post-launch  Why things fail
  3. 3. From Idea to Product
  4. 4. Idea Stage  Define a product hypothesis  Parameterize it: Who are the customers? What’s their case for action now? How are they going to buy? How are you delivering the product? How might all of these change over time?
  5. 5. “We’re going to build a tool to help large, .NET enterprises monitor and manage commercial deployments of distributed systems”
  6. 6. Parameters:  Customers: large, .NET enterprises (banks, healthcare, oil & gas, mining, gambling, insurance, retail, manufacturing)  Case for action: developers are expected to deliver more; don’t have tools or knowledge to do it (yet!)  How they buy: direct, inbound sales  Delivery: standalone installation; bundled with professional services  Change over time: annual subscription license; deliver updates and renewals to keep existing co’s happy. Expand sales through increase in deployments per account. Might add SaaS option to cloud environments. Maybe resellers.
  7. 7. Failure Conditions 1. No urgent case for action (idea is probably stupid) 2. No clear idea on how to deliver experience (can’t validate) 3. Unclear target persona (can’t target) 4. No vision (if idea can’t evolve, then it has no future)
  8. 8. Validation Goals  Validate / Invalidate Hypothesis  How does it resonate with my personae?  Quantify that.  Tune parameters  Determine which parameters are optimal for first implementation  I.E. what’s my most profitable group of users and what will they pay for?  Quantify that.  Figure out how to save as much time and money as possible  Refine product idea down to limited scope. MVP.
  9. 9. Tactics
  10. 10. Making a Landing Page (YOU’LL BE DOING THIS OFTEN)
  11. 11. Tools for Validation  Github Pages – static HTML, super fast, easy to host  Mailchimp – basic email tool  Drip – hard-core email tool  SumoMe – analytics + email capture  Optimizely – easy A/B testing
  12. 12. Validation Results  Best metrics translate most closely to revenue  Pre-orders (actual money)  Letters of intent (some will convert to future purchases)  List opt-in (I want this!!!111!)
  13. 13. BUILD
  14. 14. Picking an MVP
  15. 15. Technology Stacks (Web)  .NET / C# / Windows (Enterprise Stack)  Java / NoSQL / Linux (Big Data Stack)  Node.JS / JavaScript / Linux (RAD Stack)  Ruby on Rails / JavaScript / Linux (RAD Stack 2)
  16. 16. Technology Stacks (Client)  Objective-C / Swift / Xcode (native iOS)  Java / Eclipse (Android)  .NET / Xamarin (native Android and iOS)  JavaScript / Adobe Cordoba (RAD stack)
  17. 17. Factors in Selecting a Tech Stack  Labor availability  Who do you know who’s proficient with a particular stack?  Do you need to hire people in your local area?  How much do consultants and full-time laborers cost?  Infrastructure Requirements  Some stacks are “heavier” than others  Some are better late stage than earlier stage  Find a compromise and have a transition plan
  18. 18. Build Costs
  19. 19. The Process  Develop specification for an MVP  Wireframes  Workflows  Find engineers you can trust and gather estimates  Rough estimates initially  Pick engineers who suggest using off-the-shelf tools where appropriate  Develop a “workback” plan with engineers  Trust the engineer’s judgment on where they need to begin  Set milestones and concrete deliverables  Hit milestones until MVP is finished
  20. 20. Workback Plans  Break tasks down until they’re no larger than “half a day” in size  Total amount of work to hit milestone = sum of the parts  (This estimate will still be wrong)  General rule of thumb for work estimation: multiply the number of units of work by 1 and increase the unit of work by an order of magnitude  2 days = 3 weeks  2 weeks = 3 months  3 months = 4 years  4 years = pick a new MVP
  21. 21. LAUNCHING
  22. 22. Facts about your MVP  It will have bugs  It will have rough edges  If it doesn’t, you’ve waited too long  It will still impress customers if you’ve done your validation right
  23. 23. When the MVP takes too long….  CUT features  Communicate with your users; don’t let them forget about you  DON’T hire more engineers
  24. 24. Deployment  Your engineers must have a deployment process in-place  Should be able to roll back to a previous version of the product  Use a source control system  Use continuous integration (CI)
  25. 25. Launch Procedure  Always deploy your product before your marketing  Deploy the night before  Make sure it works  Postpone marketing materials if it doesn’t  Make sure your product is functional before you schedule major PR
  26. 26. Assessment
  27. 27. Quantify how well your MVP proved your hypothesis  Most important: be able to collect information about bugs and product failures  Product analytics: track key product metrics like unique users, user retention, recommendations, etc..  Conversions: how well does the product convert users to customers?  Qualitative feedback: what works and what doesn’t? Break down by cohort.
  28. 28. Starting the Cycle Again  Change delivery / product based on feedback  Have specific goals for next iteration in mind:  Improve user retention by X%  Improve conversion by X% or $N per month  Does this require a new feature?  Often, the answer is “no”  Most of the time it involves fixing something customers already use
  29. 29. Questions?

×