Do Not Ask Users What They Want!

This may seem a very strange thing for somebody to write who has, after all, devoted a great deal of effort to understanding software requirements. I think however, that I can defend it and that it is not wholly inconsistent with my broader stance on software development. The argument I want to make is founded on experience and reduces, essentially, to my encounters with the delicate business of 'expectation management'. Put simply, if you go around asking people what they want, and carefully recording what they say, then they will naturally assume that you are going to provide it. The more concerned you appear with what they would like to see, and the more evident your understanding of their requirements is, the more certain they are that they will get what they want. Then, when, inevitably, the system only meets their requirements partially, if at all, their disappointment is palpable. It is not simply that the system does not do what they want but they have been duped and their valuable time wasted.

Of course, we say, "we had to make tradeoffs", "your requirement was de-scoped", "do not worry your use case is in the backlog", whatever that means. We protest that the decisions on what to provide, within the limited budget, are not ours. We are not believed, obviously. We appeared to be in charge, and the outcome is disappointing. From the user's standpoint the focus is now on what the delivered system does not do, rather than what it actually does. A system labelled from the outset as a failure will struggle to secure user engagement and probably further development budget.

It is absolutely no use, in this case, blaming the unrealism of the users. If they have any knowledge of the budget at all, they certainly have no sense of what can be achieved within it. If we struggle to provide accurate estimates it is hardly a surprise that users find it difficult to intuit.

This problem is accentuated by expectations that are set by the user's experience of high functionality - high quality systems in their everyday lives. Apart from large budgets, highly talented and motivated development teams, systems such as, for example, Amazon, TripAdvisor and Dropbox, meet their expectations in significant part because they set the expectations. An online bookshop, travel advisory or file sharing fabric are defined by the services. Very few users were asked what they wanted, though you can naturally assume that there has been extensive user testing.

There is, of course, I should have mentioned this earlier, a worst-case scenario: building a system that attempts to meet all the requirements. Result a costly, incoherent, unmaintainable grab-bag of functionality that satisfies everybody ... and nobody.

So, what do I propose? Well, I am not sure I have a complete answer. In fact, I am sure I do -not- have a complete answer. Perhaps, an initial suggestion is that expectation management needs to become a real software engineering discipline rather than a loosely defined label for a bundle of problems. Certainly, discussions with users, and let us be under no illusion that discussions are necessary, should in some way be placed within a constrained frame. In other words that the concept of a 'budget of functionality' and of the (non-linear) escalating costs of complexity should be at the core of the discussion, introduced at the outset. How to do this? I don't know. By specifying requirements in terms of goals rather than functions we are closer to a sense that goals may only be partially satisfied. This however, is a fine conceptual distinction but the practical implications are unclear.

Clearly, a process of iterative requirements conversations and a sophisticated project communications strategy, are important in order to adjust expectations as development proceeds. Ensuring that users understand the 'big picture' makes sense, though I do not hold out too much hope for this, nice in principle, less easy in practice. It may well also be important to understand user expectations in a broader context than simply that of a single system or development project. The cycle of raised expectations and then progressively deeper disappointments, of (implicitly) over-promising and (evidently) under-delivering, may be the results of many projects and a pattern of behaviour by developers.

So, for the moment perhaps, the best I can offer are these few words of caution and pointers to a new frontier for software engineering.