False Progress
Every feature added to a product increases its complexity and raises the risk of errors. So be absolutely certain of the value it adds.
I once owned a coffee machine that used aluminum capsules sold by a dandy named Georges ☕️
This machine was designed to automatically pierce the capsule so that I, a young executive as dynamic as I am ambitious, could save precious seconds. Seconds that I used to fully exercise my creativity, start three companies, change the world, and… try to dislodge that darn capsule that had once again failed to seat properly (about once every 10 tries).
So there’s a whole mechanism and electronics involved, all that additional complexity, just to spare me from manually operating a lever and exercising my little muscles in the process: you can’t stop progress…
There are plenty of examples of false progress: electric knives, pocket fans, cat water fountains, leaf blowers, all the way to the hypothetical “smart” salt shaker, which, let’s hope, is more of a meme than a reality. And when, one Saturday night, my toilet starts leaking like crazy, I tell myself that the old-fashioned water jug had its merits. Me, Amish?
But let’s get back to our software.
When you’re developing a product, there’s often that one feature you introduce that multiplies the complexity of the code tenfold. The existing functionality becomes just a special case; you’ve taken it up a notch in terms of generality: wow, what power, I’m the master of the universe, but let’s calm down.
Sometimes this complexity is justified, because it provides a service that sets us apart from the competition… and sometimes it isn’t. Or, worse, the user experience suffers, and we slip into feature bloat: adding the feature actually diminishes the value of the app as a whole.
Feature bloat is a serious problem because, in addition to degrading the user experience, the complexity introduced by the feature slows down the development process while increasing the risk of bugs. It’s a surefire way to lose users.
It’s therefore better to take the time to “challenge the requirement” with these users, constantly return to the “why” (the 5 Whys technique), weigh the pros and cons, and, if necessary, come up with workarounds. That’s the whole job, and the whole added value, of Product Managers.
Unfortunately, competition pushes companies to offer products that do everything but the kitchen sink. The SRP (Single Responsibility Principle: do only one thing, but do it well) isn’t always easy to sell, especially for reasons of interoperability between applications.
But I’d tend to say: when it comes to features, it’s better to have too few than too many. If all signs truly point to the fact that you can no longer do without this feature, there will still be time to implement it with the conviction that the complexity it brings is a necessary evil.