Why Product Management is like Raising a Child++

An awful lot of people call themselves Product Managers, or want to steer their career there.

Let's face it: it's mainly because the PM role is said to be like being a CEO within a company. Actually, it's better: all the perks without the headaches of being an actual CEO. You can choose to schmooze with people you like, you don't have to manage or fire anyone, and most of all, you don't have to lie awake at night worrying where the next operating dollar is coming from.

In many companies the PM's call the shots. They are connected to senior management (or are senior management), connected to the customers, connected to the $. They call the shots. The engineers scream, argue, moan, and whimper, but in the end, the engineers pretty much aim where they're told. In fact, the distribution of people quality (smarts, competence, etc.) in these companies tend to be proportionate to this power balance. And they are a particular kind of company, closer to the manufacturing or distribution end of the spectrum. Google and Pixar are closer to the creating end. The engineers are in charge of the asylum there.

So it's all fun and enjoyment for the PM's. Not.

The best product managers I know that product management is like raising a child and more, first from a parent's perspective, then from the world at large. The phases span the gamut:

1. Flirting
2. Dating
3. Enjoying
4. Conceiving
5. Bearing
6. Birthing
7. Feeding
8. Playing
9. Enjoying
10. Teaching
11. Yelling
12. Planning
    
13. Pushing
    
14. Advising
15. Talking
16. Watching
17. Enjoying
18. Growing
19. Slowing
    
20. Dying

70% of product managers I've come across can't get past #3, another 20% lose interest after #9. Not to belittle the painful child-bearing and birthing process, as any good parent knows, it gets even harder from #10.

This makes only 10% what I consider real product managers, and perhaps 10% of them are really good at it. So I consider only 1% of the people I've come across with the title Product Manager are really committed to it and are really good at it. They also tend to be super well-grounded in the technology they manage (so they can credibly push back at the brilliant engineers they deal with when they get BS or genuinely empathize with them when they introduce the next impossible feature request).

So my suggestion to engineers coming out of school with the ambition of getting into product management on their way to CEO-dom is: don't be in such a hurry. Get well grounded. It will take 5+ years. There's a spectrum of coverage you can't skip from intelligence to knowledge to experience. There is no real learning but by doing.

Or you can become the other 90% product managers. Or get lucky, which would be unfortunate, but that's another topic altogether.

A very wise mentor of mine once observed, "In my time, I've seen an awful lot of super-talented engineers become super-talented business people. But I've yet to come across a super-talented MBA become a super-talented engineer."

How To Innovate With or Without a Better Horse

If I'd asked people what they wanted, they would have asked for a better horse.
- Henry Ford

This quote has been variously repeated sometimes with "better horse", sometimes with "faster horse", but almost always accompanied with an assertion: this is proof that you should therefore not listen to your customers ("strong form"), or a reminder: that you should listen to them with more than a grain of salt ("weak form").

Lots of arguments ensue. Steve Jobs's name is invoked as proof that not listening is required for fundamental innovation. "You completely misunderstand Ford," someone else would suggest. Parties agree to disagree, somewhere in the middle.

I don't know what Ford meant when he said it. I also don't know why this has to be so complicated.

Innovation is, fundamentally, Problem Solving. And Problem Solving, for as long as as I can remember (*), starts with the Problem Statement. Asking what people want is not asking for the Problem Statement; it's asking for the Solution. People, busy in their daily lives and experts in their own areas---but with information asymmetry as to areas we are experts in or spend all our waking hours dreaming about---may not be as good as we are at concocting innovative solutions in our space.

But they're great at telling us the Problems they're experiencing with the Solutions we do have. So we must seek that out. Talk. Ask. Observe. Think. Innovate.

Actually, this article has a larger point than just Innovation.

In solving problems, we as teams do repeatedly fail to start with The Problem Statement, large and small. I can't count the countless times I've sat down at a meeting with the participants proposing The Perfect Idea to address whatever situation we were facing, whether it's dealing with work timezone differences between Hong Kong and New York, or what features to ship next, or when and how to do the next round of funding.

The catch was that there were invariably 5 Perfect Ideas, each orthogonal to the other, all solving different problems. And the smarter the participants, the more vociferous the arguments. Tempers flared. Egos bruised. Survival of the Fastest Mouth. Fight or Flight. Reverse Wisdom of Crowd effect. Worst: nothing gets done.

On the other hand, when we just start with the Problem Statement, go away for 15 minutes, then come to the table, we usually converge at the 1 Obvious Idea in less than 30 minutes and get it executed in the following 24 hours.

I do have a theory as to why we find it unnatural to start with The Problem Statement, but instead instinctively launch directly into Solutions. And it has to do with evolution---but that's another topic altogether.

(*) or at least since Mr. Rogoway's high school physics class. He would make us re-organize every problem in the textbook in 4 sections: Data, Question, Solution, Answer. Miss a section, zero credit. Even and especially when we could solve the problem in our heads in 60 seconds, 30 with a calculator. In the intervening years I've terrorized my own students into similarly evolutionarily unnatural problem-solving processes, to their benefit.