As software makers we suffer from physics envy.
Physics envy is a term that can be used to describe the desire of designers, developers, and product 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 spend 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 to 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 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 the 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 as back-ups, re-factoring, optimization, 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.
Want to keep reading?
This is an excerpt from Intercom on Product Management, a new book from the team at Intercom about our approach to the product challenges we face.
In it you’ll learn how to evaluate your current product, decide what to build (and more importantly what not to build) and how to get new features used.
Praise for Intercom on Product Management
Every product manager should read this. The order matters — it’s great to see the outstanding chapter on when NOT to add features comes before how to build new features. — Josh Elman, partner at Greylock Partners.
While books about design and programming abound, resources for the product manager are scant. Intercom has been filling that void with excellent blog posts and now a book of guidance. Intercom on Product Management will give you tools for thinking about which features to improve, which ones to ignore, and how to better address customers. — Ryan Singer, Product Manager at Basecamp.
The Intercom team takes their development frameworks, adds a bunch of honest learnings, and spins the pairing into a book which will give at least a dozen useful ideas to anyone building products. — Hunter Walk, Partner at Homebrew VC (former YouTube, Google, Second Life product lead).
A valuable resource for anyone who wants to build products that customers will want to use time and time again. — Nir Eyal, author of Hooked: How to Build Habit-Forming Products.
