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.

by Mike Marfise

A recent blog post on The Forrester blog for technology product management and marketing professionals highlighted an interesting concept related to a product team’s dilemma when striving for customer-centric innovation — use cases vs. feature descriptions.

The use of user stories and use cases has been around for years, yet many companies I have worked with seem to skip this step or, to be frank, have not done a good job of understanding their customers’ needs. As stated in the blog post, understanding the customer’s needs and business problems is paramount to understanding how to solve those problems. That said, it’s equally important to define the requirements or features that your engineering team will eventually design, and develop a product/solution to suit. Ensuring that there is a collective understanding of the customer and their needs throughout the product innovation lifecycle is mandatory for delivering successful products to the market. In software, for example, it goes beyond production and should continue into the pricing, packing, and commercialization of that product.

So why have so many companies done a poor job of this? Simple… TIME! It’s one thing to say, “I understand my customer.” It’s another thing to spend time with enough of them to understand their collective challenges and look for opportunities to innovate. Let’s face it, if we just did everything a few customers asked for we might never invent new products or categories. So how do you get to more customers quickly, and how do you get a deeper understanding of what challenges they face? Putting the customer at the center of your innovation process starts with listening to them. With modern technologies such as web-based communities, idea portals, online surveys, and social networks, access to your customers and their ideas has become increasingly obtainable. But it still requires that, first, you either get them to participate or you go to where they are already talking and listen in, and second, that you have tools that allow you to analyze the information such that you can reduce the time it takes you to transform those ideas rapidly into qualified product concepts and ultimately to new market offerings.

Here are some suggestions on how to increase the velocity in your innovation process:

1. Identify where your customers are discussing their challenges. For some companies this may be in their backyard: support sites, web site, company-hosted communities. For others, the conversations may be on public sites such as forums, blogs, or review sites like Amazon or CNET. Don’t assume they are not happening – they are!
2. Determine the best way to reach out to your customers. This will most likely be a combination of initiatives, depending on the answer to #1. If they are coming to you, building a community to gather and harness the collective wisdom and insights of your customers is a great approach. If they are already heavily engaged in a wide range of conversations on public sites, using an application that can discover and deliver those conversations to you will be much more successful.
3. Establish a process for vetting and prioritizing what you hear. Once you open the flood gates and begin gathering this insight you need to be prepared to process this QUICKLY! Establish gates and metrics you will use to evaluate these conversations. Determine how to take the next steps in prototyping, validating, and executing on those new ideas, and who will take those steps.
4. Communicate results with your customers. Often this step is an afterthought or done only when products are out the door, via marketing. In the modern age of marketing you should leverage those same vehicles where you gathered the insight to communicate progress and even solicit additional feedback along the way. When customers are invested in your innovations they are more likely to remain loyal to your products and your company. Additionally, they will spread the word much faster than you or your company ever can.