Gathering Requirements: Ask Why
Would you like to improve your software or make some new functionality in your existing software? Better yet, a customer is requesting a new feature. Regardless, you want to deliver a product that the customer will like and use. Simply ask your consumers what they want, right?
Over the last few years, I've collected requirements from internal and external stakeholders, which were used to build new functionality into existing software (or improve existing functionality). I can tell you that customers always know what they want, but rarely know what they need. Client’s requests usually go something like:
"I need X so that I can Z."
Now, all we have to do is build X, right? WRONG. You MUST ask this question or you will likely get it all wrong.
Why do you need to Z?
Gathering requirements for any project can be a tumultuous process. Stakeholders will tell you everything they need and constantly ask you one last time for the proverbial One More Thing. If you want to save some red ink and time, simply ask, "Why do you need this?"
Driving a Car Does Not a Mechanic Make
Every time I tap the brake pedal in my car, the front vibrates a little and pulls to the left. One day, I’m riding in my car with my brother-in-law (who is an amateur mechanic), and he confirms my suspicion, I need brakes to stop the vibration and pulling.
I take my car to the mechanic and ask him to check the brakes. The mechanic inspects the brakes and concurs, my brake pads are worn and the rotors need turning. So, now I am waiting for the brakes to be fixed. Once they are done, I pull out of the lot and I apply the brakes and the front end vibrates and pulls to the left, just as before! Naturally, I take my car back and insist something is wrong with the brake job that they just completed. They put my car on the rack, inspect the brakes, and declare nothing is wrong with the brakes. So, I do the only thing I know to do, I tell them why they did their job poorly.
“Every time I tap the brakes, my front end vibrates and it pulls to the left.” For the first time, I have told the mechanic my problem. After some investigation by the mechanic, he confirms that some suspension component needs to be replaced to fix my original problem. Even though my mind tells me they simply did what I asked, I am pretty disappointed in the service. I just had a bad experience with the mechanic. Why didn't they ask me why I thought I needed brakes?
Using Software Does Not a Software Engineer Make
We had a customer who was interested in migrating their Spam Filtering from Company A to AppRiver. They trialed our service, and provided this feedback, “We like your software, but Company A’s software provides a must-have feature that yours does not (e.g., our users need to override domain level blacklists and whitelists). Can you add this feature to your software?”
This request would require a sizable change to our API and impact all of our customers, so we asked, “Why do your users need to override domain level blacklists and whitelists?”
Potential Customers Response:
"Some members of our executive team want to receive/block email from domains that may be on the white and blacklists.”
Here is what they initially asked for:
"Our users need to override domain blacklists and whitelists."
Here’s what they really wanted:
They needed the ability to designate specific users that should not inherit domain level white/blacklists and the ability to configure how their lists interact with the domain lists.
Can you imagine if we had delivered the ability for all users to override domain blacklists and whitelists? The CEO would have even less control over what mail she received, legitimate emails would be quarantined, and spam would flow to inboxes.
Here was our implementation of that final request:
The Admin may select an individual user and edit her permissions as shown, and then select how the domain whitelists/blacklists will impact that user.
This implementation isn't perfect, since it doesn't allow an Admin to select several users and change their permissions all at once (bulk editing). As more customers begin using this, we will continuously improve this implementation to fit their needs.
Listen to your customers and stakeholders; they are the lifeblood of your company and will supply you with endless ideas to improve your software. But asking them why will give you insights into what they really want!