Why software will never be the same... Discuss why agile and lean development methodologies alone are not enough to compete in today's software startup market. Explore real-time prototyping and minimal viable experiments that can accelerate learning down to hours, not sprints.

1. THINK IN HOURS NOT SPRINTS
WHY SOFTWARE WILL NEVER BE THE SAME
1
Rob Meadows
CEO, Originate
Oct 21, 2013

2. We partner with start-ups and enterprises
to rapidly build high-quality modern software.
2

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
3

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

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

6. Cheaper, Faster, AND Better
Cloud +
Open Source +
Tools +
Methodologies
=
It has never been cheaper or faster
to build high-quality software
6

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

8. Open Source
Frameworks
Ruby/Rails, Scala/Play, Python/Django, etc.
User Interface
jQuery, Twitter Bootstrap, etc.
Data/Analytics
MySQL, MongoDB, Hadoop, etc.
Utilities
Security, integrations, testing, you name it…
8

9. Tools
Advanced tools help save time + risk:
Communication
Create more efficient (faster), global (cheaper) workforce
Skype, Hipchat, Webex, Pivotal Tracker, JIRA, Assembla
Analytics
Faster reaction to business needs with less risk
Google Analytics, Mixpanel, New Relic
UX/Prototyping
Omnigraffle, Popapp, Invisionapp, FluidUI
Dev/DevOps
Git(hub), Xcode, continuous integration, code quality, monitoring
9

10. Cloud + Open Source + Tools
So the odds must be in our favor now,
right?
10

11. Odds of New Startup Success
What is the success rate of software
startups today?
11

12. Odds of New Startup Success
<10%
12
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?
13

14. Once you Pivot in Market
<15%
14
Steve Blank “Startup Owner’s Manual”

15. Why Do They Fail?
?
15

16. Why Do They Fail?
They fail to create a product that people
need and will use
16

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

18. Better Methodologies
Identify and eliminate risks earlier in the cycle
Agile
Lean
Real-time Prototyping
18

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

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

21. Accelerate Learning
We can (and need to)
increase our rate of learning
by several orders of magnitude
21

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?
22

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

24. Learning is Not Failing
Experiments don’t fail. They create learning.
24

25. Minimal Viable Experiments
To get real insights, the medium
must be reality -not in our heads.
25

26. Paper Prototypes
26

27. Paper Flows
27

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
28

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
29

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
30

31. Manual Messaging
31

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
32

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

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 realworld
- Refine ideas and experiments; build second
prototype overnight
- Day 2: Test, refine, test, refine… in real world
- Hour 48: complete working prototype
34

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