6 ms·

We Need Fewer Product Managers

65 points by Athas 9y ago

tw1010 9y ago
We Need Fewer Exaggerated Headlines
- mi100hael 9y ago
  We need fewer blogs on Medium
prepend 9y ago
I don’t quite understand this piece. Perhaps there is some exaggeration in the use of product and product manager in titles, but I think it’s superior to previous exaggeration in project management. It seems like this author has a complaint against product management, but doesn’t quite explain who hurt him or why. The recommendation is for various different titles to serve in the role- analyst, domain specialist, etc. But I think this is just syntax sugar for product manager. I don’t think you go to school to be a product manager. I think you go to school for a skill and then add product management skills (eg, be an engineer, learn product management to design products and lead teams). This approach is better to the leader being a project manager with no domain expertise but able to track schedules. I don’t think it’s important what you call the product leader, it’s more important that you have someone with knowledge of the user and the problem domain “in charge” rather than just a procedural person following the project. Finally, you need a metaphor for all products to help with oeganization. I prefer product over project as it better puts the user as the measurer of value (ie, if user is happy then project is succeeding) rather than the project itself which frequently can continue on intertia for some time without any user value.
wgerard 9y ago
> We have roles (hats) for these things: project managers, UX, researchers, data scientists, business analysts, team managers, coaches, etc. Do product managers often wear these hats? Sure. Do you need a product manager to wear these hats? No. Yikes, some problems immediately spring to mind: 1) It's significantly more overhead (both financially and logistically) to have seven specialists doing the job that one generalist was previously. 2) Someone still needs to "herd those cats". Someone has to take the UX research and distill it into project requirements, someone has to take the business analysis and figure out what that means for the product, and so on. 3) It's ok to have generalists with changing job duties. Companies do this all the time with job titles like "software engineer" or "full-stack engineer". I get the frustration with vague job descriptions and unclear responsibilities, but I don't think the answer is more specialization necessarily.
- midasz 9y ago
  >"herd those cats" I'll do it.
- hvidgaard 9y ago
  No matter how it is worded, someone needs to be the shield for the development team. There is a constant stream of requests from customers, but the team should not be exposed to all of them. That is the responsibility of the product manager. A coherent system, and decide how to use the limited ressources to develop the product the best way.
- lostcolony 9y ago
  "Herd those cats" - that's where "self organizing teams" come in. Turns out, most groups of people who are told "Hey, you're all accountable for (X). Work together on it" will actually work together. That includes figuring out what the business actually needs (not what they say they want), and what tradeoffs may be necessary. I've been on a project in the past that for most of its life had no product owner (or equivalent), just devs, QA, and a team lead, and we delivered what the business flat out said was the biggest success our department had ever given them. We still had internal issues on our team that we had to work around, we still had disagreements, but when everyone is invested in the success of the product, you learn the domain, learn when you need to ask questions, when you need to listen, and when you need to overrule the business (and how to do that in a way they can appreciate). You should have someone in charge (a technical manager say) to handle personnel disputes and otherwise play tie breaker in the event of disagreements, but that's a very specific, and very different, role, compared to what product/project owner/manager entails.
  - geofft 9y ago
    What are your individual incentives and expectations, and who sets them? Who has the power to say "Look, this will be cheaper and better for the business if we spend $50,000 on this SaaS and 3 person-months of dev time integrating it instea of building it in house from scratch"? Are you all individually measured on value to the business and not engineering productivity? My worry with unmanaged teams is that they work well when the right option, with all the data, is to just let some engineers do the engineering they're familiar with / excited about, and very poorly when that's not the right option. So if you don't know in advance which case you're in, you want someone who's able to herd the cats if necessary.
romanovcode 9y ago
> We need fewer product managers. We need MORE: - internal startup co-founders, - UX, - customer advocates, - domain experts, - service designers, - complexity untanglers, This suppose to be a sarcasm?
kbos87 9y ago
This is really a rant against management. Reading it reminds me of my way of thinking early in my career before I had encountered a good manager, and also really understood how hard it can be to get even well meaning people working on the right things and moving in the same direction. A collection of specialist individual contributors sounds great, but in practice, it just doesn't work.
- prorsum 9y ago
  We need good managers for sure. But I like the fact that the author is trying to draw a line between management practice and thought process.
- bradleyjg 9y ago
  A regular manager is better than an amorphous product manager. If your manager tells you to do X, it's pellucidly clear that you need to do X. That's the person that does your evaluation, can fire you, can maybe get you a raise or a bonus, that approves your vacations. If you think it is a bad idea, you can argue that with your manager. But at the end of the day, if you aren't convincing you are probably going to do X or start looking for a new job. On rare occasion maybe you can take the risky step of going over your manager's head, but it is unlikely to end well. If a product manager tells you do X, is that an order? suggestion? request for a favor? If you don't agree that X is a good idea, what are your options? What if the product manager for product A tells you do X and the product manger for product B tells you to do Y? I understand that companies on the one hand don't want a rigid system where cross functional teams communicate with each other solely by going up across and back down, but on the other hand don't like to have e.g. a programmer managed by someone that's never programmed. But a dotted line on an org chart are the corporate equivalent of code smell -- a problem waiting to happen.
crdoconnor 9y ago
I can think of a few kinds of manager who ought to be culled (mostly upper), but somebody who can give me crystal clear requirements with clear priorities is of immense value to me as a software developer. It takes a massive weight off my shoulders. The alternative is fielding a stream of requests from different people with different agendas and trying to figure out both what their deal is, what the hell it is they are actually after (because most people can't explain their requirements coherently and have to have it teased out) and using subtle social cues to figure out how important their requirement really is so it can be prioritized. I've noticed that PMs who can't do this are pretty common though. It's a job that seems to be filled frequently by unqualified people.
- Myrmornis 9y ago
  Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this understanding is usually absent, by definition, in a PM?
  - crdoconnor 9y ago
    It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills). The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge. The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.
    - Myrmornis 9y ago
      Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions. I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.
kartickv 9y ago
Most teams I've worked on had a tech lead, a UX designer and a product manager. Why can't one of the first two people play the PM role? It's not as if being a PM takes up a person's whole time. In fact, on most of my teams, the PM was also the PM for a few other teams. Having fewer people wastes less time in coordination. I understand there would be some situations where you need a PM separate from other roles, but that shouldn't be the default. Just as most teams don't have an interaction designer, a visual designer, an animation designer, and a sound designer — all those are performed by one UX designer — most teams shouldn't have a separate PM. Is there anything I'm missing?
commandlinefan 9y ago
I've been coding professionally since 1992. I've witnessed the gradual decline of this profession from a fairly respected research-and-design type position to a clock-punching, time-tracking factory-assembly-type job - at least in the minds of the hordes of project/product managers who see their position as making sure that they squeeze every ounce of "productivity" out of the "lazy, slacking" programmers by accounting for every single minute spent in the office and making sure it matches up with an estimate from two months ago.
Myrmornis 9y ago
The piece is spot-on in that companies as they grow fill up with mid-level “PM”s who fill time with meetings. One problem with the article is companies don’t always use the P to mean product. They may distinguish Product and Program/Project, but the criticisms of the article, where not specifically about the word “product”, apply to the others.
dlwdlw 9y ago
Product managers produce less quality than self organized teams because even a good listener will not be able to coordinate all the small things that go into a great product where every domain specialist can contribute there sense of quality. This inefficient centralization however is necessary in higher complexity orgs because otherwise the higher level has nothing to control, no levers to push and pull. (they can't track down and keep in touch with EVERY individual) The downside of self organization is lack of focus outside a certain scale. The free market is a quintessential example of higher level emergent quality resulting from individual self organizing self centered interaction. It produces "goodness" but not in a mission directed way. The JavaScript ecosystem is another example. And like all ecosystems (as opposed to just "systems") it can be messy and confusing despite what it does. Efforts to tame these types of wildness often fail. Efforts to scale without becoming this type of wildness also often fail. As orgs grow, the focus on controllability requires more and more gatekeepers to maintain eventually choking actual output.
makecheck 9y ago
I’ve had many managers; by far the best were former peons that had actually worked on the project/technology they’re driving, or at least used it. Better still, those that never became 100% managers; more like people still being regularly exposed to the tech so they know firsthand. And since frankly tech is more fun than spreadsheets, this meant fewer meetings and shorter interactions overall, just getting stuff done. It meant using technology to help the project rather than periodically re-explaining everything to somebody and shoehorning it all into someone’s idea of a project plan. It meant that estimates could be meaningfully judged instead of being made-up numbers.

65 points by Athas 9y ago

tw1010 9y ago

We Need Fewer Exaggerated Headlines

mi100hael 9y ago
We need fewer blogs on Medium

prepend 9y ago

I don’t quite understand this piece. Perhaps there is some exaggeration in the use of product and product manager in titles, but I think it’s superior to previous exaggeration in project management. It seems like this author has a complaint against product management, but doesn’t quite explain who hurt him or why. The recommendation is for various different titles to serve in the role- analyst, domain specialist, etc. But I think this is just syntax sugar for product manager. I don’t think you go to school to be a product manager. I think you go to school for a skill and then add product management skills (eg, be an engineer, learn product management to design products and lead teams). This approach is better to the leader being a project manager with no domain expertise but able to track schedules. I don’t think it’s important what you call the product leader, it’s more important that you have someone with knowledge of the user and the problem domain “in charge” rather than just a procedural person following the project. Finally, you need a metaphor for all products to help with oeganization. I prefer product over project as it better puts the user as the measurer of value (ie, if user is happy then project is succeeding) rather than the project itself which frequently can continue on intertia for some time without any user value.

wgerard 9y ago

> We have roles (hats) for these things: project managers, UX, researchers, data scientists, business analysts, team managers, coaches, etc. Do product managers often wear these hats? Sure. Do you need a product manager to wear these hats? No. Yikes, some problems immediately spring to mind: 1) It's significantly more overhead (both financially and logistically) to have seven specialists doing the job that one generalist was previously. 2) Someone still needs to "herd those cats". Someone has to take the UX research and distill it into project requirements, someone has to take the business analysis and figure out what that means for the product, and so on. 3) It's ok to have generalists with changing job duties. Companies do this all the time with job titles like "software engineer" or "full-stack engineer". I get the frustration with vague job descriptions and unclear responsibilities, but I don't think the answer is more specialization necessarily.

midasz 9y ago
>"herd those cats" I'll do it.
hvidgaard 9y ago
No matter how it is worded, someone needs to be the shield for the development team. There is a constant stream of requests from customers, but the team should not be exposed to all of them. That is the responsibility of the product manager. A coherent system, and decide how to use the limited ressources to develop the product the best way.
lostcolony 9y ago
"Herd those cats" - that's where "self organizing teams" come in. Turns out, most groups of people who are told "Hey, you're all accountable for (X). Work together on it" will actually work together. That includes figuring out what the business actually needs (not what they say they want), and what tradeoffs may be necessary. I've been on a project in the past that for most of its life had no product owner (or equivalent), just devs, QA, and a team lead, and we delivered what the business flat out said was the biggest success our department had ever given them. We still had internal issues on our team that we had to work around, we still had disagreements, but when everyone is invested in the success of the product, you learn the domain, learn when you need to ask questions, when you need to listen, and when you need to overrule the business (and how to do that in a way they can appreciate). You should have someone in charge (a technical manager say) to handle personnel disputes and otherwise play tie breaker in the event of disagreements, but that's a very specific, and very different, role, compared to what product/project owner/manager entails.
- geofft 9y ago
  What are your individual incentives and expectations, and who sets them? Who has the power to say "Look, this will be cheaper and better for the business if we spend $50,000 on this SaaS and 3 person-months of dev time integrating it instea of building it in house from scratch"? Are you all individually measured on value to the business and not engineering productivity? My worry with unmanaged teams is that they work well when the right option, with all the data, is to just let some engineers do the engineering they're familiar with / excited about, and very poorly when that's not the right option. So if you don't know in advance which case you're in, you want someone who's able to herd the cats if necessary.

romanovcode 9y ago

> We need fewer product managers. We need MORE: - internal startup co-founders, - UX, - customer advocates, - domain experts, - service designers, - complexity untanglers, This suppose to be a sarcasm?

kbos87 9y ago

This is really a rant against management. Reading it reminds me of my way of thinking early in my career before I had encountered a good manager, and also really understood how hard it can be to get even well meaning people working on the right things and moving in the same direction. A collection of specialist individual contributors sounds great, but in practice, it just doesn't work.

prorsum 9y ago
We need good managers for sure. But I like the fact that the author is trying to draw a line between management practice and thought process.
bradleyjg 9y ago
A regular manager is better than an amorphous product manager. If your manager tells you to do X, it's pellucidly clear that you need to do X. That's the person that does your evaluation, can fire you, can maybe get you a raise or a bonus, that approves your vacations. If you think it is a bad idea, you can argue that with your manager. But at the end of the day, if you aren't convincing you are probably going to do X or start looking for a new job. On rare occasion maybe you can take the risky step of going over your manager's head, but it is unlikely to end well. If a product manager tells you do X, is that an order? suggestion? request for a favor? If you don't agree that X is a good idea, what are your options? What if the product manager for product A tells you do X and the product manger for product B tells you to do Y? I understand that companies on the one hand don't want a rigid system where cross functional teams communicate with each other solely by going up across and back down, but on the other hand don't like to have e.g. a programmer managed by someone that's never programmed. But a dotted line on an org chart are the corporate equivalent of code smell -- a problem waiting to happen.

crdoconnor 9y ago

I can think of a few kinds of manager who ought to be culled (mostly upper), but somebody who can give me crystal clear requirements with clear priorities is of immense value to me as a software developer. It takes a massive weight off my shoulders. The alternative is fielding a stream of requests from different people with different agendas and trying to figure out both what their deal is, what the hell it is they are actually after (because most people can't explain their requirements coherently and have to have it teased out) and using subtle social cues to figure out how important their requirement really is so it can be prioritized. I've noticed that PMs who can't do this are pretty common though. It's a job that seems to be filled frequently by unqualified people.

Myrmornis 9y ago
Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this understanding is usually absent, by definition, in a PM?
- crdoconnor 9y ago
  It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills). The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge. The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.
  - Myrmornis 9y ago
    Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions. I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.

kartickv 9y ago

Most teams I've worked on had a tech lead, a UX designer and a product manager. Why can't one of the first two people play the PM role? It's not as if being a PM takes up a person's whole time. In fact, on most of my teams, the PM was also the PM for a few other teams. Having fewer people wastes less time in coordination. I understand there would be some situations where you need a PM separate from other roles, but that shouldn't be the default. Just as most teams don't have an interaction designer, a visual designer, an animation designer, and a sound designer — all those are performed by one UX designer — most teams shouldn't have a separate PM. Is there anything I'm missing?

commandlinefan 9y ago

I've been coding professionally since 1992. I've witnessed the gradual decline of this profession from a fairly respected research-and-design type position to a clock-punching, time-tracking factory-assembly-type job - at least in the minds of the hordes of project/product managers who see their position as making sure that they squeeze every ounce of "productivity" out of the "lazy, slacking" programmers by accounting for every single minute spent in the office and making sure it matches up with an estimate from two months ago.

Myrmornis 9y ago

The piece is spot-on in that companies as they grow fill up with mid-level “PM”s who fill time with meetings. One problem with the article is companies don’t always use the P to mean product. They may distinguish Product and Program/Project, but the criticisms of the article, where not specifically about the word “product”, apply to the others.

dlwdlw 9y ago

Product managers produce less quality than self organized teams because even a good listener will not be able to coordinate all the small things that go into a great product where every domain specialist can contribute there sense of quality. This inefficient centralization however is necessary in higher complexity orgs because otherwise the higher level has nothing to control, no levers to push and pull. (they can't track down and keep in touch with EVERY individual) The downside of self organization is lack of focus outside a certain scale. The free market is a quintessential example of higher level emergent quality resulting from individual self organizing self centered interaction. It produces "goodness" but not in a mission directed way. The JavaScript ecosystem is another example. And like all ecosystems (as opposed to just "systems") it can be messy and confusing despite what it does. Efforts to tame these types of wildness often fail. Efforts to scale without becoming this type of wildness also often fail. As orgs grow, the focus on controllability requires more and more gatekeepers to maintain eventually choking actual output.

makecheck 9y ago

I’ve had many managers; by far the best were former peons that had actually worked on the project/technology they’re driving, or at least used it. Better still, those that never became 100% managers; more like people still being regularly exposed to the tech so they know firsthand. And since frankly tech is more fun than spreadsheets, this meant fewer meetings and shorter interactions overall, just getting stuff done. It meant using technology to help the project rather than periodically re-explaining everything to somebody and shoehorning it all into someone’s idea of a project plan. It meant that estimates could be meaningfully judged instead of being made-up numbers.