Spider-Man Vs. Megatron: A product manager in action? (Image from Wikipedia)

The Product Management blogosphere has been atwitter, and a-Twitter, with the question of the best metaphor for the role of product management. Is a PM the captain of a product as Christopher Cummings suggests? Or, going back to the old tropes, should we think of them as mini-CEOs of their products (one is always tempted to believe the Cranky Product Manager, isn’t one)? Or are they cat herders - and does that explain anything? In any case, Saeed wants to make sure we don’t undermine ourselves with unsavory metaphors like “glue” and “grease.”

Product management is a complicated and multi-faceted activity, and each of these concepts offer useful guidelines as we strive to create successful and useful products that kick ass. But there are several other characterizations I’ve found helpful over the years both to understand what I do, and to explain it to others. Since they’re not common, I would like to share them (over several posts):

The Product Manager As Transformer

One aspect of the product manager role is to do impedance matching.

From Wikipedia: The term ‘impedance’ means the resistance of a system to an energy source. For constant signals, this resistance can also be constant. For varying signals, it usually changes with frequency.

Impedance is an unfamiliar concept if you’re not an electrical engineer or a ham radio operator (I was KA6HAJ). But it basically means the resistance of a medium to information transmission, usually between components of different types. I think we can all agree that customers and developers are “different types” - and there’s naturally a communication barrier.

The product manager’s job is to bridge that barrier. In the language of electronics, the product manager is a type of transformer.

Wikipedia again: … [transformers are] used extensively in modern communications, particularly in frequency conversion mixers to make cellular phone and data transmission networks possible.

The product manager takes the signal from the market - needs, desires, complaints, misunderstandings - and transforms it into a signal that the engineering organization understands - requirements, specifications, defects, enhancement requests, and so on. Likewise, the product manager takes the signal from the engineering organization - a product with features - and transforms it into a signal for the market such as a value proposition, a set of benefits, and talking points.

Of course, like all the metaphors for product management, the transformer can only be taken so far: A transformer is a linear device, so the outputs are directly related to the inputs. A good product manager, however, will transform the inputs in non-linear ways - thinking outside the box to take the product to the next level.

Next: The Product Manager’s Purpose In Life

In my next post I’ll talk about the “highest cause” of the product manager:

As an employee, at a high level your highest cause can be yourself, the company, your fellow employees, your customers, or the product. Obviously, the highest cause of senior executives is - or should be - the company. The highest cause of the support organization and usually the services organization is the customer. Of course, by focusing on the success of the company, the executives also work to the benefit of themselves, the other employees, the customers and the product. And likewise, by focusing on the success of the customer, the service and support orgs benefit the company, their fellow employees, and the product.

The highest cause of the product manager, in contrast, is the product.

Do you agree or disagree with these characterizations of product managers? Let me know in the comments.

Q1: What are the top three Requirements/Features in your next product release?

Q2: How do the top three help address your long-term product strategy?

Q3: If you had been planning this release six months ago or six months from now, would the top three still be the same?

I have often found it easy to answer question 1, and not so easy to answer 2 and 3. If my boss asks me to answer 2 or 3 I would stall or if forced say something like “We should not do that; we are an agile company, our priorities change every day”.

But is that right? Is saying our priorities change every day almost the same as saying “Everything is a Priority”? Shouldn’t we strategize, prioritize and plan? One noted expert in the field, Karl Wiegers, states: “One characteristic of excellent requirements is that they are explicitly prioritized.”

Of course, any discussion of business priorities today has the following adages behind it:

1. In today’s world, you have to be agile, so we have to be fluid and accept change
2. In this economy, we are end-of-quarter driven, so priorities change each quarter

I observe the above but do not accept requirements change WITHOUT communicating the impact of making the change. In other words, state something like “Yes, we can consider that change and we should understand its impact on ________ and ________”

To help others make the decision, I find it is very helpful to list the pros and cons in two columns, it doesn’t hurt this method is ascribed to Benjamin Franklin:

An investment in knowledge still yields the best returns. - Benjamin Franklin

People will accept your ideas much more readily if you tell them Benjamin Franklin said it first. - David H. Comins

(image courtesy Blackberry Studio)

Each requirement has a web of relationships with customers, stakeholders, market elements, risks, and competitors

In my last post I talked about the fact that agile methodologies are all about “doing the most important thing first.” This post is about figuring which is the “most important thing.”

As a product manager or product planner, how do you reconcile the following:

• Too many ideas
• Too many customers clamoring for their pet enhancements
• Engineering teams who have lots of “cool” things they want to implement
• The sales force screaming about the “must haves” of today’s “deal of the day”

Prioritization is a problem whether you’re doing waterfall or agile, and whether it’s a new product or an existing product. In the agile context, you have to determine your most important story, then execute on that story. Then on the next most important story, and so on.

This is easy to say, isn’t it - just do the most important thing first! But there’s a slight problem - how do you know what’s most important? If you’re a product manager or product planner, you have many constituencies, each with their own set of priorities, and each with more than you can possibly accomplish. You have to consider: customer needs and their desires (often as important as needs); company goals and strategies; your technical capability to execute on the story; tactical sales force needs; and let’s face it, personal assessment of the importance by everyone from the product manager to the engineer to the CEO herself.

And if you don’t come up with a prioritization someone else will - maybe an engineering manager, maybe the VP of Sales. And they’re not in a position to necessarily make the best decision for the company as a whole.

Now once you do make a decision, as the product professional, how do you justify it when those with axes to grind seek you out, or call you on the carpet in the executive board room?

For all these reasons, you’d better have a system - and it’s best if that system is visible, takes into account the interests of all the stakeholders, and in general helps you find the “right answer.” It’s even better if the system is not just qualitative, but quantitative, and traceable. This sounds a little like a spreadsheet, but as lots of product managers have discovered, spreadsheets have a host of problems:

• It’s hard to represent all the relationships you want to capture - to customers, market themes and other strategic elements, risks, competitors, etc.
• They aren’t very transparent
• They are terrible for acting as an enterprise knowledge base (if even stored in a sharepoint or wiki), and
• Who wants to, or has time to, create a big spreadsheet model?

So, you want something that’s a little like a spreadsheet, but is also

• Transparent
• Enterprise
• Purpose-built to handle the desired relationships to customers, market segments, competitors, risks, and marketing themes.
• Provides out of the box analysis

Well, I have one of these, and as a PM who didn’t have one in my last job, I must say it’s changed my life.