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!
Define a product hypothesis
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?
“We’re going to build a tool to
help large, .NET enterprises monitor
and manage commercial
deployments of distributed
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.
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)
Validate / Invalidate Hypothesis
How does it resonate with my personae?
Determine which parameters are optimal for first implementation
I.E. what’s my most profitable group of users and what will they pay for?
Figure out how to save as much time and money as possible
Refine product idea down to limited scope. MVP.
Factors in Selecting a Tech Stack
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?
Some stacks are “heavier” than others
Some are better late stage than earlier stage
Find a compromise and have a transition plan
Develop specification for an MVP
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
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
2 days = 3 weeks
2 weeks = 3 months
3 months = 4 years
4 years = pick a new MVP
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
When the MVP takes too long….
Communicate with your users; don’t let them
forget about you
DON’T hire more engineers
Your engineers must have a deployment process
Should be able to roll back to a previous version
of the product
Use a source control system
Use continuous integration (CI)
Always deploy your product before your
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
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
Qualitative feedback: what works and what doesn’t?
Break down by cohort.
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