Don’t Ask Me What I Want, Give Me What I Need

I don’t know about you, but scenarios like the following happen to me all too often. I meet with the business stakeholders and representatives of the user community to discuss changes to a software application. We discuss new features and/or changes to existing ones. They give me a general idea of what they want. I describe how this might operate within the software. They indicate agreement and I go forth to develop the features in our sandbox.

Depending on the type of changes and which software development groups need to be involved, I may create a formal specification, write up stories and/or throw together a mock-up. For small efforts, I may simply make the changes directly in the sandbox ( makes this really easy). I can always write some kind of documentation after we agree on the implementation approach.

So far so good, right? I show them the sandbox implementation. They offer a few minor suggestions and ask how soon the changes can be deployed in production.

We love it … But …

Here’s where it gets interesting, amusing or frustrating depending on your point of view. The changes are deployed and complaints arrive in my inbox — usually only a few but on occasion, it can be a blizzard! Why does that happen?

1. Sometimes the stakeholders and user representatives didn’t fully understand the problem expressed by the end users.

They should have dug deeper and I should have engaged at least some of the end users directly rather than having all the information filtered through their reps.

2. Sometimes the stakeholders and user representatives didn’t fully understand the solution I proposed.

They should have spent more time exercising the sandbox implementation and asking questions. I should have explained the solution better and more importantly, I should have clearly defined what the software would and would not do.

3. Sometimes the stakeholders and user representatives didn’t really know what they wanted. Their real intention was to try something, see the result, and make another set of changes to the software based on user feedback.

That’s fine too, though they should have stated up front that they wanted to conduct an experiment. This is a communication breakdown that stems from lack of trust.

4. Adding more people to the discussion by deploying the software always generates new ideas and opinions.

That’s a good thing — as long as everyone is reasonable. I always listen carefully to everyone’s concerns and opinions. Most people simply want to be heard and understood.

5. Some people simply enjoy complaining.

Sadly, there’s nothing we can do about this latter group. Let them complain and always ask them for their ideas.

These issues don’t crop up every time but often enough to be troubling. Everyone is busy trying to operate their area of the business. Everyone has too many demands on their time. These issues will never go away entirely.

Welcome to the world of software application development. I don’t know what I want but I’m sure you can figure it out.

photo credit: Sybren A. Stüvel via photopin cc

Updated: January 24, 2013 — 9:54 pm


  1. Klaus Even Enevoldsen

    I understand your frustrations all too well. In my head I’ve been playing with the idea of creating a role play where the stake holders can interact with each other.

    1. Good point. At times the stakeholders really don’t agree even though they give the appearance of agreement. Once the software is delivered, the truth always comes out.

Comments are closed.