|
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. |
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/