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