If you are working on a product that involves software, you may realize a considerable number of the features you build are never utilized by your users. And while some of those may be there due to legal reasons, the fact that you spent resources with little to no return of your investment does not change.
To make matters worse, these features increase the system's complexity and make the remaining ones less discoverable. Combined with the understanding that the majority of the work which goes into a product is not in functionality that sets it apart from the competition, I have become a firm proponent of data-driven decisions.
Unfortunately, reaching the blissful stage where your organization can acquire and make sense of data as well as use them for decision making, requires a considerable investment. Investment in both the relevant technical infrastructure and product features as well as peoples' mentality. For example, functionality that allows data gathering, quick feedback loops and experiments needs to be implemented. Moreover, individuals have to accept that navigating the market based on opinions or, worse, a "hunch", is tremendously costly and risky. To be honest, such a transition will not happen overnight and it is ultimately a matter of culture. Before anything else, the change will never occur unless the status quo is questioned.
You can begin changing mindsets towards a data-driven approach by making the need for it (more) obvious. When someone proposes a new requirement, feature or change, the usefulness of which is not beyond the obvious, you simply ask "Why? What value does this bring and to whom?".
This question will force the requester to contemplate the potential return of investment and argue logically for it. Additionally, this may commence a conversation on the ways the change will affect performance, complexity or architecture. Once the proposal has been reasonably defended and the requester has not changed their mind, the next question is "OK, can you prove it?".
It is unlikely you will get a response citing facts and data. If you are lucky, a particular use case of one or more customers may be mentioned. This may be good enough if you are working for the particular customer(s), e.g. you are their supplier. However, if you are aiming at a broader market segment then this simply should not be sufficient. You are not consulting for the specific subset of your consumer audience, therefore the benefits of satisfying their demand do not necessarily justify the change.
You may eventually have to grant the request since you also lack data and do not want to come out as someone unreasonably negative. Nevertheless, with this negotiation, you have hopefully planned the seed. Keep reminding it is better to make happy customers than making customers happy. In other words, you should prefer to be proactive than reactive. Do this enough and your organization members may start shifting away from the current opinion-driven approach.
Steering clear of features that do not adequately increase the value of the product is not only about saving money. They affect the user experience, the maintainability of your software and more often than not, technical debt. The more features you add, the more cluttered your product is likely to become. Simultaneously, the complexity is bound to be raised which adversely influences maintainability. This realization sold me on the oxymoronic correctness of Worse is better.
Worse is better or the "New Jersey style" is an approach that values simplicity most, in software design. Furthermore, it favors being simple than correct. Next, it tolerates the sacrifice of consistency and completeness in favor of other quality attributes, especially when complexity is inflated on their behalf. I have grown very fond of this statement, not just because it is provocatively amusing. What it lacks in straight-forwardness, it makes up for the truth it entails.
"Worse" is indeed better when a project gets bombarded by feature requests, stemming from arbitrary hypotheses with dubious marketability. The desire of salespersons to satisfy a couple of new leads is not a good enough reason for R&D to cram new functionality into the product. Succumb and you will find yourself in a downward spiral that results in tilting the balance of power between the company and its customers towards the latter. Consequently, if this relationship gets abused, your organization may end up pampering few "loud" customers ignoring the needs of a much larger user base.
Instead of a conclusion, I strongly encourage you to have a look at several excellent reads by the Software Engineering professor at Chalmers, Jan Bosch. They have been a fantastic source of inspiration for many of the thoughts illustrated in this article:
Comments