[oddthink]

Why do agile-folks seem to hate product managers so much?

This comes out in #13, #19, and #20 (well depending on exactly what they mean by "managing".) I find it really helps to have someone dedicated to the product side, so they can help with prioritization, generating ideas for what to try next, keeping track of the research, and tracking the launch process and metrics.

We could, I suppose, distribute all of that to the engineers, but there's value in that specialization.

(I generalize to "agile-folks" here because I feel like I've seen this before, but I can't think of exactly where.)

[ItsMonkk]

I'm not yet an expert on this, but I'm coming to the same intuition that the writer has so let me attempt to explain.

Let's say we have 4 domains, and 4 domain experts. P is product, B is backend, F is frontend, and D is database(this is heavily simplifying, I know there are many sub-domains within each depending on the scope of the project). Each new feature starts with the P expert working with the team translating the user requirements into what he thinks is needed. B and F communicate with each other. B and D communicate with each other. But since none of them have a shared understanding, the communication is of poor quality. You get mistakes. You'll find that if you had an PF expert the implementation would be 10x simpler. You get things where if you had an PBFD expert would be 1 million times simpler. Without the cross-domain knowledge you will never know when those simplifying measure are possible.

The problem with starting with a P is that the expert is basically starving the rest of the team of the knowledge that they have accumulated. They handle that work, it's up the the product expert to come up with the new features. And by putting that title on their head, and never letting the developers in, it tends to lock in place.

You are only as creative as your feedback loops, and your feedback loops depend on the bandwidth of communication. Within waterfall that might be months. Within agile that is a sprint. But with a PBFD expert your feedback loops can be measured in seconds.

You don't need PBFD experts, but it is very helpful to at least have translators. So there might be a PD expert, there might be a BF expert. That way you can get a reasonable translation of the requirement out. By taking on the team a Product Manager who is explicitly non-technical person, you lock that P in place. I think that's why we're seeing push-back to PM's where it's a general domain issue. P is a fine role, if you also have a PD, if you also have a PB, if you also have a PF. The Fullstack developer is already a BFD, why not also train them in the product?

The example I like to give is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed while also able to create everything, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity.

[oddthink]

I can see this as being a problem, like you said, if there isn't communication, but I don't think that demanding a "PBFD" expert is realistic or scalable.

But in my experience the PM is technical enough to understand what's going on. (Can write some SQL to answer questions, possibly ex-engineer themselves, etc.) They're in the same meetings, same email threads, looking at the same set of OKRs, etc. It's part of the engineers' jobs (B/F/D whatever) to communicate their constraints and their ideas (both product and pure-tech) to the PM, and it's part of the PM's job to take those into account when advocating for what should be done.

Similarly, the more the engineers know each others' specialties, the better they can coordinate. It's probably more important for everyone to have "a little bit of product" in them, but that doesn't mean we don't need a product-specialist.

When it's time for quarterly planning, the PM's voice is definitely loud, but they're still just one voice in the room. They're the one accountable for the product, which gives them some leverage, but the other voices are there (TLs, managers, etc.)

Now I can see this going terribly wrong if the scale is off (only one PM for too many engineers), or if communication breaks down (PM scribbles a "design" on a napkin and faxes it over), or if only the PM is consulted for planning. But the problem there is that communication broke down, not that it's bad to have a PM.

[ItsMonkk]

I generally agree with your response. There is nuance and every project will be different and every team will be different.

There was a PM post this last week[0] where I can cite possible flaws. The PM creating this post has engineering experience, so it's possible that he will make all of the correct decisions, but he is also centralizing a big portion of the decision making. That can be good, especially if he is of the PBFD variety.

> "Do we absolutely need discount functionality at launch?"

This is a good question to have. You want to only build the MVP. But if you don't know what it will take to build[1], then you can't make that decision. If you make that decision, and don't communicate to the team that you made that decision, and they build a product that needs to be completely redone once that feature needs to be done, that's not ideal.

> "Which tasks depend on which other tasks?"

This is a good question to have. Another good question is: What parts of these tasks can we work on even if the entire story is dependent on some other task? Is the entire job going to take at minimum 23 weeks, or can we on week 1 spend a bunch of time doing "product cart price calculation" spike engineering task, while at the same time doing a "shopping cart containing product" spike task. Then when we get to the story, suddenly the implementation of the entire pipeline can be completed in a single sprint. If your engineers only see the story when its popped off of the top of the backlog, they won't be able to accomplish that.

[0]: https://news.ycombinator.com/item?id=27906886

[1]: https://xkcd.com/1425/