The document outlines a comprehensive approach to startup product development, detailing the stages from idea validation through to deployment and iteration based on user feedback. Key factors include defining a product hypothesis, selecting the appropriate technology stack, and executing a minimal viable product (MVP) while preparing for post-launch assessments and adjustments. It emphasizes the importance of customer engagement and validation metrics to ensure the product meets market needs and can evolve over time.

1. Startup Product
Development
BY AARON STANNARD, CTO PETABRIDGE
HTTP://WWW.AARONSTANNARD.COM/

2. Agenda
 The Product Development Cycle
 Pre-launch
 Implementation
 Post-launch
 Why things fail

3. From Idea to Product

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. “We’re going to build a tool to
help large, .NET enterprises monitor
and manage commercial
deployments of distributed
systems”

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

10. Making a Landing Page
(YOU’LL BE DOING THIS OFTEN)

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

13. 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!)

14. BUILD

15. Picking an MVP

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

17. Technology Stacks (Client)
 Objective-C / Swift / Xcode (native iOS)
 Java / Eclipse (Android)
 .NET / Xamarin (native Android and iOS)
 JavaScript / Adobe Cordoba (RAD stack)

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

19. Build Costs

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

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

22. LAUNCHING

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

24. When the MVP takes too long….
 CUT features
 Communicate with your users; don’t let them
forget about you
 DON’T hire more engineers

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

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

27. Assessment

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

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

30. Questions?