In my Internal Web Tools group at my day job, we regularly deal with end users who are rather, shall we say, insistent that they need a particular feature on an app we are building for them. When we ask them why they need that feature, their responses generally includes phrases like "I will have Ability X or my ocelot will claw your eyes out," or "Implementation Y must be in place by this date so we can be sure to be live before Marge's boyfriend's Zodiac sign is in the fifth house of Lannister." (It is possible that I am remembering these conversations incorrectly.)
Once we get that much-sought-after improvement in place though, we often never hear whether or not the end users are using it or, indeed, actually needed it. Time constraints on many of our projects don't allow for complete logging, so we can't get the info we need that way. Further, users are notoriously bad about providing feedback unless you coax it out of them (or bribe them), and ours are no different. Usually what we end up doing is assuming something works the way the users wanted it too unless they tell us otherwise.
Sometimes, though, we come across a bug that requires us to turn off a feature for a little while in order to track it down. It might be a permissions issue (our eternal enemy) or a Heisenbug or what have you. At any rate, when these issues pop up, very often I end up uttering the following sentence:
Just turn it off and see if anybody complains.
On the face of it, this seems like a dangerous thing to do, and usually my internal monologue rebels against this idea. Just turn it off?! We can't do that! What if somebody is using that thing RIGHT THIS VERY INSTANT? The users' anger could make their heads pop off their shoulders, and by sheer raging force of will they'll roll to us and YELL at us for taking away their beloved Excel export, and when they are done verbally eviscerating us they'll have to roll all the way back to their cubes and sow themselves back onto their bodies! We've seen it before, remember?! We can't put our precious users through that experience!
Complaint Department Grenade by Adam the atom, used under license
Hyperbolic internal monologue aside, in practice this it turns out to be a surprisingly effective way to determine whether or not the users actually care about that particular feature. If they do care, they complain immediately and loudly; if they don't, we don't hear from them at all.
What this means is that we had better be pretty sure that our users are not going to complain (at least not immediately) should we decide to disable one of the abilities of an app in order to solve a bug.
It's very much a strategy of asking forgiveness rather than permission, and as such it carries some risks. For example, you can't do this very often or with vary-large-impact features. If you want to disable the login system for your intranet just so you can find out who was uploading the wrong JPEGs, you'd better rethink your plans. People really don't like it when you move their cheese, so doing it too often just annoys them for no good reason.
Further, you had better be rather confident that disabling the feature to solve a bug is the correct thing to disable; otherwise you've potentially pissed off your users for no good reason. If you're just willy-nilly turning things off and on without any reasoning as to why you need to do that, your boss is probably going to want a word with you, and not in a good way.
But this strategy carries some nice benefits. For our group, which deals with hundreds of small web apps, the primary benefit is that we get clear and obvious indications as to whether or not our users are actually using the now-disabled feature. We get to know whether or not the users care about that feature for real, rather than just assuming they do because they told us they do. We get to indirectly ask the users whether they actually care, and if they don't we can look at removing that feature since we aren't going to need it.
Ultimately, we wouldn't do this if it didn't work, and it has worked for us rather well. We've done this on several occasions, and only once can I think of a time where the user complained before we had caught and fixed the bug in question (and there's only been a couple of times where the user complained at all). It's a procedure that works well for my group, especially for certain cases of analysis paralysis; maybe it will work for your teams as well.
Have you tried this before, and did it work out for you? Or did it end up biting you? Share in the comments!
