

Should Product Managers Know How To Code? Steve Jobs Couldn't... - wslh
http://bexhuff.com/2010/03/should-product-managers-know-how-to-code-steve-jobs-couldnt

======
nhashem
(getting a Page Not Found error now... Google Cache:
[http://webcache.googleusercontent.com/search?q=cache:qu58iS1...](http://webcache.googleusercontent.com/search?q=cache:qu58iS1Efa4J:bexhuff.com/2010/03/should-
product-managers-know-how-to-code-steve-jobs-
couldnt&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a))

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.

~~~
yzhengyu
Hmm, in the greater world of software project delivery, I actually see this as
a problem of misaligned incentives.

People will go ahead and make poor long-term decisions that inflate technical
debt and eventually cause product to die largely because they can disassociate
themselves from bearing the consequences. You know, like moving on with their
lives after the project goes into production and when the problems start
emerging.

I've seen this happen with many projects which I was part of. Managers telling
me with a straight face that technical debt does not matter. Engineers caving
to managerial fiat to ship features which the contract did not hammer down.

All software system failures are human failures. If your company culture,
leadership and processes can prevent this, kudos. :)

~~~
chii
Agreed - see <http://en.wikipedia.org/wiki/Conways_Law> which is exactly the
problem you described (but in a more general way)

------
equark
Here is Eric Schmidt on Steve Jobs' technical knowledge, I think the point is
pretty clear:

\--

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...](http://www.businessweek.com/magazine/eric-schmidt-on-steve-
jobs-10062011.html)

~~~
sek
Steve Jobs must have had a understanding about programming, it makes just no
sense otherwise.

He was maybe never an active coder, but i can't believe he doesn't understand
code itself. It is a skill you can learn in a day and he never was curious
about this in 30 years of software industry?

~~~
cleverjake
he started out doing hardware and software stuff for atari, but it became
obvious that he was more of a firebrand and woz was better at the hardware
side, so thats how things went.

------
rsinger9
A product manager who doesn't understand implementations will not be able to
negotiate when an implementation bears on interface design or scheduling
decisions. Conflicts arise all the time between implementation, interface and
schedule. To resolve them one has to understand all three.

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.

~~~
wslh
I don't think so, you can have some middle men to be in charge of that and
just shout very loudly if the things turn different. Obviously in this case
you need a top team that is hard to find and build and was key in the Apple's
case.

~~~
noahlucas
a middle man "shouting very loudly if things turn different" sounds more like
a project manager, who gets a specific plan and tries to manage the
development process after things have been prioritized and broken down by the
PM and a tech stakeholder (usually more efficient).

I've noticed breakdown occurs when a PM is unable to understand and balance
the constant push-pull of tech capabilities with desired functionality, or the
ability to "satisfice"

------
teyc
Steve Jobs dropped out of college, had zilch technical skills but still
managed to be employee #40 at Atari.

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

~~~
felipemnoa
The exception to the rule.

~~~
randomdata
I think it really just exemplifies the fact that marketing is king. Finding a
job at Atari or amazing the world with the iPhone is the exact same skill. A
skill that Jobs was very good at.

------
wickedchicken
Jobs had a decent amount of electrical engineering experience before starting
Apple; he helped Woz with some of the RAM layouts in the earlier computers
they made. The argument is bogus.

~~~
secretasiandan
"Jobs never did a lick of engineering in his life. He had me snowed," Alcorn
later recalled. "It took years before I figured out that he was getting Woz to
'come in the back door' and do all the work while he got the credit."

From the article in <http://news.ycombinator.com/item?id=3087492>

You're wrong. Don't worry, he's snowed a lot more knowledgeable people than
you. I would call it the key to his success.

~~~
dextorious
So, your argument is "Alcorn says so"?

------
jackbean
"Should Product Mangers wear black? Steve Jobs did..."

Isn't that just a ridiculous argument?

------
luser001

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

I haven't met a _single_ product manager who had the chops to be something
grandiose like "CEO of a product".

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.

------
idan
Yes. Most of us are not Steve Jobs.

~~~
gsharm
Actually, none of us are. And that's what makes this so hard.

------
baddspellar
"Knowing the code base is a pretty hefty requirement... even seasoned
developers don't know everything about their product... so it would be nigh
impossible for a Product Manager to do so. It's more important that their
minions think they know the whole code base, to try to keep the lazy virtuous
developers honest."

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.

------
arctangent
I like to think of the relationship between a developer and the user of their
software as being a bit like the relationship between a doctor and their
patient. One of them has a problem and the other one has special skills that
will enable them to fix it.

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.

~~~
wnight
With a single developer, yes. With five or six it's still doable to all meet
the customer and talk about your issues directly.

Beyond that you start acting as interfaces already because not enough people
can come to the meeting, etc, so you become like mini-PMs anyways. Might as
well get someone who can actually manage (track) and do it right...

I think it does help though, for you to know all your doctors/developers, but
I don't think you need to manage them day-to-day because a lot of tasks are
pretty straight forward and/or can be easily delegated.

------
kyberneticka
Here is my perspective, as a product manager at a large (Fortune 500)
corporation for the past two years...

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.

------
j_baker
_Now... what if you are a Product Manager in charge of lazy, lazy developers?_

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

------
anamax
Steve Jobs wasn't a product manager....

------
earl
I think that perhaps devs saying pms should be able to code is really more
like devs want pms to have a deep sense of what can be done with software,
what can't, and roughly how difficult things are. You can have that knowledge
without being able to code yourself, but I'd bet the fastest way to acquire
such knowledge is to learn to write software yourself.

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.

~~~
aufreak3
That knowledge is pretty hard to come by _even_ if you know how to code, so
not having thought computationally .. ever .. makes for a really bad PM.

Computational thinking and prototyping skills are the key, even if you use
another human to do the prototyping, knowing what to bother protyping and how
to learn from the prototype are all very important for a PM. If you dont have
those skills, you don't have the means to discover the limits of what you know
about the area your product grapples with, and to grow.

Steve Jobs, I believe, was very good at both.

------
georgieporgie
_programming skills are primarily useful to a Product Manager as a
communication technique_

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?

~~~
wnight
You can have a completely non-technical PM, I've found, as long as they still
get to know their teams, the problem domain, etc... The type of person who
proudly professes their ignorance of something is not cut out to be a PM. But
much of what a PM does is take the bookkeeping off the backs of the developers
so they can go to the issue manager and just read what pertains to them.

A good programmer should never need to lie to his PM to push-back. Knowing how
to put your foot down is an important part of delivering a working product.
And a good PM should never need to browbeat or threaten the team.

If, for instance, they feel a quick release is essential but the developer
feels the product isn't stable (race conditions under customer-levels of load)
neither is flat-out wrong. Even with the CEO yelling at the PM yelling at the
developer they shouldn't bend - if the developer can't deliver what they been
asked for they shouldn't pretend they can.

But this tense situation can be solved by working with the developer to
clarify requirements. Perhaps a lite-version could be released that was hard-
limited below the danger zone, or with a problem feature left out or set to
use offline processing to avoid the race conditions.

