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.

02
Oct 14

PM Tools Should Help Us With The Hard Things We All Do

What are some of the annoying, hard things you have to do as a product manager? Here are two common situation from my experience. I wish the PM tools out there would step up to helping me do these more easily.

I sometimes get features that are only partially implemented, with respect to the original story or requirement. If the tool automatically understood in its guts that a requirement can be partially implemented, and that it might need to be decomposed along those lines so the remaining parts of the feature could be implemented later, it would be a big help. Perhaps a wizard that guided me in decomposing the requirement. It could ask questions like ‘is this requirement 100% completed?” If I say “No,” then it asks “Is it partially completed, and if so, what part? What’s the value proposition of that part?” “Do you want to take any of the existing requirement and turn it into a new requirement for implementing later?” And so on.

Of course, I want the tool to maintain the relationships in the process. E.g., the new requirement should be related to the original, probably with an “Enhances” relationship. Or it might be a “Delighter” relationship. (Because what didn’t get done is usually the “nice to have” portions, not the “table stakes” portions.)

Another thing – I need to write a datasheet entry for the feature, or a release note. Why do I have to go to Word to do this? Why doesn’t the tool have a place for the datasheet blurb related to this feature? And then the ability to write a draft datasheet based on these entries for the features implemented in the upcoming release?

I have to do these things anyway, and often I just try to do them in my head, which means that the next thing that I have to pay attention causes this one to drop on the floor, which means I have to rediscover it later, at a great cognitive cost. Since I have to do it anyway, let’s have the tool become the capture spot for it – which means it needs the right semantics to capture it, and it probably needs to remind me that it needs to be captured, because after all, “I am a product manager, big of head, and I will remember.” Which I won’t, really.


29
Sep 14

Is Your Lack of A System Of Record Leaving You In the Stone Age?

I have done a bit of guest posting lately, and this week’s entry is about a new essay on Mike Smart’s Product Management 2.0 site. As long-time readers know, I’m a proponent of getting product management into the “big leagues” with better tools, and particularly, with a good system of record for the full lifecycle of product management. “System of Record: Why You’re in the PM Stone Age Without One” puts a stake in the ground about what product management needs to insist on to become a modern business process.

Almost no company has a legitimate system for product ideas and input, or front-end customer interactions (i.e., interviews, ethnology, market discovery and research). Likewise, typically there is no system of record for product marketing (i.e., value proposition, benefit statement, go-to-market plan). Instead, all of these are stored in various spreadsheets and documents, but not tracked or managed.

The benefits of tracking all the information related to product management – from customer interviews, to market analysis, to competitive positioning, to roadmaps, to the value proposition, to the go-to-market plan – are immense. They range from the obvious, like transparency and collaboration, to the subtle, like the fact that product managers have more time and attention to spend innovating and learning about market problems to solve.

I’ll be following this essay up with a post on this site about how to build a real system of record, even if you don’t have all the tools you’d like.

In the meantime, take a look at System of Record: Why You’re in the PM Stone Age Without One.