Startup Product DevelopmentBY AARON STANNARD, CTO PETABRIDGE

HTTP://WWW.AARONSTANNARD.COM/

Agenda

The Product Development CyclePre-launch ImplementationPost-launchWhy things fail

From Idea to Product

ProductCycle

Ideas

ValidateBuild

Launch

Assess

Idea Stage

Define a product hypothesisParameterize 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?

“We’re going to build a tool to help large, .NET enterprises monitor and manage commercial deployments of distributed systems”

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.

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)

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.

TacticsValidation Tactics

B2C

Pre-Orders

B2B

Interviews

Professional Services

Landing Pages

List Building

Surveys

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

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

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

BUILD

Picking an MVP

LOW CUSTOMER VALUE HIGH CUSTOMER VALUE

LO

W B

UIL

D C

OS

TH

IGH

BU

ILD

CO

ST

SweetSpot

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)

Technology Stacks (Client)

Objective-C / Swift / Xcode (native iOS)

Java / Eclipse (Android)

.NET / Xamarin (native Android and iOS)

JavaScript / Adobe Cordoba (RAD stack)

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

Build CostsCosts Associated with Building MVP

Other

Developer time

Designer time

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

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

LAUNCHING

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

When the MVP takes too long….

CUT features

Communicate with your users; don’t let them forget about you

DON’T hire more engineers

Deployment

Your engineers must have a deployment process in-place

Should be able to roll back to a previous version of the productUse a source control systemUse continuous integration (CI)

Launch Procedure

Always deploy your product before your marketingDeploy the night beforeMake sure it worksPostpone marketing materials if it doesn’t

Make sure your product is functional before you schedule major PR

Assessment

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.

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

Questions?