Product management isn't a hard job. At least not in the traditional sense. It's not astrophysics, curing cancer, or trying prove that P=NP. As long as you have the necessary technical knowledge, it involves a lot of common sense and mountains of organizational skills. As Adam has told me many times before, it's like writing an open book test, the answers are all right there, you just have to know where to look.
One of the most challenging things that I've found about the job is the paradox of having to manage without having any actual authority. This problem is compounded when in addition, I have very little experience...and I'm also very little...and kind of look like a 12 year-old.
Narrowing in on locking my first product, I've found myself doing 2 things, when my product decisions are questioned or an alternative is suggested.
The first is second-guessing myself. Though I have spent quite a while studying technology and usability theory, everything functions much differently in the real world (i.e. not in a vacuum), and seriously, what the hell do I know? Though questioning your own logic is a good practice in theory, it can lead to some serious analysis paralysis over micro-decisions. And eventually you might have a developer come to you and say that in the time it took you to decide whether or not a requirement should be implemented, he already finished it. Yeah...ummm...oops.
Eventually after I've worked it through, and if I've come to the conclusion that the few brain cells I have left after excessive drinking could possibly be functioning properly, the second thing I stumble over is trying figure out how to come out with the explanation that X is the best decision in this case. Funny enough, though somewhat of an uncomfortable conversation, no one has thrown anything at me or called me stupid...yet. That I've heard. Which is a win in my books.
There aren't hard and fast solutions to either of these problems. When you're getting input from other members of the team, it's important to find that right balance where you're considering other opinions, but not to the point where you might compromise the product vision or usability to include or cut certain requirements. Asserting yourself to other team members is very touchy on your first product release, with no proven track record of success, sometimes the best solution is to recruit the help of a more senior PM. As long as they're not always doing your dirty work for you.
Thankfully, though I am learning all these lessons, it has been surprisingly pain-free. Though that might have to do more with the fact that I work with some serious rockstars that make my life so much easier :)
Wednesday, November 28, 2007
Subscribe to:
Post Comments (Atom)
TwitThis
3 comments:
Your two reactions:
1. Speaking of whether P=NP, second-guessing yourself can continue long enough that the halting problem comes into play. So product management *is* a hard job. (You fool, saying that it's not! Don't you want a raise? Oh right, I just re-read your last sentence.)
2. To prove that your decision was wrong cannot be accomplished in polynomial time, so you're safe. But just in case anyone wants that silly stuff called "evidence", fortunately this is easy to come by. Since you are starting out as a product manager, allow me to introduce you to the magic of the focus group. Assemble one (it's easy: just offer homeless people a few bucks) and ask their opinion, then alter the question repeatedly until the opinion is the one that backs up your decision. For instance:
Q. Should the product include a burple feature?
A. I don't think so; it's a pretty good product as it is and I don't think it needs it.
Q. Should a situation ever arise where a burple feature would save the lives of you and yours, would you want it?
A. I really can't imagine such a situation.
Q. But just supposing?
A. Well, sure.
Q. Thank you.
Product management, at least for me, is one of the hardest jobs I ever had. The reason for it is specifically because it is not science.
You need to know a lot of a lot of disciplines and you need to polish up all of your soft skill for it, where managing without authority is only one of them.
For me, the part of asserting authority seems like one of the most important aspects of dealing with R&D teams. When doing that, you need to make sure you honor the engineers you are working with, explain them why you want things and what is the big picture, show them that you value their inputs, but that in the end - the decision is yours to make and the head on the plate is yours as well.
Further to Tsahi's comment, one big advantage you have over other product managers is your technical credentials. Rightly or wrongly, software developers tend to be much more willing to follow the opinions and decisions of those product managers who know their technical stuff. (I used to point this out on my resume, until my technical cred became stale.)
So throw around those comments about how you're interested in adding such-and-such feature but you're worried that it can't be done faster than O(n squared): watch the programmers jump to help solve the problem.
This is a highly contrived example, but in general I do believe that you will come out ahead by demonstrating your technical competence. Partly it's about "earned" respect (soldiers have more respect for up-through-the-ranks generals than those who have been desk-bound), partly it's because they can better able to relate to you as a person (to illustrate with an extreme, most programmers do not relate to rise-and-shine kill-the-competition frat-boy product managers), and partly it's because programmers are all too familiar with the quality of decisions arising from uninformed "management" such as Dilbert's pointy-haired boss.
Post a Comment