This year’s data model
Since there are no industry-standard approaches to product requirements, most PM organizations improvise the data model for product requirements. As with any data model, over time, requirements information evolves. Even though PM teams craft their own data models, these evolutions seem to be pointing in some common directions.

Therefore, I’ll be writing a couple of posts about these evolutions in the PM data model. Right now, my data is very impressionistic. Whether or not this topic turns into some serious research, I’d be interested in hearing what you, Dear Reader, think about the requirements data model. Please voice your agreement or disagreement to the Comments section of this post.

Sometimes, these common directions in the requirements data model reflect outside efforts at standardization. For example, the Six Sigma approach suggests that you should track particular kinds of information. If you’re in the minority of product managers who use a requirements tool, you’ll have a data model suggested for you, in the design of the tool itself. (Though you’ll need to morph that data model into your own version, which is one reason why customization options are critical for requirements tool adoption.)

In many cases, a common puzzle facing product managers inspires similar solutions. One such conundrum is, "What makes one person interested in our technology, and another person not interested?" The corollary to this question is, "For whom are we really designing this technology, and do we know how to market and sell to them?"

Product managers on a role
The knee-jerk response is to look at a particular vertical, which leads to statements like, "We provide products and services for the financial services industry." Unfortunately, this is the wrong response.

To continue this example, the target customer for accounting software is, not surprisingly, an accountant. Plenty of people with that job description work in big accounting firms like KPMG or Ernst & Young, but they’re not the only people who work in those companies. Accounting is a universal activity, so you’ll also find plenty of accountants outside these firms. So, to what extent is it useful to say that you "provide products and services for the financial services industry"?

Perhaps the industry colors the tasks an accountant performs. An accountant for Archer Daniels Midland might have a different set of responsibilities, and an entirely different way of working, than an accountant for a local car dealership.

While that may be true, it’s just as likely that accounting work varies by geography more than industry. An accountant in Heidelberg, for example, follows a different set of financial regulations than an accountant in Topeka.

Therefore, an increasing number of requirements discussions start with roles, not industries. Of course, verticals are important, but they’re not the starting point. Verticals determine opportunities in that market, and they also shape the role, to varying extents. (For example, compare product management itself in the pharmaceutical and technology industries.)

If you really want to know answer the question, "For whom are we designing this stuff?" you’ll look at the role first. Still, it’s most people’s first instinct to answer by vertical. Go ahead, grab a random person in your company and ask.