4 ms·

I get that this is a thought up example, but why is this role necessary in this case. If the business team knows what they need next, and the software team know

I get that this is a thought up example, but why is this role necessary in this case. If the business team knows what they need next, and the software team knows how long it takes, can't they just get together and work on it? Why do they need a middleman here that just creates meetings? To be bit more abstract: if the business team owns the roadmap, then what value does the role add?

Osiris 7y ago
In my case, "the business" (executive team) has broad overarching ideas. The PM then works out the specifics, works with UX to design the screens, put together the copy, talks to engineering to understand what technical challenges may exist, then works with individual teams to break down the high level into small specific tasks. During development, they manage our todo column, answer questions, help make adjustments when previous assumptions prove false or we run into unexpected challenges, etc. As an engineering manager, I've actually found it quite helpful.
aidanlister 7y ago
Get a piece of paper out and draw a bunch of circles on the left, and a bunch of circles on the right. This is your business team and development team respectively. Now draw lines between all the circles. Those are your lines of communication without a PM. This is a sad diagram, no one knows the whole story. Now repeat the exercise but draw an additional circle in the middle of the page. This time, the lines on the left and right connect to the middle circle. This is a happy diagram, the developers aren’t pulled in a dozen different directions and one person has the whole picture. That is the role of a PM.
- tootie 7y ago
  This is a good point of view. Depending on your team or your org as a whole, it may be that you can manage communications just fine without one, but most of the time you can't. Also, in my org at least, the PM's main job is watching the budget.
  - ethbro 7y ago
    My perspective, having worked with both good and bad PMs, is that a PM is a communication line aggregator. In the example, every one of those lines consumes resources: time, context switching, misunderstanding, synchronization with the rest of the team. A quality PM funnels all those lines through themselves. Their value is proportional to their ability to (a) bidirectionally extract, transform, and deliver useful information to both sides (developers and end users), (b) offload processing tasks that neither side is good at (merging similar requests, clarifying ambiguous requests, tracking down answers / requests for external teams), & (c) keeping a 10,000 view and coordinating tactical requests to align with strategic vision. I like the CDC 6600's peripheral processors ( https://en.wikipedia.org/wiki/CDC_6600#Peripheral_Processors_(PPs) https://en.wikipedia.org/wiki/CDC_6600#Peripheral_Processors... ) as a computer hardware metaphor.
- nradov 7y ago
  Where are the customer circles in that diagram? Product managers have to get out of the office (maybe virtually) and talk directly to real customers and qualified sales prospects.
  - crazygringo 7y ago
    A full diagram has a circle at the bottom for customers and a circle at the top for management. The PM is the hub of communication between all 4. Although on a day-to-day basis, it's the dev team and business/sales that make up the large majority of interaction. Check-ins with management are occasional, and conversations with customers are just kind of an ongoing informative thing.
cjcenizal 7y ago
They’re in meetings all day, gathering and distilling the information mentioned by the GP, and helping stakeholders understand and make trade-offs. If the engineers did this work, they’d have no time for executing.
geofft 7y ago
Same reason why if you've got team X that's produced an API and team Y that's produced an app with a plugin architecture, someone still needs to spend time making your app call the API. It doesn't happen on its own, and if you get rid of the "make the two actually talk to each other" role, people from the two teams will have to end up doing it anyway, taking time away from their own job.
dahart 7y ago
In my experience as an engineer, and also as a founder, good PMs are extraordinarily valuable. Having lead engineering teams and also started a company, I can safely say that prioritizing feature development is one of the hardest and most important things that needs to happen, and it never stops, it needs constant attention. A PM is a liaison between multiple teams - executive, sales, marketing, design, engineering, testing, QA, and last but not least, customers. They are responsible for wrangling the priorities and the schedule, and doing that is a full time job, often in larger companies of many people, not just one. There’s a lot of assumption built into the framing of your question. Why do you think a PM is a middleman and only creating meetings? Is this based on some experience? Why is your premise that the business team owns the roadmap? Bad PMs do exist, just like bad managers, and just like bad engineers. If that’s where your question is coming from, I’m sorry, but please don’t assume that a bad experience is universal; it’s not. In a business, there usually needs to be a healthy tension between what sales and marketing ask for, what the executive leadership see in the future, what customers need (which is not always what sales and marketing are asking for), what is on the engineering backlog, how difficult features are to implement (both how long, and also how disruptive they are), and anything the product needs that is not on one of those previous lists. When one team or one point of view dominates, bad things tend to happen. If sales and marketing gets to dictate what happens and engineering is relegated to implementing whatever they say, the roadmap can be too short-term and full of churn, it will lack focus and forget about existing customers. If engineering has complete control over the roadmap, it sometimes drifts away from what customers need and toward what engineers like to do, with solutions that are neat but overly complicated or using new technology for the sake of learning. You need a little of each, as well as some pushback from every direction to keep everyone happy. A PM has their work cut out for them.

Osiris 7y ago

In my case, "the business" (executive team) has broad overarching ideas. The PM then works out the specifics, works with UX to design the screens, put together the copy, talks to engineering to understand what technical challenges may exist, then works with individual teams to break down the high level into small specific tasks. During development, they manage our todo column, answer questions, help make adjustments when previous assumptions prove false or we run into unexpected challenges, etc. As an engineering manager, I've actually found it quite helpful.

aidanlister 7y ago

Get a piece of paper out and draw a bunch of circles on the left, and a bunch of circles on the right. This is your business team and development team respectively. Now draw lines between all the circles. Those are your lines of communication without a PM. This is a sad diagram, no one knows the whole story. Now repeat the exercise but draw an additional circle in the middle of the page. This time, the lines on the left and right connect to the middle circle. This is a happy diagram, the developers aren’t pulled in a dozen different directions and one person has the whole picture. That is the role of a PM.

tootie 7y ago
This is a good point of view. Depending on your team or your org as a whole, it may be that you can manage communications just fine without one, but most of the time you can't. Also, in my org at least, the PM's main job is watching the budget.
- ethbro 7y ago
  My perspective, having worked with both good and bad PMs, is that a PM is a communication line aggregator. In the example, every one of those lines consumes resources: time, context switching, misunderstanding, synchronization with the rest of the team. A quality PM funnels all those lines through themselves. Their value is proportional to their ability to (a) bidirectionally extract, transform, and deliver useful information to both sides (developers and end users), (b) offload processing tasks that neither side is good at (merging similar requests, clarifying ambiguous requests, tracking down answers / requests for external teams), & (c) keeping a 10,000 view and coordinating tactical requests to align with strategic vision. I like the CDC 6600's peripheral processors ( https://en.wikipedia.org/wiki/CDC_6600#Peripheral_Processors_(PPs) https://en.wikipedia.org/wiki/CDC_6600#Peripheral_Processors... ) as a computer hardware metaphor.
nradov 7y ago
Where are the customer circles in that diagram? Product managers have to get out of the office (maybe virtually) and talk directly to real customers and qualified sales prospects.
- crazygringo 7y ago
  A full diagram has a circle at the bottom for customers and a circle at the top for management. The PM is the hub of communication between all 4. Although on a day-to-day basis, it's the dev team and business/sales that make up the large majority of interaction. Check-ins with management are occasional, and conversations with customers are just kind of an ongoing informative thing.

cjcenizal 7y ago

They’re in meetings all day, gathering and distilling the information mentioned by the GP, and helping stakeholders understand and make trade-offs. If the engineers did this work, they’d have no time for executing.

geofft 7y ago

Same reason why if you've got team X that's produced an API and team Y that's produced an app with a plugin architecture, someone still needs to spend time making your app call the API. It doesn't happen on its own, and if you get rid of the "make the two actually talk to each other" role, people from the two teams will have to end up doing it anyway, taking time away from their own job.

dahart 7y ago

In my experience as an engineer, and also as a founder, good PMs are extraordinarily valuable. Having lead engineering teams and also started a company, I can safely say that prioritizing feature development is one of the hardest and most important things that needs to happen, and it never stops, it needs constant attention. A PM is a liaison between multiple teams - executive, sales, marketing, design, engineering, testing, QA, and last but not least, customers. They are responsible for wrangling the priorities and the schedule, and doing that is a full time job, often in larger companies of many people, not just one. There’s a lot of assumption built into the framing of your question. Why do you think a PM is a middleman and only creating meetings? Is this based on some experience? Why is your premise that the business team owns the roadmap? Bad PMs do exist, just like bad managers, and just like bad engineers. If that’s where your question is coming from, I’m sorry, but please don’t assume that a bad experience is universal; it’s not. In a business, there usually needs to be a healthy tension between what sales and marketing ask for, what the executive leadership see in the future, what customers need (which is not always what sales and marketing are asking for), what is on the engineering backlog, how difficult features are to implement (both how long, and also how disruptive they are), and anything the product needs that is not on one of those previous lists. When one team or one point of view dominates, bad things tend to happen. If sales and marketing gets to dictate what happens and engineering is relegated to implementing whatever they say, the roadmap can be too short-term and full of churn, it will lack focus and forget about existing customers. If engineering has complete control over the roadmap, it sometimes drifts away from what customers need and toward what engineers like to do, with solutions that are neat but overly complicated or using new technology for the sake of learning. You need a little of each, as well as some pushback from every direction to keep everyone happy. A PM has their work cut out for them.