Product Requirements: How to Figure Out What to Put in the Stew

Even though it’s often a no-win situation, I’ve always enjoyed the process of coming up with product requirements. I really like taking all those disparate threads and coming up what will be in the next mix.

Things have changed, of course, since I was establishing product requirements. With the development tools available, release cycles, at least on the software side of the house, have accelerated - as have customer expectations about when they’re going to get new stuff. For companies providing software as a service, the notion of the big, mega, once a year grab-bag release is almost obsolete, given the ease with which small nip and tuck changes can be made and deployed.

But I don’t imagine the process has changed all that much.

You still need to listen to what your customers are telling you - while also listening for what they’re not saying, and trying to anticipate needs they may not yet realize they have. You need to keep up with your competition, not borrowing wholesale or exclusively from the Joneses - that’s a sure-fire guarantee that your product will always be behind - but taking an honest look at features they have that your product really needs.

You still need to think about industry and technology trends, and how they’re going to impact your product.

While it’s absolutely essential to look outside for product ideas, I always liked tapping all the internal sources, as well: techies, QA, customer support, sales engineers, marketing, sales (although with sales you always need to be aware that the most important item in the next release is the one they attribute their most recent loss to).

Once you have your first pass at the list, it’s always good to run it by a few key and trusted customers. (Hint: these won’t necessarily be the folks who spend the most money.)

And, while you’re figuring out what stays on the list, you also need to be figuring out what to toss off the list. Some on both sides will be obvious, some less so.

But the cardinal rule has to be that just because someone suggested it doesn’t mean it’s a good idea. (And that’s no matter who suggested it.)

I started thinking about this the other day when I was at my physical therapist.

I was in the ladies’ room, and the toilet paper in one of the stalls was running out.

My PT place is an informal and help-yourself kind of joint, so I went to the cabinet and got out a new roll. But when I went to put it on, I found that you need a key to undo the roller apparatus.

Huh?

I am hard put to think of the circumstances under which you would want to have a key-holding gatekeeper who’s the only one that can replace the toilet paper. The only situation I could come up with was a night club in which everyone was drinking, someone might drop the spring-action roller on the floor, and someone else might slip on it and bash her head against the toilet. Even in those circumstances, couldn’t you go with the t.p. holders that just swing away?

A silly example, perhaps, but one with a point: before you add a feature to your product, you should really ask yourself who will be using it, how will they use it, how they will benefit from it, and whether there’s any downside to that feature that you can think of.

A key to change the toilet paper roll? Hah!

When you’re setting product requirements, you’re really preparing a stew. And while a lot of different things can make up a stew, just because you have something sitting around the kitchen doesn’t mean you have to use it. Throw in some marshmallow Peeps, and people will ask themselves what you were thinking. Toss in a handful of marbles, and somebody may break a tooth.

---

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically each day to your feed reader. If you don't have a feed reader, you can always have these articles delivered to your email inbox every day. Click here to sign up.

The Opinionated Marketers | Powered by WordPress | ElegantBlue is a custom theme by Nathan Rice