Features & Physics Envy
I use the above graph to pick what features to add or improve based on how many customers use them, and how often. This leads to curious but clever decisions.
For example if a hotel booking website has to choose between a minor improvement to the date picker, or a significant improvement to the print stylesheet, then the minor improvement is always a better choice. All features were not created equal, hence the diagram. In addition, just because a feature took months, it doesn’t mean it’s going to be useful. There’s no easy correlation between effort spent and user satisfaction. Let’s take a look.
We suffer from Physics Envy
Physics envy is a term that can be used to describe the desire of designers, developers, and project managers to enforce laws on a system that simply doesn’t obey them. We would love it if the return on investment was always perfectly proportional to the time spent. It would make product planning easy. The problem is that you can spent five weeks working on a killer feature, only to see it go ignored by your users. Conversely you can add one sound effect, have your cute logo say Hi, or make your favicon blink, and all of a sudden everyone is talking about you. It’s not rational, but then what is?
Rather than try stare enviously at those who don’t work with such irrationality, let’s see how we can use this to our benefit. When you’re planning your next few months work, plot your features on this chart…
Anything in the lower right corner is special. These are features where the return is disproportionate to the effort. Some examples I’ve seen are:
- Rewrite the app copy to make it all more personal, funny, precise or useful.
- Add a couple of keyboard shortcuts to let power users be more productive on the main screen.
- Remember the last active project and bring user back there when they next log in.
- Provide extra information and links to actions in email notifications.
When to Use Quick Wins
Customers won’t value all the development you do on a project. Some necessary tasks such back-ups, re-factoring, optimisation, improving infrastructure offer little immediate reward. This doesn’t mean you can ignore those issues. The trick is to plan your roadmap so there’s never long periods where customers feel the application has been abandoned.
This is precisely where quick wins are useful. You can schedule these quick wins to cover time periods where it would otherwise appear that nothing is happening. This way you’re constantly delivering value to your customers, whilst still tackling the larger features or back end problems. Remember the only thing worse than an app in constant flux, is one where users can see cobwebs forming.
