How to maintain a vision for your software
(Or how to say no to your customers)
Henry Ford said famously in reference to popularizing the automobile: “If I had asked people what they wanted, they would have said a faster horse.” Instead, Ford thought more broadly and created a product that addressed the true needs of his customer. Similar discrimination is key in any creative industry, and particularly in software development.
Throughout the development and ensuing public release of our quoting software, Socket, we encountered countless ideas and suggestions for new features from both our own team and our customers. Many were great and would likely serve useful to at least some users, however only a few truly fit the greater goal for our software. Since our goal was to build a sales quoting system that takes care of the grunt work without unnecessarily complicating the process, only a few made it through our gantlet of validation questions.
Scratch your own itch
To produce an effective piece of software, a developer must have a clear vision for the goals and design of his product, and must be judicious in deciding what features will and will not make it in. Intimate knowledge of the problem domain is necessary to ensure that the end solution achieves its goals in the least complex manner. The best way to ensure the efficacy of your software is to start by scratching your own itch — developing a solution for a problem you are naturally familiar with. Naturally, though, this can sometimes come at odds with what customers seek.
Needs do not equal wants
Customers don’t always see the big picture, and often misunderstand their real needs. They can often become impatient with a feature, and try to misuse it in an unintended way. In response, it’s often easy for the customer to request new ways of doing what they specifically have in mind.
On the other hand, as a developer, acting on every feature request would quickly turn your product into “bloatware” — bogged down by layer upon layer of confusing and redundant features. (By the same token a developer’s own visions can also lead to boundless “feature rampage”, so restraint must come from within, too.)
“Say no by default”
Jason Fried and David Heinemeier Hansson, in their book Rework, give the advice to “say no by default”. The benefit of this position is that popular requests will make themselves heard repeatedly, making it easier to evaluate their importance.
Despite turning down a request, saying “no” doesn’t have to mean leaving your customer high and dry. You can still be diplomatic in response, and even helpful. Often there is an alternative and perhaps simpler solution that will work just as well at solving the problem at hand, without needing to complicate the software.
Your vision must withstand the tests of time
Inevitably, customers will eventually grow out of your product. Resist the urge to grow with them by relentlessly expanding scope, because such a pursuit might risk alienating new customers whom you’ve been targeting all along.
With a clear vision, and as you begin to acquire customers and build an understanding of their needs, it will become easier to thoughtfully refrain from adding undue features — while knowing when to move ahead with those that truly benefit your target market and best serve the product.