The Customer

The customers buy the product. You have to understand your customers well enough to specify a product they will buy and find useful and pleasurable.

The customers buy the product once it is developed. Perhaps you already know the names of your customers, or perhaps they are hundreds or thousands of unknown people who might put down their money and walk out of the store with your product under their arm. In either case, you have to understand them well enough to specify a product they will buy and find useful and pleasurable.

Sometimes the customers are also the end users of the product. This happens when the product is sold via retail channels and aimed at domestic or small-office users. In other cases, your customers may buy your product for use by others. For example, you may be developing a new intranet product. In this case, your customers are the office managers who buy multiple copies of your product and expect their office staff to use it.

Even if you are developing open source software, you still have a customer. The difference is simply that no money changes hands.

You must know what appeals to your customers. What requirements will they pay for? What will they find useful? What window-dressing features are attractive, and what is downright trivial? Answering these questions correctly makes a huge difference to the success of your product.

For the IceBreaker product, the Northumberland County Highways Department has agreed to be the first customer.^[1]

^[1] The original Vaisala deicing prediction system was built for the Cheshire County Council. The designers of the product were Thermal Mapping International and The Computer Department. The product is now installed by all counties in the United Kingdom and has thousands of customers overseas. www.vaisala.com

The customer for the product is the Northumberland County Highways Department, represented by director Jane Shaftoe.

As there is a single customer (at this stage), it would, of course, be advisable to invite her to participate as a stakeholder in the project. This kind of outreach results in the customer being actively involved in selecting which requirements are useful, choosing between conflicting requirements, and making the requirements analysts aware of her problems and aspirations.

Saltworks Systems has further ambitions for the IceBreaker product. The company suspects that a successful ice forecasting system could be sold to road authorities in other counties and other countries. If you plan to build the product with this aim in mind, then your requirements specification should include an additional customer statement:

Potential customers for the product include all counties in the United Kingdom as well as northern parts of North America and Europe. A summary of the requirements specification will be presented to the Highways Department managers of selected counties, states, and countries for the purpose of discovering additional requirements.

It is clear that the customer should always be represented on the project. Where many potential customers exist, there is a need to have a customer representative. This representative can be a member of the marketing department, a representative from a user group, a senior user from one or more of your key customers, or a combination of domain and usability experts from within your organization. The nature of your product, the structure of your organization, your customer base, and possibly several other factors will decide which roles on your team represent the customer stakeholder class. For consumer products or shrink-wrapped software, you might consider using a persona. The decision to use a persona should be made here. We have more on personas in Chapter 5, Trawling for Requirements.