The actual documentation of new product or service requirement is clearly an internal function. Often it is a collaborative effort between sales, marketing, development engineering, and, of course, product management who takes the lead role. These groups need to be involved, and trade-offs will always need to be made. Each of these groups does need to have one thought in common; they need to think of themselves as scribes and not sole authorities. Their primary role must be to capture the desires of customers, prospects, and business partners. Requirements need to be externally driven by the said and unsaid needs of these groups.
Too often product requirements are based on a comparison of the company’s current offering to those of competitors or are driven by incremental improvements. Perhaps fairly, but most likely driven by ego, developers take the position that they, not customers, know what to do because of new technological advances. In many cases, that observation is correct. Apple Inc., for example, develops capabilities that most customers never thought were possible. In so doing, Apple and a few other companies, regularly raise the bar for an entire business sector. However, these advances, unforeseen by customers, need to be held to the same simple standard. They, like all other requirements needs to be able to be clearly stated as:
How will this requirement positively impact the customer?
This seemingly simplistic question can have major impacts on the entire development process. It can, for example, stop a developer from including a “neat” capability or a sales rep requesting a feature that was unique to one prospect that selected another company.
The article in this collection, “Fast, But Not Too Fast”, discussed some of the considerations regarding agile, iterative product development processes. Key to this approach is the involvement of customers or project “owners”. With this model, the customer or project owner is “leading the charge”. If, however, the project owner is not the external customer, care must be taken to keep external customers or prospects involved.
One of the downsides to the agile approach with regular, perhaps daily, involvement of the customer is the tendency for the customer to fall into the trap of rescinding or modifying their requirements based on direct feedback from the development team. A developer may, for example, bring up how difficult or time consuming it will be to develop a certain capability. The project owner or customer, during the discussion may relent only to satisfy the developer. Later, the owner may reinstate the requirement much to the dismay of the developer and risking the schedule or product itself.
The article, “Best in Another Class” discussed the notion of looking well-past the current market segment for capabilities that could be used as benchmarks for the current development effort. In this case, customers in other segments may be unintentionally, but importantly, leading the charge. This is especially applicable when the new product is targeted toward a different market or segment. As one obvious example, a domestic product may be quite successful. However, domestic customer inputs may be off-base for non-domestic applications. As one example, consider the difference in requirements for an accounting system in the US versus the requirements in a Third World country.
Determining who should lead the charge in developing requirements needs careful consideration. For sure, it should not be internal resources alone.
