1

THINK IN HOURS NOT SPRINTS

WHY SOFTWARE WILL NEVER BE THE SAME

Rob MeadowsCEO, OriginateOct 21, 2013

2

We partner with start-ups and enterprises

to rapidly build high-quality modern software.

3

Quality Software is Essential to Almost Every Business

“Software is eating the world”

/ Marc Andreessen

“In 3 to 5 years, your car will have more lines of code in it than LinkedIn does today”

/ Reid Hoffman

4

Building Software

Classic Problem: Cheap, Fast, Good. Pick 2.

Fast + Cheap (but it doesn’t work)

or

Fast + Good (but you can’t afford it)

or

Cheap + Good (but you don’t live to see it)

5

Building Startup Software

Most competitive market landscape ever for software startups.

More technology options (noise) than ever for software startups.

Must be cheaper, faster, and better to win.

6

Cheaper, Faster, AND Better

Cloud +

Open Source +

Tools +

Methodologies

=

It has never been cheaper or faster

to build high-quality software

7

Cloud

Software as a Service (SaaS)Leverage quality 3rd party applications faster and cheaper

Salesforce, Google Apps, etc.

Platform as a Service (PaaS)Deploy and scale applications faster and cheaper

Heroku, Azure, Pivotal, etc.

Infrastructure as a Service (IaaS)Provision servers, storage, and bandwidth faster and cheaper

Amazon Web Services (AWS), Joyent, Rackspace, etc.

8

Open Source

FrameworksRuby/Rails, Scala/Play, Python/Django, etc.

User InterfacejQuery, Twitter Bootstrap, etc.

Data/AnalyticsMySQL, MongoDB, Hadoop, etc.

UtilitiesSecurity, integrations, testing, you name it…

9

Tools

Advanced tools help save time + risk:

CommunicationCreate more efficient (faster), global (cheaper) workforce

Skype, Hipchat, Webex, Pivotal Tracker, JIRA, Assembla

AnalyticsFaster reaction to business needs with less risk

Google Analytics, Mixpanel, New Relic

UX/PrototypingOmnigraffle, Popapp, Invisionapp, FluidUI

Dev/DevOpsGit(hub), Xcode, continuous integration, code quality, monitoring

10

Cloud + Open Source + Tools

So the odds must be in our favor now, right?

11

Odds of New Startup Success

What is the success rate of software startups today?

12

Odds of New Startup Success

<10%

Steve Blank “Startup Owner’s Manual”

13

Once you Pivot in Market

And what about if you can bounce back from a failure in market?

14

Once you Pivot in Market

<15%

Steve Blank “Startup Owner’s Manual”

15

Why Do They Fail?

?

16

Why Do They Fail?

They fail to create a product that people

need and will use

17

Avoiding Failure

Failure is usually catastrophic because there are no means to recover (money, time, expertise).

Therefore, we need to either fail faster or know more before starting.

We must identify and eliminate the risks around what users need and what they will use.

18

Better Methodologies

Identify and eliminate risks earlier in the cycle

Agile

Lean

Real-time Prototyping

19

Agile

Think in weeks.

Plan, build, test, repeat weekly;

Involve real users in testing;

Ability to pivot earlier

Learning happens in sprints/weekly. Not good enough (a week of quality work is not cheap).

20

Lean

Think in days.

Front-load learning; test before building when possible (Lean Canvas model).

Identify a problem, generate idea, de-risk it, build it, test it. Build Problem Solving Products (PSP).

Some learning happens daily, but most is weekly. Still not good enough (need fast + cheap + good).

21

Accelerate Learning

We can (and need to)

increase our rate of learning

by several orders of magnitude

22

Phases of Product Learning

Phase 1 (90%): Does it make sense? Does it feel right?

Ask: Real problem? Needs solution? What solution? Doable? Acceptable? Intuitive? Generalizable?

Learn: problem space, user expectations, solutions, UI approaches, modalities, ergonomics

Phase 2 (9%): Does it work with real data?

Phase 3 (1%): Does it work in real life?

23

Real-time Prototyping

Think in minutes.

“Minimal Viable Experiments”- a few minutes each;

Hundreds of experiments can be done before building any real software.

Learning happens several times per hour.

24

Learning is Not Failing

Experiments don’t fail. They create learning.

25

Minimal Viable Experiments

To get real insights, the medium must be reality --

not in our heads.

26

Paper Prototypes

27

Paper Flows

28

Paper Experiments

1. Draw the UI on stacks of index cards.

2. Let the user “click” somewhere.

3. Replace the card with another one that shows the new screen.

4. Observe if the user gets lost or has questions.

5. In the case of feedback, draw a new card in 10 seconds.

6. Results in ergonomic UI’s and workflows

29

Digital Prototypes

1. Convert paper prototypes into digital with tools like Popapp

2. Create digital mockups with tools like OmniGraffle

3. Test on real users

4. Incorporate feedback immediately

5. Use to build working software for specific features (in hours)

6. Test with real data

30

Manual Messaging

Use existing channels to “simulate” software interaction: email, text, IM, etc.

Use a human to act as server. Do NOT build software that a human can’t first do manually.

Test and adjust messaging and flow until it is intuitive to real users

31

Manual Messaging

32

Readme Experiment

1. Write the documentation first. Strictly no coding!

2. Show the documentation to real users

3. Ask them:If/how they would use it

What part of it they would not use

What value it would have to them

What else is missing

4. Change the documentation until it describes the perfect software

5. Use Agile/Lean to build PSP

33

And More MVE’s!

There are hundreds of experiments you can come up with for any software product.

Get creative and think outside the domain; start with experiments that don’t require coding.

Remember, there is no such thing as a failed experiment!

34

A 48 Hour Example

2 day immersive workshop with key stakeholders:

- Morning 1: Set real-world context (go do something)

- Fill whiteboard with problems and ideas

- Prove/disprove assumptions for each idea/solution through rapid experiments

- Build first working prototype by lunch and test in real-world

- Refine ideas and experiments; build second prototype overnight

- Day 2: Test, refine, test, refine… in real world

- Hour 48: complete working prototype

35

Recap

- You must be faster, cheaper, AND better to win the software game.

- This requires being agile and lean, but also creating real-time prototypes/experiments.

- Learning is not failing; push learning up-front where it is cheaper/faster.

- Start thinking in minutes: an hour is the new week.