A risk in software development is that teams are so busy creating more and more features that they forget to reflect upon their business value while everyone knows that not every feature is a success. Some features may not be used at all or may even be disliked by users. As an industry, we have come to learn that product owners have a hard time predicting which features will be really liked by users and which will not. Even when using all of the feedback mechanisms discussed previously, predicting what users want is difficult.

Another important thing to recognize is that every feature in the product also brings a future cost. Every feature requires documentation, support, and maintenance. This means that unnecessary features are driving costs up as well. From this stance, it makes sense to not only leave non-value features but to even remove them from the product as soon as possible.

Hypothesis-driven development is a practice that starts with acknowledging that it is impossible to predict whether a feature will add value, add no value, or, even worse, decrease business value. Next, it recommends transforming features in the backlog into quick, lightweight experiments that are run in the product to determine whether a new feature adds value or not.

Such an experiment can be written in a similar shape as a user story, for example, like this: We believe that users want a new one-field popup to quickly create an appointment, instead of the full dialog. We are convinced that this is the case when we see that over 25% of appointments are created using this new dialog and that the average approval rate of appointments goes up by 2 points or more. The first part is called the hypothesis, and the second is the threshold for confirmation of that hypothesis.

Once this is written down, a minimal implementation of such a one-field popup is created and its usage and the usage of the original form are monitored using metrics. Depending on the measurements, one of the following can occur:

• The belief stated in the hypothesis is confirmed to be true and the new feature adds value. More stories surrounding this feature can be added to the backlog to increase the business value the product brings.
• The belief stated in the hypothesis is not confirmed and further experimentation is not expected to yield different results. The feature is dropped from the backlog and the current, minimal implementation might even be removed from the product.
• The belief stated in the hypothesis is not confirmed but experimentation continues. This can happen when there are numerous user complaints about a certain feature that the team is set on fixing. If one approach does not work, they might try another.

Using the approach outlined before, teams can increase the impact they make on business value by minimizing the time they spend on features that, after experimentation, do not add value and even remove them from the product again.

Often, hypothesis-driven development is combined with phased roll-out mechanisms such as feature flags or deployment rings. The experiment is then run on only a small percentage of the users, which makes it easier to pull the feature if it does not add enough value.

This completes the discussion of the means for gathering and using user feedback on applications and how user feedback ties into the DevOps goal of delivering business value to end users.