Should Product Managers Know How To Code? Steve Jobs Couldn't...

This is the problem. The problem is you're a developer at your mid-sized company, working directly with sales or analytics or whatever team you support, but you notice your projects aren't coming out quite... right. There's always some important interface feature that is missing, for example. "What if I want to bulk delete the list?" the sales team asks you, and you had no idea they wanted to delete anything from the list, let alone in bulk.

"It would be so nice," everyone starts to think, "if we had a product manager that actually had time to think about this stuff and manage communication, requirements, and expectation."

So you hire one.

He has no prior expertise in your industry vertical and he has no programming background whatsoever.

Things are immediately rocky. Rather than manage expectations, he seems to inflate them. He's constantly trying to cram every new project and feature request down your throat. Any estimate you give him is questioned. While he has no programming background, he knows enough about tech to suggest terrible alternatives that will save a couple days of development time at the cost of huge technical debt. Meanwhile, any suggestions you have fall on deaf ears. You notice areas where the sales team is doing things really manually and suggest enhancements, but he's not being judged on how well he listens to engineers.

Before long you miss interacting with the sales team directly, because even though they asked for completely pointless things that were technically impossible anyway, at least they listened to you when you explained why it was pointless and impossible.

So you grit your teeth and bear it, and wait until the company has a down quarter and needs to let people go, because product managers are almost always on that list.

---

I've worked with several product managers in my career, and the easiest heuristic for how effective they truly were and how much engineers liked working with them was whether they had a technical background or not. Being a good software product manager is hard. You have to understand the cost of technical debt. You have to understand that engineers have good ideas too. You have to understand the tradeoffs of projects with long-term value. If you're a product manager who used to be a programmer, understanding all of the above is very obvious. If you're a product manager who was never a programmer, maybe you're Steve Jobs.

But you're probably not.

--

He was exactly the same way he was at Apple: strongly opinionated, knew what he was doing. He was so passionate about object-oriented programming. He had this extraordinary depth. I have a PhD in this area, and he was so charismatic he could convince me of things I didn’t actually believe.

I should tell you this story. We’re in a meeting at NeXT, before Steve went back to Apple. I’ve got my chief scientist. After the meeting, we leave and try to unravel the argument to figure out where Steve was wrong—because he was obviously wrong. And we couldn’t do it. We’re standing in the parking lot. He sees us from his office, and he comes back out to argue with us some more. It was over a technical issue involving Objective C, a computer language. Why he would care about this was beyond me. I’ve never seen that kind of passion.

--

http://www.businessweek.com/magazine/eric-schmidt-on-steve-j...

This doesn't mean the product manager must understand code. It means there's a trade-off. If they don't understand software implementation, they need somebody on the team who does (what the article calls a "Technical Product Manager.") Adding another person is possible, but it hikes up the overhead and communication costs while dragging down the speed of development and decision-making.

The best case is a product manager who can understand a given implementation if and when it bears on decisions about what is possible in the interface or the production schedule. That person can make informed decisions because they understand all the factors.

It's fine that not everybody can do all three, but imo we should stay conscious of the trade-off and keep the bar high.

The best rule in life is "there is only one Steve Jobs".

Isn't that just a ridiculous argument?

    "a product manager is more or less the CEO of a product line"

In my ideal company, the product manager role would rotate among the developers. As many as possible should be doing, not creating powerpoints and writing emails.

The Microsoft "program manager" job description is one I respect.

I let the "CEO of a product line" slide, but the above comment had me seeing red. A product manager thinking programmers are his minions? I guess it might be true if the programmers are so incompetent that they can't see through a blowhard who pretends he knows the code base.

Having a person (of whatever job title) between a developer and the user is a bit like having a patient telling the nurse what's wrong with them and the nurse then passing along that description to the doctor so they can write out a prescription.

I don't know how to code (well, anyway...), but I try to take care of the dirty work so that the development team can focus on doing, you know, development. This means figuring out the flow of transactions (we work with web services, and expose our own web services to clients), field level details, managing the intake of feature requests, figuring out why certain things are broken or behaving in unexpected ways...

Basically, I move all around to make sure the developers are able to focus on they are able to do, and protect them from the headaches that upper management and business sponsors produce. I try and manage the goals of business asks and user experience with the abilities of our development team. If there is a major change in design or scope, I make sure to consult with the development lead before I commit to anything.

I don't assume to be more important than any developer, or that I know more than them. I understand what my role in the organization, and my relationship to the development team, and I know who is doing the work that makes us all look good.

I don't know if this satisfies any developers who read this, but this is what I come into work trying to accomplish.

Ok, so let's be fair. I'm sure there are totally lazy teams of developers out there. But somehow, I doubt that's the case as often as the author thinks it is.

"I don't need to know how to code. Why aren't you listening to me?! Must be laziness on your part."

So while Jobs might not have been able to code, he'd done some engineering and I think had a keen sense of where the approachable borders of software lie.

Huh? This whole article is a bunch of semi-circular fluff.

Having a PM who can't code is akin to having a college-fresh MBA running a factory. Will it get the job done? Yes. Is it wise for the long-term health of the company, the fluidity of operations, and the happiness of the workers? Probably not.

A PM who can't code is a PM who doesn't understand why feature A takes an hour, while feature B takes three weeks. Do you want your engineers spending stressful hours upon hours explaining how and why things are, or do you want them working?