Assumption-driven development: hypothesis writing

THINK: assumptions and hypothesis

Instead of expressing “requirements,” we consider assumptions and declare hypothesis statements. A hypothesis statement is a way of expressing assumptions in a testable form.

Reality often shows that the creators of a product or service are not sure what a user needs or wants or how it should work concerning the user experience. But quite often, organizations or companies proceed with their idea for functionality or user experience without the input what the user needs (or what the user thinks about it) and without checking (testing) with the end-user throughout the development process.

Quite frankly, organizations that have been in business for many years (decades) think (with some level of arrogance) to know what the customer wants and how the experience should be – but this arrogance will bounce back with failure: an unhappy end-user will trash the product and its experience if it deemed to be unfit.

Hypothesis statement

A hypothesis statement will require experiments to determine right or wrong assumptions.

The first step is to list any assumptions: an assumption is a declaration of what we assume to be true. But it’s not a requirement until we have facts and figures to support it. Assumptions comprehend both business and user assumptions. A possible way to list assumptions is to start with a problem statement. Problem statements are complete with beliefs. When assumptions are listed, selecting the most uncertain ones is crucial.

The main principle of Lean Startup is to expose the highest risk first to learn. The whole team should do the exercise of listing assumptions and hypotheses with the entire team: everyone involved so that you can create a shared understanding from the start.

A hypothesis statement has the following format:


Note: This is a possible format; there’s no obligation to follow this mindlessly as long you understand the purpose and have the different elements.

Outcomes (objectives) and metrics

It is essential to focus on outcomes first: what are we trying to achieve, and what objectives? What kind of user needs? Instead of directly thinking about features (solutions), we focus on outcomes. When creating the product, the progress will be measured against the outcomes. To measure, you need to define a set of metrics. An excellent approach to this is Objective-Key-Results.

Features (functionalities, stories, …)

Features exist to serve the needs that have been identified. You create a particular feature (solution, functionality, story). It’s essential to define the outcome first and think about possible features.

User assumptions

It is essential to know something about the customer, the end-user for whom you’re creating the product. Personas are a well-known technique to make the end-user visible.

The clue is to approach the creation and validation of personas the lean way: personas are not the output of great research upfront but are created and evolve as the product evolves. Personas made with lots of work upfront and not updated afterward are essentially throw-away personas: they become useless as soon as they are outdated and are a source of waste.

We prefer to create “ad-hoc” or “proto“-personas representing the best guess of who uses the product and why. A proto-persona contains the information (demographics, behaviors, and needs) of a specific type or segment of end-user relevant to the product being designed.


Lean UX book

Materials in this post are based upon readings on the Lean UX approach.

Lean UX (Jeff Gothelf)
Lean UX (Jeff Gothelf)

Lean UX book by Jeff Gothelf.

Read more about the Lean UX cycle.

Read more about the Lean UX book.

Objective Key-Results

In any context, objectives (or outcomes) are essential as they give guidance or direction instead of focusing on solutions.

(Solutions in the broad meaning: a product or service, an improvement, a feature, a functionality, …)

We want to track progress concerning objectives, not only solutions. Quite often, solutions are proposed or defined without an objective in mind. Multiple solutions are possible to reach a specific objective.

When teams are given an objective, they can think about possible solutions and which fit best in the current environment (system, product, service, etc.). In general, teams who own part of the problem statement and the solution space are more motivated, focused, and creative as they feel ownership.

Objective Key Results
Objective Key Results

OKRs = Objectives + Key Results

It is a method of defining and tracking objectives and their outcomes.

  • Objectives are what the organization or individual wants to accomplish, typically subjective and qualitative. Objectives can be ambitious can be challenging.
  • Key results are concrete, specific, and measurable. They describe how you will accomplish the related objective and measure whether you achieved it.

The clue is that Objectives and Key Results can be defined on several levels in the organization: for example, executive management, departments, products or services, and teams.

How Google sets goals