3 ms·
(getting a Page Not Found error now... Google Cache: http://webcache.googleusercontent.com/search?q=cache:qu58iS1Efa4J:bexhuff.com/2010/03/should-product-manage
by nhashem 15y ago
(getting a Page Not Found error now... Google Cache: 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 http://webcache.googleusercontent.com/search?q=cache:qu58iS1...)
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 15y agoHmm, 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 15y agoAgreed - see http://en.wikipedia.org/wiki/Conways_Law http://en.wikipedia.org/wiki/Conways_Law which is exactly the problem you described (but in a more general way)