2012 feb 25 agile ux nyc, seiden, requirements to hypotheses

Replacing
Requirements
with Hypotheses

AgileUX NYC 2012
Feb 25, 2012
Josh Seiden
@jseiden

Me and my hashtags

Josh Seiden
www.proof-nyc.com
@jseiden
@proof_nyc

#leanUX
#leanStartup

www.proof-nyc.com License: Creative Commons Attribution-
www.slideshare.net/jseiden
2 Share Alike 3.0 United States

Internet Mouse

www.proof-nyc.com
3 License: Creative Commons Attribution-
Share Alike 3.0 United States

What are we talking about?
Requirements and hypotheses can both be
used to frame the work of teams.

- Example of a requirement: create an
Internet Mouse that people can use when
surﬁng the internet on their TV from their
couch.
- Hypothesis: we believe that people will pay
for a device that makes it easier and
more fun to surf the internet from their
living room couches in front of the TV.
www.proof-nyc.com

For many teams, in many
contexts, hypotheses are a
more effective way to
manage your work than
requirements.

5

Extreme uncertainty

www.proof-nyc.com

The problem with requirements
The business owners express needs as
“requirements.”

Problem: the team has no visibility to user/market
need.

Problem: “The business” does the
thinking, the design/dev team
does the implementing.


Requirements vs. hypotheses

When you’re in production, building to a
known standard, you want requirements.

When you’re in an environment of uncertainty,
you want hypotheses.


Why are hypotheses more effective?

They are understood to be only provisionally
true: in other words, they express
assumptions that need to be tested.

Hypotheses are answers put forth in the spirit
of a question.


On questions...

“We get wise by asking questions, and even if
these questions are not answered we get
wise, for a well-packed question carries its
answer on it’s back as a snail carries its
shell.”

James Stephens, The Boyhood of Fionn


Wisdom? Who cares?

“Working software is the primary measure of
progress.”

“Validated learning is the primary measure of
progress.”


Reduce Inventory, Risk and Waste

Make a Get
design feedback
decision from market

Concept credit: @clevergirl



This is
going to be
BIG!

Make a Get
design feedback




This is No one
going to be clicked.
BIG!

Make a Get
design feedback




This is No one
BIG!

Make a Get
design 3 MONTHS feedback




This is No one
BIG!

Make a Get
design 3 MONTHS feedback

3 HOURS


Less risk, more often

The old
way...

The new
way!



What is a hypothesis?

An hypothesis is a proposed explanation of
the way things work.


What is a Hypothesis?

We believe that ________________.

...and:

We’ll know that we’re right when we see this
signal: ______________.


What is a Hypothesis?

We believe that people will pay for a device that
makes it easier and more fun to surf the internet
from their living room couches.

...and:

We’ll know that we’re right when
1. People use our mockups without trouble.
2. People offer to pay when we offer to leave the
mockups with them.

Process

Replace requirements with hypotheses by:

1. Identifying assumptions
2. Expressing assumptions as hypotheses
3. Test the riskiest assumptions ﬁrst
4. Break your hypotheses down into testable parts
5. Use MVP concept to test your hypothesis
6. Get out of the building
7. Lather, rinse, and repeat


Method: Declare your assumptions

www.slideshare.net/jseiden Share Alike 3.0 United States


What assumptions do you have?



…about your customers?



…about your customers?
…that if proven false, will cause you to fail?


Method: probe deeply for assumptions
Who is the user? Who is the customer?
Where does our product ﬁt in their work or life?
What problems does our product solve?
When and how is our product used?
What features are important?
How should our product look and behave?
How will we make money?


Test your riskiest assumptions ﬁrst

high risk

known unknown

low risk


Method: Write the test ﬁrst

We believe that ______________.

We will know we have succeeded when qualitative and
quantitative outcome. This will improve KPI.


Method: Minimum Viable Product



What is the smallest thing we can make to test
our hypothesis?



What is the smallest thing we can make to test
our hypothesis?

The answer to this question is your MVP.


Case study: recent client

A web service that you plug in to your
commerce site
Provides a set of features to end users
Merchant gains insight because the widget
generates metrics


Case study: recent client

The problem: they had a feature backlog, and
were not sure how to prioritize what to work
on next.


Case study: identifying assumptions

To deal with “requirements” we built a story
map


Case study: identifying risk


Case study: the biggest risk

Do our customers
value our offering
enough to pay for
it?


The value hypothesis

We believe that our customers value our
offering because:
1. Our widget adds a valuable feature to their pages.
2. Our widget generates trafﬁc for them. Free offering

3. Our widget generates sales for them.

4. Our widget generates valuable data. Paid offering


Case study: ﬁnd the riskiest assumptions

1. Customers will value our high risk
widget’s basic functionality
enough to choose it over the 1
free competitors. 2

2. Customers will value our
analytics enough to upgrade
known unknown
to the paid version of our
product.

low risk


Startup Metrics for Pirates

Awareness Learns about our product

Installation Installs widget on site

Values analytics enough
Purchase
to upgrade to premium

Doesn’t cancel after
Repurchase
30-day trial

Refers
Referral Friends

www.slideshare.net/jseiden 36 Share Alike 3.0 United States

We believe that if we show
Awareness Debbie how important [our
Learns about our product functionality] is she will give
us her email address.

Installation Installs widget on site

Purchase

Repurchase
30-day trial

Refers
Referral Friends



We believe that our free offering
Installation Installs widget on site is strong enough that she will
install us over our competitor.

Purchase

Repurchase
30-day trial

Refers
Referral Friends




Values analytics enough We believe that Debbie will value our
Purchase analytics enough to pay for this level of
service.

Repurchase
30-day trial

Refers
Referral Friends


Hypothesis: activation/installation



Hypothesis: Our customers will value our free widget
enough to install it.



Sub-hypothesis: they will install the free widget only if
the installation process is easy enough.



Sub-hypothesis: they will install the free widget only if
the installation process is easy enough.

Problem: the installation process is too hard for our
customer. It is preventing us from measuring
customer behavior.


Experiment one: will they install it?


Experiment one: will they install it?

vs. Install with one click...


Requirement vs Hypothesis


Requirement: build an installer



Hypothesis: Our customers will value our free widget enough
to install it.



to install it.
Sub-hypothesis: they will install the free widget only if the
installation process is easy enough.



to install it.
Sub-hypothesis: they will install the free widget only if the
installation process is easy enough.

MVP: build a page that supports a concierge installer.


The next hypothesis...


Values analytics enough We believe that Debbie will value our
Purchase analytics enough to pay for this level of
service.

Repurchase
30-day trial

Refers
Referral Friends


Experiment 2: do they value analytics?
Requirement: build an analytics dashboard

Hypothesis: Our customers will value our analytics dashboard
enough to pay for it.
We’ll know we’ve succeeded when 6 customers respond to
our mockups by signing Letters of Intent.

MVP: Mockup of analytics dashboard.


Hypotheses win...


Hypotheses win...
A way to re-frame requirements


Hypotheses win...
 Every decision you make about your offering is a design decision.


Hypotheses win...
 Every design decision is an hypothesis.


Hypotheses win...
 Declare your assumptions and test them.


Hypotheses win...
 Declare your assumptions and test them.
 Entire team engaged in the feedback loop


Enjoy what you saw? Follow @jseiden and @proof_nyc.

THANK YOU!


2012 feb 25 agile ux nyc, seiden, requirements to hypotheses

More Related Content

Viewers also liked

Similar to 2012 feb 25 agile ux nyc, seiden, requirements to hypotheses

Recently uploaded

2012 feb 25 agile ux nyc, seiden, requirements to hypotheses

Editor's Notes