Despite decades of process improvement, most companies still fail in new product development. Studies show success rates hover around 50%, not because of bad ideas, but because teams use outdated, execution-driven methods. Experiment-Driven Development (EDD) applies scientific thinking to innovation, helping teams test assumptions early, reduce uncertainty, and systematically improve their odds of success.
In areas with high degrees of certainty like typical core operations, success comes from repeatable execution. Day-to-day business is driven by processes that are developed, optimised, and sometimes even automated. However, developing a new product or service requires different approaches as the exact steps required to reach success are not knowable in advance. That uncertainty hides business-critical risks, where your committed resources are at risk of not delivering success.
Each unanswered question carries a portion of this risk, for example:
“Are enough customers facing this problem?”
“Which of these 10 ideas is needed most urgently?”
“Will regulation in this space loosen, tighten, or remain constant in the next 5 years?”
Each answer you validate reduces uncertainty and de-risks your investment, and that’s where Experiment-Driven Development comes in.
EDD and the scientific approach is structured like this:
Consider the various critical questions for your new product: These questions can be derived from your business model canvas (see BMC article), or from your existing product development framework (see Stage-Gate portfolio management). The idea is that each question should cover a different aspect of the business that the new product will introduce.
Develop an informed hypothesis to answer each critical question: From these questions, use desktop studies, common sense, and experience from multiple team members to develop loosely informed answers to each of these questions. These answers start as assumptions but can then be reworded into hypotheses that can be tested and turned into validated answers.
Design & execute an experiment to collect evidence that will support your hypothesis: Each hypothesis requires qualitative, quantitative, or mixed evidence to support it. Design an experiment where you aim to test the hypothesis and determine what real-world conditions are required for the hypothesis to be true, and how reality responds to your critical question. In essence, you are trying to perform small, scaled-down tests of the types of challenges your product will face once launched.
Analyse & review the evidence: Collect your data and analyse it to notice trends, patterns, outliers, exceptions, and rules. Compare these findings to your hypothesis and determine whether your answer/assumption/hypothesis is true or not.
Translate the evidence into a learning (even if the hypothesis is rejected): Whether your hypothesis is confirmed or rejected, each experiment should yield a valuable learning through the validated data you’ve collected. These learnings accumulate into confidence, and that guides the next steps.
Drive progress through learnings: Each experiment reduces uncertainty at a minimal cost. If your hypothesis is rejected, the loss is contained to cost of the experiment, which prevents larger, costlier mistakes later. If validated, move to the next question until all your critical questions are sufficiently answered. This is how modern teams turn uncertainty into measurable progress.
Reworking your product development process can be a tough & cumbersome challenge. However, there are ways to gain some of the benefits immediately. Start by considering your list of existing assumptions (or by creating a list of assumptions using the business model canvas). From there, pick your highest priority or riskiest assumptions and consider some hypotheses for them. Think about the kinds of evidence that would be most compelling in proving that the assumption is correct. Then, design a small experiment to test each of these. The experiment can be anything from a back-of-the-envelope calculation to a survey of potential customers, to a Proof-of-Concept for a small element of your product. If you do not have established & repeatable product development processes, then start small with informal assumptions & lightweight experiments (see use maturity to set targets)
For teams looking to formalise their innovation practices and measure what truly matters, our upcoming Innovation Measurement Workshop explores how to embed EDD principles into your product development system. Click here to learn more and claim your seat.
