The Reason Why

Seth Godin has a post titled The Reason.

He has several good examples, like this one:

The reason the typewriter keyboard is in a weird order is that original typewriters jammed, and they needed to rearrange the letters to keep common letters far apart.

In each of his examples, Seth asks and answers the reason why we do things that don’t have an obvious rationale.

Requirements elicitation is about asking why
When we ask why correctly, we get great insight, which enables great requirements, which can yield great software. When we ask why incorrectly, we can get a great big mess.

Some examples of asking why about software product requirements:

• Why do the users need to be able to save work in progress and come back to it later? This is the killer-feature of Turbotax on the web. The answer is that most users don’t complete their taxes in a single session.
• Why must we be able to create a report of all purchases by a single customer in a single quarter? Because we have a rebate program that rewards customers for aggregate sales data, not just per-order discounts.
• Why must we update the price of shipping dynamically as users make selections? Because our customers are total-price sensitive, and this is how we differentiate our online-store.

We need to remember to ask why something is a requirement. Not just so that we can control scope, but so that we can focus our effort on the most important requirements, like we discussed in our recent post about requirements prioritization. The folks at 37signals ask why. They get it.

We need to ask nicely.

We must avoid sounding like a broken record – why why why?! We also have to avoid sounding accusatorial – imagine the emotions we would feel if someone asked us any of the following questions:

• “Why did you think it was a good idea to drag race my car?”
• “Why did you have a party when we were out of town?”
• “Why is it ok for you to sit and watch tv all day while I’m working in the yard?”

We might feel apologetic, or defensive, or embarrassed, or worthless. This isn’t an inquisition, its elicitation.

We won’t intentionally ask threatening questions, but that doesn’t mean that our audience won’t feel threatened.

• We may be in the process of discovering that their favorite feature has a very low ROI and is at risk of getting dropped from the product.
• We may be asking questions that they can’t answer, and they may feel humiliated or at risk of losing their responsibilities or their job.

We have to be good listeners – and pick up on cues and attends that we are making people uncomfortable, and adapt our approach.Thanks Seth for the spark of this this post.