Month: July 2007
How often do you take time out to break down important data about your product? It’s easier than you think: [Web] Analytics According to Captain Kirk.
Hello. We’ve been at this for a couple of months now, writing about various PM related (and sometimes unrelated) topics. And while we will continue posting as we see fit, we also want to hear from you about what topics you’d like us to cover.
Now that may be atypical of blogs, to ask readers what they want to hear about, but being Product Managers, it would be unnatural of us not to ask.
Is there something about Product Management or Development or Innovation that piques your interest? Want to know more about product pricing, positioning, process or partnerships? Any interest in SaaS or Agile? Want to know more about designing demos? Got a burning question you want to ask?
- What would you like to read about?
- Is there anything we’ve written, that you’d like to see more of?
- Is there anything we should stop writing about?
Let us know.
There are a lot of good posts out on the Web about hiring product managers. One of the most popular ones that I’ve seen is entitled “How to Hire a Product Manager“. In it, Ken Norton writes that hiring managers should do or look for the following:
- Hire all the smart people
- Strong technical background
- “Spidey-sense” product instincts and creativity
- Leadership that’s earned
- Ability to channel multiple points-of-view
- Give me someone who’s shipped something
In summary, hiring managers should look for smart, technical and creative people with good instincts and leadership skills, who can assimilate multiple inputs and who ideally have been product managers before. Not really rocket science eh?
To put it even more succinctly, if you’re looking to hire product managers, then hire good people who’ve been successful product managers before. OK, I may be need to give Ken some slack, as he does explain each of the points in some decent detail and provides sample questions to ask prospective candidates. None of the questions are too tough though, assuming the candidate has a decent skill set and done some reasonable level of preparation.
So that’s how you hire a great PM.
But, how can you be a great PM?
To answer that question, over the coming days, I’ll present a list of analogues to Ken’s list. Today is part 1.
Don’t just sound smart, act smart and be smart
The vast majority of product managers have no shortage of intellectual capacity. Or to put it another way: a very small number of PMs I’ve encountered have been absolute dolts. Yes, there were a few dimwits, but then honestly, in any group, there are always a few aren’t there? In general, there is no shortage of brain power in the Product Management community. But the real issue is not sheer intellectual horsepower or the ability to articulate what should be done, but the capacity to turn all that potential into a kinetic form that does the right thing.
Nothing shreds the credibility of a PM more than the perception — let me repeat — the perception that he/she talks the talk but doesn’t walk the walk. It doesn’t matter how much of anything you do, if are not viewed as someone who rolls up their sleeves and digs into details, you’re fodder for the dart board.
If a development manager asks you to clarify a requirement, and you can’t give a sufficient answer, don’t try to hum and haw your way through it. Tell them you need to research that question a bit more, then get right on it and get back with a clear and well-reasoned answer in short order.
On the flip-side, when it comes to providing information, know when enough is enough. There’s no reason to write a 60 page requirements document with dozens of requirements, when, because of development headcount or time constraints, only 5 of those requirements have any chance of getting into the next release. Who are you trying to impress? And if you didn’t know that only about 5 requirements could make it into the next release, you have much larger problem to deal with.
You’ve heard of the Doppler Effect right? No, not the Doppleganger Effect, but the Doppler Effect. Probably the most common example of the Doppler Effect is experienced when a vehicle with a siren approaches and then passes you on a street. The pitch of the siren decreases suddenly as the vehicle passes you. Of course, to the driver inside the vehicle, there is no change in pitch. And to the person on the street that hasn’t been passed by the vehicle, the pitch has yet to change.
The Doppler effect is fundamentally about frames of reference. The frames of reference of the observers in the street are very different than that of the driver. Thus, they perceive and experience the same physical phenomenon (in this case the siren), quite differently.
So, what does this have to do with Product Management? Everything.
Being an effective product manager means, being able to get into the frames of reference of others, understand their experiences, needs and wants, and then assimilate that information and convey the necessary information to those around you who need it. If you can’t do that, then your product or release may get reinterpreted many times over by each team involved. One of the most famous examples of this problem is the famous tire swing series of cartoons.
Try something. When you are at work at your desk, get a chair and stand up on it (or stand on your desk if that is safe) and survey the area around you. Does it look different? What do you see from that frame of reference that you never noticed before?
Subtle changes in frames of reference can have a big impact on what you observe and what you understand. Consider people who work in data centers. To some, the most important part of the data center are the servers executing code. To others it is wiring, network cabling and switches that connect those servers to each other. To others it is the storage that holds all the data needed by the servers and transmitted over the network. To others, it is the cooling systems in the data center, without which the servers would overheat and shutdown. Each has their own priorities and their own frame of reference by which they view the data center.
The same is true inside the enterprise. Different teams view the world very differently. A CFO is focussed on net profit and loss and booking revenue. A VP of Sales is more focused on booking sales. Revenue and profitability are secondary concerns. A VP of Engineering is focused on delivering quality product on time. While each of these people are typically very concerned about the success of the company, their focus means they view success differently. Product Managers need to understand the differing frames of reference, and then be able to shift between frames as they work with members of different groups.
When I first became a Product Manager, I was having a tough time dealing with a number of the sales people in my company. I didn’t understand why communicating with them was so difficult. When I spoke to the VP of sales about the issues with his sales team, he gave me some advice.
“Salespeople are coin-operated. Remember that, and you’ll have no problem working with them.“
I took his advice and it worked wonders for my relationship with the sales team. Why? Because I stopped talking to them from the perspective of a Product Manager, and started communicating with them in their own language and in their frame of reference.
Nicely written article and one that addresses the likely perspective of a product-oriented organization. Fundamentally they have interest in cultivating relationships with larger vendors which inherently increases the possibility (at least) of expanding the channel.
Thanks, and yes, correct, though I’d have to say it is from the perspective of a market-driven product organization. i.e. the clash between an overall market focus for products vs. a deal-driven partner/customer focus is the crux of the problem. As I mentioned in my comment to Mike Sabat:
In a sales driven company, product follows the transaction. i.e. the company builds the product to fulfill the transaction criteria.
In a market driven company, which is where Product Management looks at overall market needs (and not strictly at individual customer needs), the transaction follows the product. i.e. the company sells what is built with little or no modification.
While sales-driven and market-driven may not sound like they are too far apart, they are almost complete opposites when thought of from an operational perspective. But I digress.
My perspective on business development however is derived from the vantage point of a systems integrator, where there are significant differences between services and product. As someone who has spent over 20 years within federal business development, the term implies an understanding of all aspects of winning business.
Companies that sell services, or sell products which include services, are almost always transaction-oriented, and therefore sales driven. I can sell you my generic product, but also sell you services to customize the product for you in some way. As soon as the services component comes in, even if the service is simply to help someone choose a product, the particular needs of the individual customer drive the activity.
In aggregate therefore, business development experts within the federal marketplace should have all those aforementioned qualities to be successful. Suffice it to say because of the level of comprehensive knowledge required, their expertise is always welcomed. Hope that helps. Jim.
The aforementioned qualities laid out in James’ comment are: Sales, Marketing, Capture Management, Proposal Management. What James describes is a different type of business development than what I was describing. In a product development company (vs. a services company), BizDev is usually part of of the Channels organization. It’s goal, as James mentions, is to expand the channel. But the issue that has frustrated me is the way many BizDev managers go about it.
Sales people are told to sell the current product. They can’t sell futures and they can’t make promises of future functionality, even if it is “on the roadmap”. But BizDev managers aren’t always held by these rules, even though they are fundamentally also sales people. I’ve seen too many cases where they sell futures (in the name of being strategic), and they discuss issues that are way off the roadmap — like the IBM mainframe port I mentioned previously. When this happen, serious misalignment occurs.
I have no issue with BizDev or Strategic Alliances in general. I see the need for them clearly. But I also have the responsibility as a Product Manager to do what is best for the product and the company. And much more often than not, that means saying “No” to rogue BizDev managers (and even, with some professional risk, Senior Management), when they go “off roadmap” and start looking for that “company making deal” (I’ve heard that phrase far too often) with some gargantuan organization that frankly, is going to waste a lot of our time, and is unlikely to ever close the deal from their end.