Option Value

Interfaces have limited real estate. Interface options need to fit on the screen in order to be discoverable and accessible. This is different from the back-end. APIs have practically unlimited surface area.

Interfaces are also one-way, in the sense that you can't take features back. You can only get away with removing features in the very early stages of a product with extremely few customers. Once your customer base is larger, there will always be someone who found a way to use that feature in some unexpected way and now depends on it.

These facts make empty space in the product valuable. The value of your option to use the empty space in the future is high.

If you have an idea for a feature or a button, consider how likely you could be to have a better idea in the future about how to use that space. Always weigh this "option value" against the value of using the space now.

Core vs Periphery

A design can't be everything. So you have to figure out which things are core and which are not. Some features are core — they are the essential features that the majority of customers need. Others are "edge cases" – peripheral.

The same applies to use cases. Some represent the exact case that the product is made for, others are more eccentric.

Often when teams take feature requests or consider new ideas, they forget to step back and ask whether the idea is core or not. Checking how core it is puts the feature in perspective. Core is about importance, independent of how good the idea is or how well you can implement it (see Impact vs Quality).

It's okay to support peripheral cases or add features that are only valuable to a handful of customers. But they shouldn't interfere with the core, and you shouldn't give up too much Option Value.



Real Moments

When the debate about what to build gets too fuzzy or wide-ranging, focus on real moments. Identify a specific chain of events that happens in real life and set that as the context for the discussion. Does the feature make more or less sense when we consider this use case? If that use case isn't core enough, then how about this one? Shifting to moments in time brings the conversation down to specifics and enables the team to make trade-offs together.



See also:

Compare to Baseline

When evaluating work in progress, always compare to baseline. Focus on how much better the work is compared to what customers are using now instead of how much better it could be if you worked on it longer.


See also:

Quality vs Impact

Quality and impact aren’t the same. For example you can spend extra time making an administrative settings UI look better. Or you could reduce the wait time on an action performed from the administrative screen. Both could be objectively "better" — higher quality — from the builder's POV. But that doesn’t mean the changes make a difference to customers.

Think of each aspect of a design in two dimensions: how much better it is in terms of quality and how much it matters to customers. You can imagine each force working on the design as a vector. The sum is the net win/loss given the trade-offs in the design.


Example: We’re considering adding a new setting to notify people when a to-do is completed. The new feature does a better job than baseline on setting expectations. But it complicates the rules a bit. The complication doesn’t produce a big negative impact and it’s not so bad that we can’t live with it. So we shipped it.