Bridging the gap with requirements definition

Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn’t click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn’t flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there’s a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.

As an example of the value of requirements definition, a former client of ours asked us to design a suite of software for people working in long-term healthcare facilities. During our research phase, in which we interviewed staff in hospitals and rest homes, we discovered a user role that our client had not previously identified. People in this role were critical to the management of these facilities, and we ultimately designed an interface specifically for them. Without the initial requirements gathering phase, our client would have been unable to satisfy this key user group, and thus would have been unable to provide its customers with the solution they needed.

Why it doesn’t work to "see what sticks"

Although it seems like an obvious step, requirements definition does not often happen in development processes. Some organizations perceive such up-front research as too expensive or slow, or believe they already have enough of an understanding of their customers’ needs. So, they throw technology or functionality at the market to see what sticks. Then they iterate the product until sales targets are met or, just as likely, the product is discontinued. It’s possible to get results using this tactic, but the hit rate is very low, and the costs are very high.

One obvious expense is in engineering and production costs: If you throw a bunch of technologies together, you may luck out and produce something people will buy. More likely, though, you’ll have to go back to the drawing board continually to rework your product or start over from scratch. Either way, this costs more than if you had shipped a desirable product the first time. Since many companies operate under the mistaken assumption that this approach is ultimately cheaper, they are often unprepared for the recurring, cyclical costs that arise. When they do realize the costs involved, the company is often reluctant to spend more, so the product languishes in its original, sub-par state, which helps neither consumers nor the company’s bottom line.

Another, more hidden consequence of the "see what sticks" approach is that it will sooner or later affect your customers’ perception of your brand. If you repeatedly release products that are difficult or painful to use or that don’t satisfy any real needs, it won’t take long for your customers to lose faith in your brand and look elsewhere for their solution. This, in the long run, can be more damaging than an inflated development budget—winning customers back after losing them due to bad design is extremely difficult.

When to define requirements

Clearly, it pays to determine what people need before you start developing a product for them. This is what requirements definition is all about. So how do you do it? Most important is timing: the requirements definition phase must be completed before any substantial development begins.

On a typical development timeline, requirements definition should occur after the business side has decided to introduce a new product (or a new version of an existing one), but prior to any technical or design planning. This natural transition point gives you the opportunity to determine what business and marketing wants the product to be, then match that to the technical requirements and capabilities of the system.

As you define your requirements, it may be tempting to start coding the parts of the product that have already been defined. Don’t. Requirements definition and development cannot be done in parallel. Good product requirements describe a cohesive, unified product; if investigation into one requirement uncovers the need to modify another, previously defined requirement, your development team must be flexible enough to accommodate the necessary changes. Major modifications to a product in mid-stream are generally the most painful, and they will cost you time, effort, and money.

The requirements definition phase is complete when you can confidently describe who will use the product and why, what the product must do to meet its users’ needs, what business goals must be satisfied, and what the major technical requirements are.

Who should define requirements

Product requirements serve as a bridge between business and engineering, so the people who generate them should sit between business and engineering as well. Technically, requirements definers can be executives, product managers, marketing people, designers, or whoever. Their place within the organization doesn’t matter; what does is that they be trusted to fairly represent the needs of the constituent sides of the organization, that they be given an appropriate level of responsibility (to temper their authority—so they have some "skin in the game"), and that they be effective communicators and listeners.

The most likely candidates for filling this role are product planners (incidentally, that’s a good title for the job; see Jonathan Korman’s article "Putting people together to create new products") or designers, as they tend to have the requisite communication and organization skills and often are already in a position of balancing the needs of the business, engineering, and users.

How to create product requirements

The most important step in defining product requirements is talking to people. This is why it is crucial that the product planner be a good communicator. There are three perspectives from which it is important to get input: business, technical, and user. This step is sometimes called requirements gathering.

To learn the why of the product, you need to talk to business and marketing representatives, who will tell you about the target market and what business needs the product must satisfy. It is also worthwhile to interview any business partners, value-added resellers, or other parties who may have insight into the goals of the product. Talking to these groups should be fairly simple, since most of them are already in your organization. One-on-one interviews or small group working sessions are good forums for soliciting their ideas and concerns.

Next, and perhaps most significantly, the product planner should learn about the potential users of the product. If the product does not yet exist, this group should include people who use similar products (made by you or other companies) or who are in the target market for your product. Talking to users reveals who will use your product and what they need it to do. If, for some reason, you are unable to talk to real users, subject-matter experts can often serve as a useful proxy for customer needs.

User interviews should be qualitative. The intent is not to gather statistics but to uncover the problems and goals of the people who will be using your product and what functionality will satisfy those goals. There are many methods you can use toward this end: ethnographic interviews, contextual inquiry, focus groups or surveys, and so on. These techniques vary in effectiveness, depending on the time available to conduct the research, the type of users with whom you’re dealing, and the type of information you’re seeking.

Finally, when you know what your users need, interview your engineers and developers to get the technical perspective-the how of the product. Find out what technology resources are available in your organization and if there are pre-existing solutions you may be able to leverage. By talking to developers, you can also gain an understanding of the technical constraints the design will need to accommodate.

Presenting product requirements

Once you’ve researched the requirements of the various groups within your organization and those of your users, you need to represent your findings in a way that everyone in your development organization can embrace. One approach is to develop personas, which are archetypal characters created to represent the needs and goals of the people for whom the product will be designed. A believable, well-developed cast of personas—including one or more target, or primary, personas—can serve as a rallying point for the product. Defining functionality to satisfy the goals of a real person, rather than an abstract notion of "the user," enables your organization to avoid development roadblocks caused by personal preferences or biases. (For more on developing personas, see Kim Goodwin’s article "Perfecting your personas.")

Finally, when you’ve answered your key questions and you know the why, what, who, and how of the product, you must capture that information in a Product Requirements Document. The PRD represents the first in a trio of documents critical to successful technology product planning (see diagram).

Once a product idea is generated, it is important to document the relevant requirements and specifications at each stage of development. This helps ensure everyone in your organization is on the same page—literally and figuratively—throughout the process.

The PRD is where you actually define the requirements of the product. The document itself can take many forms, but it should always include compelling descriptions of why the product is being developed (business and marketing goals), who will use it (personas and their goals), what functionality is required of the product (persona needs), and how it will be built (engineering goals).

The PRD need not be perfect. It is impossible to accurately specify every detail of the product before development begins. Many times, technical implementation can illuminate new, better ways of doing things—but only if everyone is working within the defined overall direction provided by the PRD. When generating product requirements, the high-level model of the product must be correct; if it’s sturdy, everyone can use it as a guide, and lower-level details can change without rocking (or capsizing) the boat.

Incorporating requirements into the development process

When the product requirements document is complete, and the appropriate people have signed off on it, the design of the product can begin. With a PRD that provides a clear roadmap, business and marketing can be confident that their sales and company growth goals will be addressed, while engineering can be assured that development will proceed without any surprises down the line. Completing a successful requirements definition phase may require more time at the beginning of the development cycle, but the investment pays off in development savings and in the marketplace. Ultimately, requirements definition will produce better products for both you and your customers.

2 Comments

greg
This is well done. I'm curious, though, are you still hard and fast about your don't-develop-until-requirements-are-done rule? I would have agreed eight years ago, but find myself pretty confident now that a decent team, with a mature process (some blend of agile, xp, scrum) can start making progress immediately and adjust course as necessary.
Dave Cronin
Greg, we're right there with you. Maybe one way to characterize our current thinking about it is that "requirements" is an ongoing conversation that is never quite "done." We still think it's really important to get everyone on the same page about the big picture requirements before substantial development takes place (e.g. describing why someone would use the product, what they should be able to accomplish and how the experience should make them feel), but that the detailed requirements (things that one could actually code against), evolve as the design evolves, which hopefully happens as developers are engaged in actual construction.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment