03
Nov 14

A New Product Management Lexicon Opens The Door To A Better System Of Record

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!).


30
Oct 14

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? 

The workshop will cover version 1.0 of such a system of record. Maybe version 0.1, to be honest. It would be great if you could join me! Again, it’s the Product Summit in SF, November 20-23.