A House With No Front Door
In my effort to build products with limited resources, I often spend time justifying the need for features. Market facts provide quantification for the requirements and usage scenarios put them in context. But too often, I still face the usual questions from the engineers over each requirement:
- Is this feature critical for this release?
- How many customers have asked for it?
- Are there any workarounds?
- Would we lose deals if we didn’t have it?
And my least favorite:
- Of all of these features, if you could have only one, which one would you choose?
Why they persist in asking this question, I don’t know. It’s like asking, “Of all of the doors on the house, if you could only have one, which one would you choose?” My answer to this question would be “the bathroom door”, but that’s not relevant here.
Now I don’t blame the engineers for asking these questions, because they are just doing their job in trying to optimize the resources they have at their disposal and the tasks expected of them. But in one particular case I just started to cringe at these questions.
During a meeting with engineering, a feature was being considered for an upcoming release. For the sake of this article, let’s call it Foo. Foo is a component of a much larger set of functionality (let’s call that Bar), and was identified 2 releases ago as a necessary requirement for Bar. At the time, there weren’t enough engineering resources to complete Foo. Why there weren’t enough resources is another story though. But it was agreed back then that Foo was truly a key requirement and would be addressed in an upcoming release. In fact, we had customers tell us, that Foo was so important to them, that they would not consider using Bar without support for Foo. Are you still with me?
Now, back to the engineering meeting
While everyone else, including other development managers, agreed to the need for Foo, the development manager of the team that would implement Foo kept pushing back on the requirement, asking for more customer input (we already had a lot), describing various workarounds (none of which were reasonable), and then arguing the size of effort and that his team was already overburdened. By the end of the meeting, he agreed to go back and re-scope the effort, acknowledging that his initial understanding of the requirement was not accurate.
On the drive home, thinking about this, two things stayed in my mind. One was the focus on workarounds. The other was that there is another set of questions that we should be asking as we plan our products. The questions need to be less internally focused like the ones above, and more externally focused. They should be similar to the following:
- How will this feature improve our product?
- How much benefit will customers derive from this?
- What user pain is removed if we add this?
- Does adding this feature remove or reduce any competitive threats?
- Will it make the product easier to demonstrate or sell if we add this?
- How many of these features will remove existing workarounds we have in our product?
- Will customers use the product more if we do this?
And if they really want to ask, they should ask:
- Of all these features, which one provides the most value to customers?
Perhaps it is my job to get this perspective across to them, and I try to do that, but the gulf between the “feature triage” perspective that many engineers have, and the “holistic” customer or market perspective that is needed is enormous.
But the question of the “workarounds” stuck with me. Workarounds to software deficiencies are not new and not uncommon. In a way, they show the flexibility of software in general. If the optimal way of doing something may not be possible, then there may be an acceptable, less optimal way of doing it.
The problem that I have with the concept of the “workaround” is that not all workarounds are created equal, and there are no real metrics that are used to measure how big or laborious specific workarounds are. Some “workarounds” require the user to perform incredible contortions to do what is needed. Additionally, workarounds should be the exception and not the rule. i.e. the software should do what is expected of it in efficient ways, and only in a rare cases, or cases where people are trying to do something that the software wasn’t intended for, should the concept of a workaround be discussed.
How is it acceptable to say “All you have to do is edit the registry?” But first you must read a one hundred word disclaimer that warns you of impending doom if you do.
Workarounds are sometimes endemic in the culture of software companies. The feature triage model of prioritization almost guarantees this. I wonder how many companies measure the amount of necessary functionality that is provided via “workarounds” to their software? Looking at this in another way, it is a measure of how completely (or incompletely) software addresses problems it is meant to solve. Now that would be a good metric to know.
It is all too easy to say that some necessary functionality is not provided because the implementation effort is too high, but that a workaround requiring less development effort can be provided for the customers to use. This in my opinion is an unacceptable justification for providing a workaround. If something is truly necessary, then why is it not worth implementing correctly? Yes, I understand deadlines and resource constraints and marketing, sales and competitive pressures etc, but it is very easy to fall into the habit of providing partial solutions to problems, and laying the burden of what’s missing onto users. When this becomes extreme, perhaps the ideal workaround for customers is to start using someone else’s product; one that doesn’t deliver functionality as a set of workarounds.
Additionally once the workaround is created, it develops a certain inertia that requires significant force to displace it and implement the correct, full solution. I’ve seen this far too often. Once some code is written that “kinda sorta” addresses the problem, then pulling out that code and replacing it with code that addresses the problem correctly and completely is never a priority. Hey, there’s always new functionality to implement and workarounds to other missing functionality that have to be addressed, right?
And unfortunately, because of this preponderance of workarounds, software users themselves begin to accept these workarounds, instead of demanding full solutions to problems. The result, software becomes unnecessarily complex, hard to use and expensive to maintain. In a time where cost controls are critical and measurable ROI a requirement and not just a promise, there can be no better reason for software companies to invest in their products and provide complete solutions to their customers’ problems.
Imagine if houses were built with this premise, and every time some aspect of the house was discussed, questions about workarounds were raised. You’d end up with a two story house, that required external ladders to get to the second floor, a fireman’s pole to quickly get down to the first (no wasted floor space inside because of unnecessary staircases), that wouldn’t have a front door (the back door should be sufficient), that had only one big bedroom and closet for everyone (those extra walls and doors cost time and money you know), one bathroom (it would be an outhouse to give equal access from either floor), and only a wood burning stove to both heat the house and to use for cooking (minimizes unnecessary duct work).
While this is rather extreme and would never happen in constructing a house, it is exactly what happens in many software products. The burden of work is shifted from the software (and the engineers who wrote it) over to the user who can do, more or less, what they need, but with significant additional effort.
It’s no wonder that whenever someone creates software that solves problems completely, elegantly and cleanly, people take notice.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.