Options not Obligations

tl;dr

We want to provide our consumers and business partners options as opposed to obliging them by providing only one option.  By “Designing in options” for your business partners and consumers, you provide them with the ability to take the greater risk while minimising the impact of failure for them.  Feeling they have ‘nothing to lose’ (or at least the consequences are significantly lower) in taking a ‘riskier’ option, makes choices easier as opposed to being obliged to take the lower risk option.

The concept is based on the work by Nassim Taleb and Kent Beck who have both explored the impact of providing options not obligations. I’ve taken it one step further by introducing optionality as a quality attribute. Optionality being something to  ‘design in’ and intentionally removing/reduce the consequence of failure for the people who matter – your  business and your consumers.

nothing to lose

Nassim Taleb wrote this article UNDERSTANDING IS A POOR SUBSTITUTE FOR CONVEXITY (ANTIFRAGILITY) (his capitals) in which he talks about the concepts of optionality in terms of technological and scientific experimentation. Here, he explains that successful scientific experiments and technological discovery are not through luck, or trial and error, but discoveries that have a great benefit if they succeed and little consequence if they fail. The “We have little to lose” heuristic familiar to many startups. It’s worth reading his article at least once (or for me at least 3 times 🙂 ).

Optionality allows …”, its user to get more upside than downside as he can select among the results what fits him and forget about the rest (he has the option, not the obligation)Nassim Nicholas Taleb

design for optionality

When we are dealing with complex systems and a high uncertainty we should aim for high optionality. One way to do this is to remove or reduce obligation for our business partners and consumers.  Makes sense but how?

agile is a form of optionality

Compared to the waterfall process, agile is a high optionality approach. The option of providing feedback from small iterations minimise harm. The business is not obliged to take a final package at the end of 9 months, they have the option of providing feedback into the design and delivery process. Their obligation is reduced through delivering small amounts iteratively including feedback.

optionality depends on context

In his discussions on  Explore, Expand and Extract, Kent Beck stresses that in the Explore section, where high uncertainty exists, we simply don’t know what experiments will provide the greatest payoff. In this context, the best we can do is perform multiple small experiments that are cheap to throw away.

For the Extract section, where uncertainty is reduced, it may be that a lesser degree of optionality is required. We know what our customer wants and the need for multiple options is required less.

moving from low to high optionality

Is this good enough though? Regardless of what stage we are in, we continue to have features that fail to deliver on the value hoped for. Why is that? And importantly what can we do to help increase the chance of success?

When a product owner accepts a feature from development, they don’t know for sure if this feature will increase business revenue or not.  It could be quite sometime before its value (or lack of) is discovered.  The business partners have low optionality. They have two options available to them at this point, accept or reject. The feature may not be the one they want, but to reject it delays their ability to deploy and perform their own experiments on their consumers.  Business partners feel obliged to accept the feature as to not do so will cause possible harm to business outcomes.

ideal optionality

In the ideal world, we want to provide our business partners with multiple options. In doing so, we’re reducing the harm to the business. We want to provide our business with a high degree of optionality. However, optionality requires a lot of careful thought and possible architectural support. We need a way to understand optionality. To do that we need to observe and measure how this optionality may be trending.

Enter optionality as a quality attribute. Some thing to be considerd during design and architecture. We do this by asking the question:

“How can we provide our stakeholders with multiple options so they are not forced to take an option that will cause the business harm? “

examples of optionality

Optionality is not new. We see this thinking in play already.  For example, Google Webmaster has been providing me with the option to ‘switch’ to a new webmaster format. It provides me with the assurance that I can always switch back.

Another example of optionality is A/B Testing which provides two or more options on which feedback can be gathered enable the business stakeholder to chose the optimal design.

Providing multiple wireframes at design is another example of high optionality. These are early ‘cheap’ bets with options that can be thrashed with minimum harm to the business

Feature flags are a form of optionality in the architecture space. It provides a greater choice when deployment can occur, reducing obligation to go live on a fixed date.

more ideas on optionality

Our goal is to have our business partners to feeling comfortable rejecting options. This provides companies with greater optionality. So how we in development/architecture/product management assist them in that? Do you have an idea? Is your company increasing optionality in some way? Please tell me, I’d really like to hear your stories.

I’d like to thank Janet Gregory, Kent Beck and Rob Meany for proofing this blog post and providing feedback.