In this episode, you’ll discover how to use hypotheses and experiments to identify the right solutions that meet customer needs.


After listening to this episode, you'll understand:

  • Why traditional approaches often lead to the wrong solution
  • How to use hypotheses and experiments to discover the right solution
  • How to craft experiments that are testable


One of the biggest problems that we face today is that we’re often given a solution to implement.  Unfortunately, that solution doesn’t always meet customer needs and results in shelfware; a product that customers won’t use.

Instead of making assumptions and building an untested product, we can use the scientific method to discover the right solution for our customers.

Experiment Driven Development is a more mature way of thinking about Agile methods.  Traditionally in Agile, we use a backlog comprised mainly of User Stories.  With Experiment Driven Development, you may still have User Stories, but that’s not where we start.  Even with Agile methods, it’s entirely possible to build the wrong product.

Using a scientific approach to discovering the right product for our customers allows us to ensure we’re delivering valuable solutions.

Instead of starting with a User Story or epic, we start with a hypothesis.  From there, the work items become experiments to prove or disprove the hypothesis.  This frames solution development in the “plan, do, check, act” model and allows us to quickly validate solutions and avoid waste.


To use Experiment Driven Development, follow these three steps:

  1. Start your development with a testable hypothesis
  2. For your highest priority hypothesis, identify the smallest experiment(s) that will prove or disprove it
  3. Run the experiments

This approach allows you to get rapid feedback and decide whether to pivot in a new direction or persevere on your current path.


Nordstrom Innovation Lab video:


Listen to the full episode to understand why Experiement Driven Development is so powerful and how to start using this approach.




For your next feature, instead of documenting that feature in a traditional way, define it as a hypothesis and perhaps a few small experiments that could validate the hypothesis.


 Links mentioned in this episode:

Mike Hall

Mike Hall

Senior Agile Coach/Trainer at Agile Velocity

Mike Hall is an Enterprise Agile Coach/Trainer with 16 years of Agile transformation experience. In addition to holding 10 patents issued by the US Patent Office, he has practical experience in leading enterprise scaled Agile transformations for all types of organizations (including startups) and speaks at industry comferences.


Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.Subscribe on iTunes  Listen on Google Play Music  Available on Stitcher Radio  Subscribe on Android