On the Importance of Requirements and Stakeholders

Not only am I curmudgeon when it comes to Supportability; I also nitpick about things in meatspace :)

Take this for example:


This is the ice maker in one of our break rooms. Let’s take a look at how we operate this thing:

  1. The user flips a switch (or two) to select ice, water, or both
  2. The user presses the button, which dispenses water and/or ice, depending on the selections in Step 1

Seems pretty straightforward, right? What’s wrong with this design, you ask? Here are a couple of things, for starters:

  1. The operation is sub-optimal.
    1. Say I wanted ice, but not water. But, the person who used the machine before me just wanted water.
      1. Side rant: Getting just water from this machine is silly, because we have a dedicated water machine about 3 feet away. Despite this, I find the ice maker in this state quite often.
    2. Now, I have to perform three operations to get what I want:
      1. Switch water to “off.”
      2. Switch ice to “on.”
      3. Press button (this one is common to all operations; no getting away from that).
  2. It does not allow for differing ratios of ice to water. Once I push that button, ice and/or water dumps out at whatever rate the machine wants.
  3. If the user is not paying attention, they can get something other than what they wanted.
    1. Say they pour a soda into a cup, then they just press that button. How good will their user experience be when both ice and water come out? Great if you like your soda watered down, but neigh impossible to fix once you push that button.

Bringing this back to coding and Agile, this is a prime example of issues I see all the time in software design:

  1. Improper requirements gathering
  2. Engineering implementing what was spec’d, despite the fact that a better solution might exist as a slightly higher cost
  3. Lack of stakeholder input

Let’s break each of these down.

Improper Requirements Gathering

I can envision the genesis of this feature. It’s an ice machine, so it likely had the single “Push” button for its sole end-user function: gimme some ice!

Then, someone came up with an enhancement:

User: “Could I get both ice and water… at the same time, from the same machine?”

Product Owner: “Hey, that’s a nice idea. I will run this by engineering.”

Here’s where the problem starts. The Product Owner simply took the requirement as the customer stated it. They let the customer design the solution to their own problem… which, with all due respect to our customers, may not be the best plan of attack.

Any feature exists to address a problem/need/desire. A good Product Owner would not gather requirements from the customer by simply parroting the customer’s proposed solution. Rather, they would ask “the question behind the question.”

Asking “the question behind the question” gets into actual requirements gathering. Simply taking the feature request at face value makes you an “order taker.” Also, if one customer has a need, it’s almost guaranteed that others have the same. By backing up to find out what itch needs to be scratched, a good Product Owner works hand-in-hand with the customer and Engineering to find out:

  1. What is the problem/need/desire to be addressed?
  2. Given technological, resource, and time limitations, what is the optimal solution to the problem/need/desire that can be used by the most customers?
    1. See also, Jason Fried’s book, Getting Real, and his comments about building your product around a small number of customers

Here is an example I encountered that illustrates this point (as a refresher, I am in the Enterprise Social Software biz.):

We had a customer ask for what I lovingly termed “the firehose.” They wanted a running activity stream of all activity across the entire system. Every time anyone created a post, discussion forum thread, updated their status, etc, they wanted to see it.

Sounds ridiculous, right? How would that be at all useful? It would be like watching The Matrix scroll by – total information overload.

Instead of taking that request to Product Management as-is, I asked, “What issue are you trying to solve?”

The answer: “We had this feature in a previous piece of software and it helped us find other people with similar interests, old colleagues, etc. Sure, it was unbearable during the day, but if I was working early or late, I sometimes saw content or people scroll by that were useful to me.”

Basically, they wanted to use serendipity as a sort of RDF mechanism. Also, I could argue that staring at a ticker tape of activities, hoping to find something useful, is not likely going to register with their management as a great use of time. But, I digress…

My reply: “Sure, that would work. But, how about we use data from within the system to help link you to people and Communities with common interests, geographies, job roles, etc? We can then display suggestions for people, Communities, Posts, etc to engage with.”

Turns out we we already had a Suggestions feature in the works that used standard RDF triples to get at this info, which is partly why I made the suggestion. It was already near completion, it was something nearly all of our customers wanted, and – IMHO – it scratched this particular customer’s itch… even if they didn’t know it just yet.

Had we given them “the firehose,” they would have exactly what they asked for… but not what they really wanted. In this case, they were keynoting on previous experiences as the solution to their problem. A better approach would be to vocalize the pain point and work with us to devise a solution that best met their true need – given the resources available to all involved.

Ultimately, “the firehose” would have likely been unusable for most people and engineering resources could have been better spent elsewhere.

“It was implemented as spec’d, man. Don’t blame me!”

Going back to the ice maker, recall the design:


Running with our assumption that the “Push” button was the previous design, I can take a guess at how we arrived at the design above. It probably went something like this.

In the initial design, pushing the button completed the circuit to drive the motor to dispense ice. Keeping with that same design, when they added a valve to dispense water, they took the same design paradigm.

Engineer1: But, wait… there’s only one button. How about we put a switch between the button and the motor to turn the ice dispensing on and off. We need to hook the valve for the water up to the same button anyway, so let’s just do the same for the water.

Engineer2: Awesome! We’re totally going to get a bonus for coming up with a working solution so quickly.

Yes, this would indeed address the product requirement given to them:

  • Give the user the ability to dispense ice, water, or both

Certainly meets the letter of the law. I can’t argue against that.

But, did they actually take the time to use their creation? Did they take a step back and challenge the design? Was there a better way to solve the problem – even if it meant a bit more engineering time?

Quite often, I see Developers – most of which I know personally to be very smart and very UX-aware – simply implement a design as-is, even if they know that design is sub-optimal.

Why would they do such a thing? There simply isn’t time baked into the schedule to get the requested work done, much less time to iterate on the design. So, they implement what’s given, which sometimes ends up getting redone in a later release.

This one I would put in the lap of the User Experience team, with Management coming in a close second. Just as you can’t take a requirement from an end-user at face value, neither can you take requirements given from a Product Manager to be infallible. The whole idea of Agile is to iterate quickly so you can get feedback – from all parties – early and often.

Rather than just have “one” design, you should have a basis for your design – and iterate from there. You need to have slack in your schedule to accomodate this iteration.

Instead, we are often both Feature- and Time-bound, thus there is no wiggle room to do anything outside of our immediate marching orders. Ultimately, quality and UX suffers.

Lack of Stakeholder Input

This is typically more of an issue with Commercial software, as your Stakeholders are every potential client and end-user. It’s unreasonable to attempt to get such a large audience in a room – virtual or otherwise – to gain consensus and gather feedback. As a result, internal audiences – like the Product Owner – are the ones who end up accepting a User Story as complete.

Unless you plan to be the sole consumer of your product (e.g.: internal applications), this is a horrible idea.

In my experience, the people who create a product are terrible at predicting all of the incorrect ways an end-user can attempt to use the product. Nor are they equipped with the varying array of business needs that exist in the field.

Because of this, the feedback loop ends up being support cases and defects – neither of which are a good way to “wow” a customer. Not only have you damaged your brand, it is also much more costly to fix a design once it is out in the field. While most teams “can’t afford” to do this iteration in their Sprints, they end up paying more for it on the backside as the defects and angry customers roll in. Pay me now or pay me later.


To understand why this happens, go back to our first item: Requirements Gathering.

We can have every intention of doing a kick ass job of implementing a feature, but no matter how hard we try, we can not anticipate the corner cases and preferences of the end-users. The only way to do this is to get the feedback from the customers themselves.

Short of calling Miss Cleo, there is no substitute.

Going back to our ice machine, I can suspect the new design met all of the issues I cited at the top of this post… and more. Did these things occur to be because I’m some wonderful UX genius who can see things others can’t? As much as I’d love to say “yes,” the answer is “of course not!”

Had this design been tested – even internally, in this case – for a couple of weeks, they would have likely received the exact same feedback. Most importantly, it needs to be tested outside of the team that created it!

Our end-users are not aware of what happens behind the green curtain. They know how they would like it to work – regardless of the underpinnings and engineering involved. As such, they will not let technology lead them to a solution or rule out potential solutions, as would often be the case for those closer to the metal.

OK, time to bring this home…

Like any good story, this one has a happy ending. If you look for the current model of this machine, here is what the design looks like now:


Apologies for the crappy pic, but you should be able to make out that the new design is quite simple: Two buttons: One for ice, one for water. That’s it! No switches, no carry over of the previous user’s preferences.

This design is not only more aesthetically pleasing and much easier to grok, it addresses the issues mentioned above:

  • Want just ice or just water – without having to jack around with switches? Check
  • Want the ability to determine what ice:water ratio you want, without any fiddling with switches, etc? Check
  • Are instances of getting something other than you intended reduced? Absolutely (the only way it can happen is if the user pushes the wrong button)

I’ll be the first to admit that this is a pretty asinine way to get my point across, but this is a real (first world) problem that ultimately required a redesign to address. I see this happening time and again in software as the release, customer fury, re-design, re-release cycle persists.

Not to jump on the Microsoft bashing bandwagon, but look a quick look at the Amazon reviews for Windows 8 tells you that they got it all wrong. They took the option of doing what was simpler – hastily bolting a touch-centric UI on top of the standard Desktop – rather than “doing it right.”

Am I stupid enough to say I have the perfect answer to what they should have done differently? Hell no. But as a start, if you read the reviews, there is near universal agreement that the odd jumping between Metro and the legacy Desktop is jarring.

You don’t need alot of field research to find that one out. Yet, they decided to ship and are now suffering the backlash, ultimately delivering a way to bypass Metro entirely.

The points I am trying to drive home are:

  • Be mindful when gathering requirements
    • Ask the question behind the question and look for the need left unspoken
  • When designing and implementing, don’t tack on something to what exists if it will ultimately make things worse
    • Do it right the first time, else expect to see it come back – with high velocity – when your customer base hates it
  • Keep your Stakeholders in the loop
    • You aren’t selling ice makers to yourself, so make sure to deliver strong the first time to the people that matter – your customers!
    • You don’t have a second chance to surprise and delight
      • Ignore them during design and implementation at your peril!

2 thoughts on “On the Importance of Requirements and Stakeholders

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s