Requirements data: Projects, not customers
[Continuing a series of posts, started here.]
Certain words in the technology industry lexicon are so unspecific that they obscure more than they describe. Customization is one such word. Another is customer.
Who needs your products and services? Not General Motors. Not McGill University. Not the US Department of Labor. Instead, the collection of people, procedures, and problems that constitute a project define who the "customer" really is.
I learned the importance of this distinction by way of customer references. Everyone wants to have a Name Brand Customer as a reference. However, notoriety has nothing to do with customer success. A Big Name Manufacturer had less success, due to internal politics, than Dinky Manufacturer. Of course, dazzled with the glamour of working with Big Name Car Manufacturer, we wasted a lot of effort on trying to help people who, in all frankness, didn’t really value our help, because they weren’t ready to receive it.
The same rule applies to all aspects of product management, but especially to product requirements. If you’re trying to find organizations that are representative of your target customers, the project matters far more than the name of the customer.
A recent case in point, from my own experience, is Harvard University. You might think that you could learn a lot about what higher education needs from a software vendor by studying Harvard. However, Harvard’s IT organization is much less centralized than the average. (In fact, I used to advise other members of the PM team not to think a single "Harvard IT department" at all.)
Could you learn valuable lessons from Harvard? Maybe, but not about the process of rolling out a new service to a campus-wide audience.
Focusing on the project also increases the chance that you are tracking the right information. The sort of information about customers that you might find in a CRM system–their headquarters, vertical, company size, etc.–may be completely worthless, for your purposes. Far more important are details like project goals, the definition of success, the project champion, and the target user.
To use another example from higher education, Northeastern University has a world-class IT department. For many projects, they’ll be the point of the spear…But not for every project. If you want to understand how to support faculty research, you need to talk to people in the Sponsored Research office. If you want to see what people are doing to protect the university’s intellectual property, you need to talk to someone in the library. While the central IT organization, as good as it is, definitely has a role to play in both of these projects, it’s not necessarily the leading role.
Therefore, product requirements need to focus on the target project, not the target customer. Requirements information needs to reflect this emphasis.