Breaking New Ground: Ditch Requirements

In an environment of "knowns," where standards exist, we can talk about requirements. Where we are facing the unknown--new territory--where no standards exist, there are no requirements so we think and act in terms of assumptions or hypotheses.

Hypotheses are proposed answers formulated as questions.... Assumptions held as provisionally true until proven (tested). Put another way, hypotheses are proposals that explain how things might work. Whether we build radically new, ground-breaking technology or start radically new, ground-breaking business ventures, our work is primarily based on hypothesis and their validation, not on meeting requirements.

Hypothesis are validated by testing. Hypothesis and validation are inseparable. Constantly testing hypotheses, adapting to the results, formulating new hypothesis, testing again, and so on is the routine.

The process is iterative. Progress is also incremental (results appear in stages). All progress is real progress; tested, validated, proven.

Validated learning is the basis for measuring progress.

"We believe ____________ (hypothesis)," is always paired with:

"We know ____________ (hypothesis) is right when we see ________ (tangible result).

There is an alternative validation approach: Proof that the hypothesis is incorrect. In some cases, this may be a better (quicker, cheaper) approach.

"We know ____________ (hypothesis) is wrong when we see ________ (tangible result).

Either way, there is some tangible result from testing--evidence of validated learning. In the case of technology, positive results may mean working code or a functional prototype. For a new business, positive results may mean sales or funding. Negative results may mean avoiding a long, costly run down a blind alley. Validated learning, in either event, is the means by which we understand, track, and measure our progress.

A working method for this approach might look something like this:

1. Discover (identify and document) assumptions
2. Formulate assumptions as hypotheses
3. Determine validation criteria (qualitative and quantitative) based on the smallest thing that can be done or built to test
4. Prioritize hypotheses for validation based on risk (more unknown = higher risk)
5. Start validation of higher risk items first (high risk = high priority)
6. Validate, test, acquire feedback
7. Rinse and repeat

When in new territory, every design decision (or business decision) is a hypothesis. Know the assumptions, state them clearly, share them; test and validate. Build continuous testing and continuous feedback within your team.

Understanding that we work with hypothesis leads to better management of process and outcome.

Posted by: William W. (Woody) Williams

Subscribe