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.
Saeed