You know...
This brings a part of my life back to mind that I hoped to forget... FS, if you're reading and recognize this, I still respect the hell out of you and wish you well. I can't go into too much depth here without revealing more than allowed. I am purposely vague and I apologize if that bothers or offends you but I don't want to see any litigation in my future.
I don't know how to take this article. I wish some of the insight had been around when it mattered to me (working 60 - 80 hour weeks because of management over-promising because they wouldn't take the time to understand the scope because the PM was sure it was "trivial") but some of it also smacks of the PM thinking of her/himself as some kind of deity whose wishes would make the work happen magically. Me, personally, I like my deities to be left in church where I can ignore them as I deem necessary...
Anyway, the best PM like being I ever had contact with was a QA department head who had been in the line of business his whole life and knew exactly what something needed to do to succeed in that business. He had a second in command that was also a lifer. Between those 2 guys, when they got interested in something, that something did some smooth sailing. If they were disinterested or too busy with a fire, all hell would break loose.
Well, at this particular company, every time all hell would break loose, they would, instead of fixing the original software, buy something similar and try to massage it into the product. During the ~19 months or so I was there, they bought, had been in talks to buy or were suing the seller over the bought product not working for 4 different products. The funny thing was, all of these products were based on disparate technology... The original software was built in a combination of Delphi, Borland C++ and the Borland DB engine. Of the bought software, One was Java based, it wouldn't run for 12 or more hours at a time. One was based on .Net and it crashed more than it worked. 2 were based on popular C++ App Frameworks. Those 2 kinda worked, sometimes, if you held your mouth right and kept your support contracts up to date.
Now, we have a company with at least 4 different technologies with maybe 2 of the original developers of any of the software left. The only guy that remains with any sense and sanity is the QA guy because his family is tied to the company. And all along he's been yelling/screaming/cajoling/nurturing, whatever he can do to get the management to leave the programmers alone and so they can get the work done.
A bad PM can be countered with good engineering management. That said, I've been at a place that had both. Weekends were planned into the schedule and they thought that was the norm. At a certain point, the brain drain was pretty serious (myself included). Not meeting deadlines isn't always an engineering issue it is a management and planning issue.
Another more recent example, boot strapped startup. General engineering goal with a high level of what pieces are needed. Most of those working on it are contractors not always onsight. Functionality decisions are made between a couple of parties, but not communicated down resulting in added effort. In this case, there isn't a lot of engineering pushback, but the PM should be aware of the need to communicate more directly, yet doesn't. When pressed for specs, a blank face. An example, for me, of a bad PM.
Agreed. Thanks for the comments. We actually wrote recently about a "goal first" approach where you start with the strategy and why you are doing something and then clearly articulate the features in a collaborative way. Consider checking it out here - http://blog.aha.io/index.php/goal-first-a-product-roadmappin...
Thanks for the thoughts. I wish we had started Aha! (www.aha.io) earlier and were writing on PM topics like this when it would have been useful to you.
Being an engineer (by schooling) myself...I've always found it confounding how non-technical product managers do what they do...I've seen plenty of "shut up non-techie" posts (including this OP) but are there any really great non-techie product manager musings on this topic, explaining how they are able to reliably judge timeframes and output without having hands-on experience?
I do think producers are valuable...in the art/entertainment world, for example...you don't have to be an actor/model/writer to be vital to a production's success. However, in software, it just seems that the implementation of the process is so vital in fully realizing the gains that code can bring you, that if you have a product manager who doesn't understand that, than the PM can do as much harm as good.
I am the author and I built my career as a "non tech background" PM before I became a CEO. My super secret to success (not really that secret). Be great at explaining the "whys" and "whats" and work closely with engineering on the "hows." Understand what it will take to build something before agreeing on the roadmap. Building great product requires awesome PM and engineering.
I hate articles like this more than anything. If you really want to help product managers, do you have to spend the first half of the article telling them that you're so much more important than them? It takes two hands to clap.
The best product managers I've worked with have been ex-engineers. I got technical specs that we could go back and forth on. Wonderful in-depth technical conversations.
The worst ones: I wrote the specs. Instead of talking about technical stuff, I have to explain why something like "getting cache coherency right" is going to cost three or four days, and that no, I can't go to another scheduling meeting right now, didn't we have one yesterday?
The best: Shields.
The worst: "Why isn't that bug fixed? I'm going to call a meeting about that bug at 4:00, and I want it fixed by 5:00" [seriously. this happened]
I have been a PM for most of my career. Lose engineering and you have no ongoing product, sales and you can not sell it, support and you can not service it. You get the picture. PM is not required for the basic operations of the business. Great PM is fundamental to success, but not to the day-to-day management of the business.
There are 2 specialized positions (not roles) that I have been able to eliminate in a couple of successful projects (in a startup). These are Product Management and Quality Assurance. I think both the tasks are important enough to be entrusted to engineers, rather than getting someone else do it.
There are advantages to getting someone else to do some of your work half as good, for example they can offload work for many people at the same time. It's good for morale and concentration.
How did that work for you? Were the engineers assessing the overall market and competitive landscape and training the rest of the organization how to position and sell the product? Please tell us more about the project and how it went.
It's harsh but it's quite true. Engineers (and other people!) would otherwise have to devote time and effort towards product goals and timeline management -- it would likely be only half as good as a full-time PM but they'd get it done without trouble.
Product managers are an extension of people's normal employee workflows but expanded for coordination and communication, however there's nothing preventing the PM from exercising minimal responsibility on things like product design and whatnot.
I am not sure what your point is. Where in the blog post does it say that I am more important than they are? My career has been defined by being a PM and I have made all of those mistakes myself. In fact, our new company -- Aha.io -- is built for PMs.
"However, the reality is that you need engineering more than they need you."
Whatever. I like the article, it makes some good points.
It's hard to write an article explaining one side of a situation like this without 'taking sides'.
I think the the PM role/title has become such a generic position that articles like this one are really taking a stab at anyone non-engineering, not that I am upset by it.
As a startup founder, meshing technical teams and non-technical teams is extremely difficult to do. The work environments, thought processes, personalities, etc. are so different.
If you're having non-technical product managers owning technical products you're asking for trouble. Since when did any non-technical product person become the domain master go-to-guy for any technical product? I have seen product managers provide great leadership on technical products but they have always been supremely capable and the engineers respected them for it.
Some product person with an inflated ego spinning buzzwords is not going to be respected by engineering and will not succeed in influencing them in any way.
What you may think: I have been around engineers a long time and know the difference between NoSQL and MySQL. And there is no doubt that I would have been a great engineer if I had lerned to program, found it rewarding, and led a ton of open source projects.
Anyone who seriously thinks this way is most likely hated by engineers and probably gets made fun of a lot behind his back.
Exactly, all of the "what you might think" points were exaggerated but not intended to be ridiculous. Great PM works and respects the value of what engineers can contribute during the plan AND build efforts.
I think I am responding more to the way you have set the scene where we have non-technical product managers owning technical products. I think if this situation exists you've actually got a fucked company or at least some serious org-level trouble with the division of roles and responsibilities and probably not something you could fix by head-shrinking your product people.
Actually it's funny if you think about it the only way non-technical product managers maintain their positions owning technical products is by finding such companies and actively partaking in all the what you may think behavior. Forgive me if this whole piece is intended as subtle irony in which case I say well done and humbly accept my swoosh.
Eh—hoarding credit is sort of the M.O. of a really great product manager.
A PM has to compete with all the other PMs to get her features implemented. And if the PM's feature gets implemented first, this PM looks super productive.
I think if you're an product manager looking to be the best product manager, taking credit is imperative. Because at the end of the day, your feature is just paper until it is implemented.
Not being hated, well, that's another matter... I sympathize with the enormous friction between folks who assign work and folks who finish it.
I appreciate the comment but disagree. Leading great product teams is based on trust and trust is earned by success. Ongoing success depends on a highly motivated team and praise drives motivation as well as any other reward. Leaders do not succeed over time by hoarding kudos. They share it freely.
I think you have your logic backwards. Do you think the engineering team will implement the feature first for the PM that hogs the spotlight and takes the credit, or for the PM who gives credit to the team that implements her ideas? You need to let the love flow down to all of the team.
I sympathize with the enormous friction between folks who assign work and folks who finish it.
I don't. If you create this separation between the two categories, you'll have a terrible organization and when it caves in on itself, I will cheer that process on.
That's why open allocation is morally superior (in addition to working better). People "assign" work to themselves (without noise) and then do it. None of this parasitic high-horse management bullshit.
You know how much better the world would be if "work" was a culture of doing things rather than delegating and taking credit? It'd be a different world. People might actually, like, work when they go "to work".
You know how much better the world would be if everyone was good at work? If everyone had a correct estimation of his/her own ability? If everyone knew when to defer to those with better judgement?
The world would be awesome. But that's not the way the world is. And not all well-oiled machines will stay well-oiled...and in such a situation, sometimes it may be worth it to have someone who manages the process and can play King Solomon anytime two workers are fighting over a baby.
I'm not sure if the PM role does this well in practice, I'm just saying, I can imagine such a role in an imperfect work environment paying off.
Lots of people don't assign work to themselves, though, if given the opportunity. People shirk, they don't want to do this or that and if something is boring or hard and nobody is watching them they'll do something else.
Other people aren't very good at estimating what something will cost in terms of time or effort.
It's actually pretty rare to find people that assign themselves tasks and follow through on them. If you have an entire organization made up of people like that, awesome; it's the ideal, not the norm.
In what world do PMs actually think the supposed thoughts in this article? Yes, it's important to document well, focus on why not how, and be a shit umbrella not funnel -- though these have been PM 101 everywhere I've worked.
But when PMs infringe on these issues (and yes, all PMs do) I find it's rarely a conscious decision as much an impulsive/instinctive thing from being torn in 100 directions at once.
Oh great, another Product Manager/Project Manager/XYZ Manager has pissed off the software engineering masses post again. Another "we can live without you, but you can't live without us scribe...". Really? You mean I can't go find a top notch, $15/hr engineer to build in Kathmandu to build the product to my specs? Get a hold of yourself boys. You're not all that. I can (and have) built plenty of products with a wide assortment of engineering resources worldwide. If you're worth your salt, you recognized that it is the relationship between disciplines that matters - nt your "Engineers will Rule the World" mantra. Get over yourselves....
I built my career as a PM before becoming a CEO, so this might not be just another one of those posts. Are there market-leading products that have been built with lead $15/hr engineers? Please call out a few, I would love to learn about a few of them.
I'd like to add "Don't give estimates to other stakeholders (especially a client!) without talking to engineering." Even if you have some technical expertise, your guess may be off due to a lack of knowledge of the specifics of the platform, framework, gotchas, other priorities the team may have and a million other things.
The reality is that you can get yourself (and your team) into a bind if you commit to an estimate/schedule without discussing the details of what will be delivered with engineering. Don't do that.
What a short-sided article. I actually think it's more often the other way around--that engineers keep pissing off product managers! ;-)
Part of the problem, in my opinion, is that engineering tends not to give feedback, as much as they give derision. And product management tends to be too timid to stand up for themselves.
In reality, we all piss off each other. We'd all be better served if egos were checked at the door, and we could have open, collaborative conversations about creating really great products.
(1) Asking for a feature and then never showing up once when it is being built. "Hey, we are adding this page here. Is it okay?" <No answer>. "Hey, is this workflow good?" <No answer>. Once implemented, come around and ask "Why is this built this way?"
(2) Not being interested in any feature that engineering is interested in.
It is okay to talk to customers all the time, but once in a while turn around and talk to engineering too.
I read most of it, but you really lost me in the first sentence. If you are actually the CEO, that's one thing, but one sure fire way to piss off the engineers is to think of yourself as "the boss" simply because your role has "manager" in the title. Everywhere I've worked, the engineers answer to an engineering manager, and the engineering manager is a peer to the PM.
slightly off topic - anyone moved from coding to product management? I thoroughly enjoy product management - market research, coming up with new product ideas, feature ideas etc. No clue how to make the transition though :(
Technical Product Managers (TPMs) are a precious and valuable asset for any company. I know it because I do it :-)
No, really. If you have a good tech background, with a significat expirience from development aspects, it cannot be compared by any mean to a regual product manager. I talk to the biz people the ones with the suits, and I talk to DBAs and developers on a daily basis. I am like a bridge between the two worlds.
A good advise for one who wants to do the transition would be to just to dare to dream. Suggest products, get involved in all stages of the product's lifecycle. Be proactive, and after a while go and ask to be a PM. It's not a promotion as PM are not superior to devs (except from me). It's like a new role in your career, much different from a programmer.
In addition I would strongly suggest to build something on your own. Just do it, and you will learn a lot about specifying a product, about marketing, about managing the project of your own. If you come with this on your record, you are like 100 times in a better position.
Forget about MBA. It is useless and just dumb to do it. Go get some good books from Amazon, read 37signals series and other books which Amazon will recommend you in this area. God forbid the missed souls of the MBAs, but there is a reason Google don't hire them.
It's a tough transition, but I've seen it done in a few ways:
1) Internally apply for a Product Management job. Expect to have put in at least 3 years within the company and make sure you know the business domain better than most other engineers. Play politics successfully and hop on the first open PM position available. You may have to pick a product in pretty bad shape as a proving ground.
2) Build your own product either on the side or quit your day job to focus on it. Make sure it's something a bigger company like Yahoo, Google, Facebook, Salesforce, etc would be interested in. Make a real go at building a business, and doing the hard PM work. Hire others to do the engineering work so you can focus on the PM skills. This may also take 5 years before you land your dream PM role. If you play your cards right, you may land in a PM role with a nice exit as well.
3) Go get an MBA from a top school that Google, Facebook, and Microsoft actively recruit from. Make sure your program has a focus area on Technical Product Management so you can get into the right recruiting circles. This may be a faster track, but expect to lose 2 years of income and rack up a lot of tuition debt to make it happen.
This is good advice but the reality of it is goddamn depressing. "Proving ground"... "at least 3 years"... "MBA from a top school". We fucking lost our industry. Because we failed, we have to deal with executives.
Product management shouldn't be a special job for high-horse do-nothings with MBAs and connections. It should be a concern for all engineers; something everyone should care about and be able to influence.
Ha! I guess my negative bent around becoming a PM bled through. I have considered going into a PM role as a future career move but the reality of it usually depresses me into sticking with engineering.
It is pretty depressing that in most software companies, engineering makes little to no decisions about features, market strategy, or operational efficiency. You really have to get out of engineering to have any influence in those areas.
With engineering being so lucrative, you see a lot of self-selection where the weaker engineers end up making these transitions, which only makes the whole situation worse.
I realized that it was horrible as written and I apologize. In that vein, I fixed it (replaced with "executive's gender of interest"). It was reverse-pattern-matched off of a certain company where the desk ornament happened to be female, but I've seen male desk ornament dynamics as well.
That said, if you don't think 95+% of workplace favoritism is based on sexual desire, you're misled. That's especially true in the non-technical/subjective roles where ability is so hard to evaluate.
Most corporate executives did their 20s wrong and want to Feel Like A (Wo)Man now that they're older. Which means that for non-tech/subjective proteges they tap either (a) young, attractive people of the opposite sex who give them a "hip" image, or (b) unscrupulous young men ~20 years their junior through whom they live vicariously.
I stopped reading here: Involve engineering management early and often, so everyone has a chance to contribute to the product vision and buy into where the product is headed.
This is tailored to people in inefficient VC-istan companies where engineers don't get to speak for themselves, hence "involve engineering management". Ok, we're done here.
I agree that there are a lot of terrible, arrogant PM's out there. PM is the ultimate MacLeod Clueless job in many organizations (with engineers closer to the MacLeod Loser tier) because it involves a lot of context-switching and annoying work, but is ultimately just as subordinate as anything else, since the job still involves serving executives.
Good point. I deleted "management" from the post. The best orgs (and also the most successful) are those where everyone has a voice. Maybe you will keep reading now and let me know if anything else in the post really tweaks you the wrong way.
Minor nit: (1) you used the term "executive team" and I hate that phrase. Don't get me started on teamism. I hate this cargo-cult bullshit where every group of people is called a team. Executives are a court, in the medieval sense.
Also, I still sense that you're writing from a closed-allocation perspective. (I'm not even sure that proper open allocation would have a PM/engineer distinction. Why not hire people who are willing to do both?) Closed allocation is doomed to produce garbage and no amount about of telling other people to be better will correct for its foundational problems.
I imagine you can do both in a really small or one man team, but to do both in anything bigger will require a very difficult context switch between job functions.
I don't know how to take this article. I wish some of the insight had been around when it mattered to me (working 60 - 80 hour weeks because of management over-promising because they wouldn't take the time to understand the scope because the PM was sure it was "trivial") but some of it also smacks of the PM thinking of her/himself as some kind of deity whose wishes would make the work happen magically. Me, personally, I like my deities to be left in church where I can ignore them as I deem necessary...
Anyway, the best PM like being I ever had contact with was a QA department head who had been in the line of business his whole life and knew exactly what something needed to do to succeed in that business. He had a second in command that was also a lifer. Between those 2 guys, when they got interested in something, that something did some smooth sailing. If they were disinterested or too busy with a fire, all hell would break loose.
Well, at this particular company, every time all hell would break loose, they would, instead of fixing the original software, buy something similar and try to massage it into the product. During the ~19 months or so I was there, they bought, had been in talks to buy or were suing the seller over the bought product not working for 4 different products. The funny thing was, all of these products were based on disparate technology... The original software was built in a combination of Delphi, Borland C++ and the Borland DB engine. Of the bought software, One was Java based, it wouldn't run for 12 or more hours at a time. One was based on .Net and it crashed more than it worked. 2 were based on popular C++ App Frameworks. Those 2 kinda worked, sometimes, if you held your mouth right and kept your support contracts up to date.
Now, we have a company with at least 4 different technologies with maybe 2 of the original developers of any of the software left. The only guy that remains with any sense and sanity is the QA guy because his family is tied to the company. And all along he's been yelling/screaming/cajoling/nurturing, whatever he can do to get the management to leave the programmers alone and so they can get the work done.