You’re Saying It All Wrong – The Product Management Lexicon Is Busted

I want to explore how we can change the lexicon – the words – of product management. I am disenchanted with the term “requirements” – primarily because of the base word “require.” Nothing in my product backlog is truly “required” – and I’m not going to be able to do most of it anyway.

I’m leaning toward “feature.” Having more features in our backlog than we can do makes more literal sense than having more “requirements” than we can do. And it’s easy to say that a feature solves a problem for the customer, which is the crucial link (i.e., to the market or customer problem).

“User story” is also a problem. Based on the original definition (a customer-visible piece of value), it’s not meaningful for a product company. Almost no real feature in a real product – and features are the increment of value in a product – fits into a user story. “User story” as an increment makes sense for IT applications, but not for products.

“Task” or “work item” might be better, as the decomposition of a feature, but they hide the real value of what engineering does, which is not to implement a bunch of tasks, but to take a desired feature, and find the best way to make it.

Implications

So, if we use these newer words (and I know some people already are) what shall we call what used to call “requirements management?” “Feature management” doesn’t sound good. “Solution management” already means something else.

But perhaps this is a good thing. Focusing on “requirements management” meant that we often didn’t pay as much attention to other parts of product management as we should have – talking to customers, doing innovation, taking our products to market. Thinking of “requirements management” as the system of record for PM meant that a lot of the stuff we do – perhaps most of it – just didn’t even fit into the system of record. And that makes no sense.

So, what would be a good name for the function of the system of record for product managers? Let me know your thoughts.

Announcement

I’ll be leading a workshop on November 21 at the Product Summit in San Francisco (November 20-23) on “Creating a product management system of record using baling wire and chewing gum.”

I’ve talked in the past about how product managers don’t have a system of record – and how none of the tools in the PM space address the system of record for PMs. So I thought, what is the least work that could be done to create an MVP PM system of record? We PMs are smart, we use other peoples’ tools to do our work – what if we just take that one more step, and figure out how to think of this all as a system of record, and then add a little more structure to what we do – in the expectation of getting a lot of value out of it?