You seem to be misinterpreting my thoughts as being against the idea of a product manager role. That's not what I mean. I'm talking about product as a separate autonomous org with a CPO, versus embedded PMs reporting to EMs alongside the rest of the product development team. I have similar, though less strong, feelings about Design as a separate org as well, for many of the same reasons (communication overhead/bottlenecks).
With regard to backlog, there is actually some capacity planning math that can show that (unintuitively) backlog size negatively affects product delivery velocity. I'm not an expert there, I've just watched some internal tech talks about it in the past.
At a higher level, think about what happens when the business side requests a new feature, or a product change. What is the difference in terms of confidence of estimates that can be given if you have 20 tasks in the backlog, versus 200. Sure, for that one thing you can up the priority and jam it in above a bunch of other stuff. But then, once that starts happening to people where you prioritize a newer request above theirs, how does that affect their confidence in your planning ability on a longer timeline?
> in my (vast) experience
Lastly, maybe pump the brakes a bit here, boss. This statement doesn't make me trust you more, independent of your ideas. We're on a web forum, not in a board room.
>Lastly, maybe pump the brakes a bit here, boss. This statement doesn't make me trust you more, independent of your ideas. We're on a web forum, not in a board room.
literally made me lol, thanks for that. i mean it in a good way, not a defensive sarcastic way. that particular phrase is funny. can't recall the movie that made it popular but it forces a smile.
i'm not trying to gain your trust. like 95% of posters, i just like the sound of my own voice. i could not care less what you do with the info ... and i shouldn't care. it's opinionated. if you agree with it, you already agreed with it. it's not like i'm trying to convince you that JWT is bad. i have no agenda.
i was just using the adjective to note that this is what i've seen over a long time in this industry. AFAICT most of HN is 25-somethings with hardly a clue so i felt it useful to note that my opinion doesn't come from the 2 jobs i've held since graduating. that's all. i wasn't trying to speak from a position of authority, so as to command respect.
i understand though why you reacted as such, as in retrospect it sure looks like the typical kind of comment, i'll admit that.
as to the rest of your reply, yup i misunderstood your argument.
as to priority churn, that's not a problem of the backlog per se, that's a function of poor management, or the simple state of being of an early startup. whether you have an actual backlog or not, the whiplash priorities are the problem and the backlog merely the embodiment. by removing the backlog, you haven't addressed the problem.
I would much rather have product folks embedded in the engineering team. That way they can be working on making sure any issues on deck to be worked on next have up to date, clear requirements, and issues are prioritized correctly.
Having product people separated into their own organization almost always leads to a "throw it over the wall" situation.
however that's not a [dys]function of simply having a product org, that's a problem with poorly qualified, poorly performing employee. or a poorly describe job function. usually with the boss/management similarly poorly equipped since they don't see past the metrics they themselves (usually) have established for "success".
i think like the GP, you are conflating poor execution of the concept/model with the deficiencies of the model itself. one does perhaps encourage the other, however it doesn't need to be that way and isn't inherent.
i mean, in 3 words, "haters gonna hate". meaning that people that are poor at execution are going to be poor at it no matter the model in which they are embedded. but when you do have a good product team, the product org (as a model) gives them the ability to maximize a less than ideal engineering team. of course, still there's many a slip twixt cup and lip.
in every company i've been at that is larger than a handful of people that all know each other, a separate product org is a requirement if you want a product with broad appeal.
i'm not sure what your complaint about the product backlog is. product people should be generating a large backlog. that is literally their job, is it not? it's only through a large backlog that you can say, hey we need more engineers. or hey, our vision doesn't match our capabilities -- refine it. and so on.
How exactly does a large backlog have a negative effect on velocity?