Following up on my post yesterday about a new Product Management lexicon, where I said we should lose “requirement” and start saying “feature.” The next question is, what do we call what we used to call “requirements management?” “Feature management” sounds dumb. “Solution management” (referring to the fact that we’re creating solutions to customer problems) already means something else. This is an open question.
But maybe it’s for the best. Thinking about requirements has focused us too much on the solution piece anyway, ([tweetthis]Thinking about requirements focuses #prodmgmt far too much on solutions, rather than problems [/tweetthis]) and leaves out all the other important stuff we do, like:
- Talking to customers, prospects, and competitors’ customers all the time
- Discovering and validating market problems
- Doing competitive analysis and win-loss reports
- Creating go-to-market materials
If we just think of ourselves as “requirement pushers” we forget about those other things. More importantly, we let the tool vendors off the hook for our system of record. They just build requirements tools and forget about all the market information we gather, and the go-to-market materials we create. Those just get to live in Sharepoint (ughh!).
