Difference Between a Hypothesis and an Assumption

Written by Sean Murphy. Posted in 1 Idea Stage, 2 Open for Business Stage, 3 Early Customer Stage

Q: What are the key hypotheses you need to address first getting your startup off the ground? What is the difference between a hypothesis and an assumption?

When you are looking for early customers the value hypothesis is critical. You may reach them using non-scalable methods that don’t address your first real growth hypothesis.

My take on the distinction between hypothesis and assumption, your mileage may vary:

A hypothesis is what is being tested explicitly by an experiment. An assumption is tested implicitly. By making your assumptions as well as your hypotheses explicit you increase the clarity of your approach and the chance for learning.

The two things that can trip you up most often is an unconscious assumption that masks a problem with your hypothesis or an unconscious bias in who you are testing the value hypothesis on. In particular you may have defined your target customer by certain selection criteria but your actual choices for who to speak to (or who will speak with you) are not sampling from the full spectrum of possibilities.

See also


Update Wed-Jan-29-2014: Tim Allen left a great comment that elaborated on the need to focus on value first even if your methods don’t scale:

There was a bit of a light-bulb moment for me what I read the line:

“When you are looking for early customers the value hypothesis is critical. You may reach them using non-scalable methods that don’t address your first real growth hypothesis.”

I feel this is so often forgotten, especially in the situation of legacy systems and trying to execute lean product design within larger organizations. One example that I have been involved in, and which I regret not pushing back harder, was a requirement to use some legacy data services.

This meant that we couldn’t initially execute a hand-cranked, non-scalable solution to data storage and retrieval that our product required, which would have been better as it would have enabled us to get to customer quicker and get real learnings about how they are using our product.

At the time it didn’t seem like a big deal, but in the end it was, and continues to be an issue and an impediment in getting to the customer quicker. Likewise, any real growth hypothesis, results will most likely be skewed by the performance of systems that are not in your control.

I want to thank Tim for offering a practical story that elaborates on the principle of confirm the value before worrying about scaling. When I was at Cisco the focus was always on “will it scale,” as in we shouldn’t do something because “it won’t scale.” This sometimes led to us releasing a product that could have been more valuable if we had proceeded a little more thoughtfully and incorporated early feedback before rushing to launch. Techniques that work “in the small” to gather insight have their place even inside of large firms.

Trackback from your site.

Comments (4)

  • Terry Schmidt

    |

    How refreshing to find your insights! Behind every strategy or project design is a set of hypotheses, usually not made explicit. We can use if-then causal thinking to link objectives together in relationship to each other with if-then logic “if we build it, they will come”.

    My life work has been using the Logical Framework Approach, a systems thinking and project design methodology based on hypotheses and assumptions. Featured in book “Strategic Project Management Made Simple”, and video http://youtu.be/IX09_y4O1aI

    Thanks Sean for bringing strategic management principles to your readers — what you shared is fundamental to success but seldom explored.

    Reply

  • Tim Allan

    |

    There was a bit of a light-bulb moment for me what I read the line:

    “When you are looking for early customers the value hypothesis is critical. You may reach them using non-scalable methods that don’t address your first real growth hypothesis.”

    I feel this is so often forgotten, especially in the situation of legacy systems and trying to execute lean product design within larger organisations. One example that I have been involved in, and which I regret not pushing back harder, was a requirement to use some legacy data services.

    This meant that we couldn’t initially execute a hand-cranked, non-scalable solution to data storage and retrieval that our product required, which would have been better as it would have enabled us to get to customer quicker and get real learnings about how they are using our product.

    At the time it didn’t seem like a big deal, but in the end it was, and continues to be an issue and an impediment in getting to the customer quicker. Likewise, any real growth hypothesis, results will most likely be skewed by the performance of systems that are not in your control.

    Reply

  • SKMurphy, Inc. » Quotes for Entrepreneurs–January 2014

    |

    […] “A hypothesis is what is being tested explicitly by an experiment. An assumption is tested implicitly. By making your assumptions as well as your hypotheses explicit you increase the clarity of your approach and the chance for learning.” Sean Murphy in “Difference Between a Hypothesis and an Assumption“ […]

    Reply

Leave a comment

Quick Links

Bootstrappers Breakfast Link Startup Stages Clients In the News Upcoming Events Office Hours Button