Kevin Marsh

When To Say Yes to Feature Requests

As the only web developer for a small company, I get a lot feature requests for our apps and because time is limited (for everyone) I have to prioritize these requests. My job sure would be easier if I could just say no to everyone but management probably wouldn't have much of a use for me after awhile. So we need some rationale for turning one down and giving the other the thumbs up. Here's my little rule of thumb:

(time savings per day/time to implement) * number of users

or if you like terse variable names,

s/i * u

Case I: The Quick Win

Bob spends about 30 minutes a day sorting through a list of orders, paginating through and selecting ones that match a given range. He submits a request:

"Kevin, it'd be great if I could use the existing search tool to search for a range of order numbers."

A quick estimate yields about 15 minutes for writing a few test cases, and coding up the feature. We have all the variables we need, so lets fill in our equation, sticking to hours:

(.5/0.25) * 1 = 2

Hmm, seems sort of arbitrary. We'll leave this on the whiteboard, and tell Bob we'll get back to him.

Case II: Productivity, Multiplied (or divided)

Just then, Sue comes in:

"Kevin, the other 4 customer service representatives and I are spending about 2 hours every day handling orders with invalid credit card numbers. Could we give our customers some more information during checkout if their card was rejected? It sure would reduce our call volume."

Adding some more validation and error handling to the order processing steps would take a couple hours, but it looks like it would save 5 CSR's 2 hours every day. How does this fill into our equation?

(2/2) * 5 = 5

We can see right away this looks like a huge difference, keeping in mind of course that it's just a rule of thumb.

While it isn't a hard and fast rule (I don't think you could come up rules like "< x = no" and "> y = yes") I've found this technique can help prioritize requests in a way that your users can appreciate. It also forces your users to think a little about how much time they really spend doing things, and how much time it takes you to do your job.