After all the customer research you have done, you will probably have a pretty good idea of what will resonate with your customers, and what will not. However, it is not enough that you know these things in your own head. More importantly, for your organization to use the knowledge you have gathered from your VoC sessions, you will need to find a way to express this wealth of customer understanding so that the organization can consequently make changes to the product roadmap, engineer specifications, and marketing material. To do this, the first thing we must do is to determine customer requirements in a way that is digestible by the rest of the organization.

Customer requirements express what the customer will be able to accomplish, what the product will be able to do, or how the product will be able to satisfy the customer's need to achieve something. Product requirements are not specifications or descriptions of how a product meets customer needs, but are merely statements of what the customer will be able to accomplish, be able to do, be able to obtain, or be able to resolve as a result of your product or service.

Developing product requirements is typically the responsibility of product management or marketing in an organization. These product requirements take the form of an MRD (see Chapter 2, VoC in the Product Development Process), and are given to engineering, whose responsibility is to take the requirements received and create a document describing how the design specification will satisfy this customer's needs.

As mentioned previously, the reason most products fail is because the customer requirements are not wholly or accurately expressed. Either this is because the organization did not undertake sufficient customer research, or the team did conduct effective customer research, but the translation from the customer's voice to the product requirements was flawed.

When we think about developing product requirements, many other elements must be considered, and stakeholders must be involved. These stakeholders are internal stakeholders in the business, as well as customer stakeholders who are also participating in purchasing, installation, commissioning, maintenance, usage, disposal, and justification. There are a number of different types of requirements we should consider when developing a product, but there are two that come to mind immediately: functional and non-functional requirements.

A functional requirement describes what a product or offering should do, while a non-functional requirement places constraints on how the system or product will do, or how it will relate to a quality the product will have... In essence, how the product will work for the customer.

A company's e-commerce site must send an email whenever a particular action is initiated by a customer – for example, when a visitor to the site signs up to join the email list, they change their shipping address, they place an order or initiate a return, and so on. A non-functional requirement for this example would be that the customer must be notified within an hour of the time the condition changed state.

Another example of a functional requirement would be: "A car's overhead light will turn on when the door opens." The associated non-functional requirement would be "how long the light will stay on after the door closes" and "how bright the overhead light will be.".

Examples of functional requirements include:

Some common non-functional requirements include:

In addition to the two previously mentioned requirement types, product managers should look at two additional requirement types: business requirements and constraints.

Business requirements relate directly to the business outcome the customer desires. Many times, this is expressed directly or indirectly in the form of economic value to the customer. For example, the customer may wish to increase their efficiency, reduce overhead, or enhance their productivity to contribute to reducing their overall costs.

Some possible examples of business requirements include:

Constraints are limitations or strict guidance the product team has in place when developing the product. These create boundary conditions that the product must adhere to. Examples include: