4 ms·

> We have roles (hats) for these things: project managers, UX, researchers, data scientists, business analysts, team managers, coaches, etc. Do product managers

> 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.
  - lostcolony 9y ago
    If the technical people don't understand the tradeoffs and prioritize the business' actual needs (sometimes even above the business' stated wants), why do you think a non-technical person (which is 100% of the POs I've encountered) will be able to?
    - TheCoelacanth 9y ago
      Because the non-technical person has time to dedicate to learning about business' needs while the technical person is busy doing technical stuff for most of their day.
      - lostcolony 9y ago
        And then they have to communicate that to the dev team, and sit with the dev team to come up with proper stories, which effectively saves little to no time (and leads to a game of telephone; is what the PO telling you -really- what the business needs or just what they heard the business tell them they wanted?). Or, be technical enough that they don't need to communicate it to the dev team in the first place but can just write the stories. I've yet to encounter one sufficiently technical
    - geofft 9y ago
ryanbrunner 9y ago
My takeaway from the article was less that you should have each one of those roles filled out with a dedicated person, but more that those roles can be fluid and accomplished by many people on the team. Developers and designers can talk to customers. You can experiment with bringing in representatives from customer success, sales, or whatever for the team to work with to analyze business requirements. Developer leads can manage the projects and meetings. There's cases where having a dedicated product manager helps with these, but keeping those roles fluid in the early days can be helpful.
- wgerard 9y ago
  > My takeaway from the article was less that you should have each one of those roles filled out with a dedicated person, but more that those roles can be fluid and accomplished by many people on the team. I guess that wasn't really my takeaway, and even if it was I wouldn't agree with it really. Why it wasn't my takeaway is quotes like: >> If you need advocates, evangelists, analysts, persona specialists, domain experts, coordinators, strategists, stakeholder herders, project drivers, etc. then hire them, and give them the right title >> Consider hiring in apprentices/interns to fill “mixed” hats — research, data science, UX, etc.

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.
- lostcolony 9y ago
  If the technical people don't understand the tradeoffs and prioritize the business' actual needs (sometimes even above the business' stated wants), why do you think a non-technical person (which is 100% of the POs I've encountered) will be able to?
  - TheCoelacanth 9y ago
    Because the non-technical person has time to dedicate to learning about business' needs while the technical person is busy doing technical stuff for most of their day.
    - lostcolony 9y ago
      And then they have to communicate that to the dev team, and sit with the dev team to come up with proper stories, which effectively saves little to no time (and leads to a game of telephone; is what the PO telling you -really- what the business needs or just what they heard the business tell them they wanted?). Or, be technical enough that they don't need to communicate it to the dev team in the first place but can just write the stories. I've yet to encounter one sufficiently technical
  - geofft 9y ago

ryanbrunner 9y ago

My takeaway from the article was less that you should have each one of those roles filled out with a dedicated person, but more that those roles can be fluid and accomplished by many people on the team. Developers and designers can talk to customers. You can experiment with bringing in representatives from customer success, sales, or whatever for the team to work with to analyze business requirements. Developer leads can manage the projects and meetings. There's cases where having a dedicated product manager helps with these, but keeping those roles fluid in the early days can be helpful.

wgerard 9y ago
> My takeaway from the article was less that you should have each one of those roles filled out with a dedicated person, but more that those roles can be fluid and accomplished by many people on the team. I guess that wasn't really my takeaway, and even if it was I wouldn't agree with it really. Why it wasn't my takeaway is quotes like: >> If you need advocates, evangelists, analysts, persona specialists, domain experts, coordinators, strategists, stakeholder herders, project drivers, etc. then hire them, and give them the right title >> Consider hiring in apprentices/interns to fill “mixed” hats — research, data science, UX, etc.