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.
"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."
"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.
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?
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.
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.
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.
"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.
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.
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.
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"
Yes, you can be a PM without knowing code, but it's hard to be an excellent one.
A technical PM maybe doesn't code on a daily basis anymore, but one who understands technical challenges is highly valuable. A good PM who knows the chops can easily debug things when a customer calls, design good features and know whether it'll be easy or hard to implement,set more realistic goals,or call out BS from developers who says some easy task will take 4 weeks or something is impossible to implement.
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.
If Apple wants a replacement, maybe Vogue magazine's people would work. I'm at a loss to understand Steve Jobs except has a sense of fashion. Maybe, the Paris fashion world has a replacement.
God says...
C:\TEXT\WORD1.TXT
,
Their Father, took of them no thought,
He loved the Wars so well.
Sing, mournfully, oh! mournfully, 10
The Solitude of Binnorie!
Fresh blows the wind, a western wind,
And from the shores of Erin,
Across the wave, a Rover brave
To Binnorie is steering:
Right onward to the Scottish strand
The gallant ship is borne;
The Warriors leap upon the land,
And hark! the Leader of the Band
Hath blown his bugle horn.
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.
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. :)
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.
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?
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.
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."
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.
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.
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.
32 comments
[ 4.6 ms ] story [ 80.8 ms ] threadFrom 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.
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.
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?
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.
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.
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.
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.
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.
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"
Yes, you can be a PM without knowing code, but it's hard to be an excellent one.
A technical PM maybe doesn't code on a daily basis anymore, but one who understands technical challenges is highly valuable. A good PM who knows the chops can easily debug things when a customer calls, design good features and know whether it'll be easy or hard to implement,set more realistic goals,or call out BS from developers who says some easy task will take 4 weeks or something is impossible to implement.
The best rule in life is "there is only one Steve Jobs".
God says... C:\TEXT\WORD1.TXT
, Their Father, took of them no thought, He loved the Wars so well. Sing, mournfully, oh! mournfully, 10 The Solitude of Binnorie!
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.
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. :)
--
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...
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?
Isn't that just a ridiculous argument?
A.
Link.
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."
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.
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.
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.