Software requirements are arguably the single biggest source of heartache for Product Managers and anybody else working to move a software product forward. Requirements definition is every Product Manager’s dreaded opportunity to wrestle with all the contention, politics, and conflicting viewpoints an organization has to offer.

Not only is formulating and prioritizing requirements the essential starting point of any effort to improve software, but there’s almost always a major disconnect between how requirements are expressed by sales reps, marketing, prospects, or customers and how those same requirements need to be stated in order to pass along clear, complete guidance to developers and other technical teammates.

So here’s a little bit on what I have learned to change requirements from “hype-ful” – straight from the mouths of sales reps and marketing types – to helpful, in three basic steps.

Step 1: Remember the Real Goal

Often Product Managers get so caught up in the whole drama of requirements time that they forget that their goal is not to hear and understand the features and changes being requested by everyone and his brother. Instead, the goal is to communicate to developers which specific features and changes need to be coded. So it doesn’t really matter if somebody in Marketing or Sales understands the requirements, what counts is that someone in Development or Engineering does.

Most software programmers are people who specialize in the technical subject of computers and programming, not the business purpose of the software. If your software lets sales reps see their pipeline and stay on top of deals, I bet your programmers are not all former salespeople who have since learned to code, yet still adept at every nuance of successful selling.

What this means is that you cannot rely on the ability of your programmers to take instructions like “make entry of new prospects easier” or “streamline the qualification process” and make judgment calls based on a true understanding of what it’s really like for someone using the software.

Instead your descriptions need to be specific enough that a programmer is not required to make major judgment calls on the business issue. Let them apply their judgment to technical questions.

You can do this by first removing the hype, and then adding information that provides instructions that a programmer can readily follow without having to interpret it, as described below.

Step 2: Convert the Hype

For me, hype in a software requirement is information that is not matter-of-fact or cut-and-dried. It is information that requires the reader to interpret it.

Let’s go back to the example used above for a contact management tool: “Make entry of new prospects easier.” Basically all the instructions are provided by one word “easier.” Now this is hype worthy of its name! It sounds extreme, but I’ve seen plenty of requirements like this one.

The only interpretation that a typical software programmer can make of this is that there need to be fewer keystrokes, including the Tab and Enter keys. Maybe somebody’s asking for more dropdown lists to save keyboard time?

It turns out that the problem, when you look at it more closely, is that after you specify that a prospect is a business, not a person, you have to move through all the Name and Title fields, which you often don’t know at this point, to get to the Company field and address fields. Similarly, when you say a prospect is a person, you still have to go past the Company and Department fields to put in the address.

To meet your goal of clearly communicating to the programmer, you need to make this more cut-and-dried, as well as more specific. Try something like this:

“Make entry of new prospects faster by changing the order and availability of the fields to match whether a prospect is an individual or a business. Display fields by default for individual prospects. When the user specifies that a prospect is a business, change which fields are displayed and their order.”

Hardly literature, but already much more helpful to a programmer.

Maybe not helpful enough, though.

Step 3: Add More Help

I would not assume at this point that we have reached our goal of complete communication to the programmer. It sounds like it might be simple to determine which fields belong to which type of prospect, but not if you’re not a salesman. There will be questions like “Wouldn’t you still want the company fields for an individual, in case you want to put that information in?”

So it helps to add the following to the earlier description:

“For individual prospects, the fields are First Name, MI, Last Name, then the Address fields. First Name and Last Name are required. For a business, the fields are Company, Department, then the Address fields, and finally First Name, MI, Last Name, and Title. The Company field is required.”

And while you’re at it, you might begin the requirement with an explanation of the overall business need that is driving the request:

“Salespeople need to enter new prospects as quickly as possible while they’re on the phone with them.”

This will help the programmer focus on the business use of the software.

Are We Helpful Yet?

By translating the hype words and adding help words, you’ll wind up with requirements that are reasonably pleasant and simple to get across. This is good, because the technical and business folks can both leave the requirements sessions – shaken, but alive – with energy left to continue to dialogue with each other during the design, planning, and development that will follow.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com