5 ms·

yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers are

yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers aren't product experts. and if the customer is an engineering team, then engineers mostly make mediocre decisions, typically because of poor incentives (gaming story points). 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?

golemiprague 6y ago
You say it as if it is a fact, what are you basing it on? There are so many examples of start up companies where most of the team were engineers and they created very popular and successful products. It might be even the opposite, many times product people are not necessary really, a middle man between customer facing people and engineering that nobody really needs.
Sodman 6y ago
Having an entire separate org whose sole job is to create backlog items inevitably ends up with 100s of items, 15-30% of which are "high" priority. Many of these will have out of date specs by the time engineering can pull them in. 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.
Benjammer 6y ago
>engineers almost always make poor product decisions 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.
- lovehavetodo 6y ago
  Weird.
- pr91 6y ago
  Great point! Compartmentalisation is one thing but in large orgs, everyone starts focusing on one metric they need to boost (backlogs or PRs or design mocks) and we have no idea how this will affect other teams. We just have good metrics to show.
- jiveturkey 6y ago
  >> 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. 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.
almostdeadguy 6y ago
You're not wrong about incentives, but an org where PMs have fully segregated duties from devs is exactly the organizational context that breeds disconnected engineers juicing their burndown chart. I mean what do you think is the predictable outcome from a PM whose main job is googling his competitors and stuffing high fantasy JIRA tickets in the engineering backlog based on his mystic customer divinations. Neither of these people has made contact with a customer in their lifetime.
- jiveturkey 6y ago
  agreed! 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.

golemiprague 6y ago

You say it as if it is a fact, what are you basing it on? There are so many examples of start up companies where most of the team were engineers and they created very popular and successful products. It might be even the opposite, many times product people are not necessary really, a middle man between customer facing people and engineering that nobody really needs.

Sodman 6y ago

Having an entire separate org whose sole job is to create backlog items inevitably ends up with 100s of items, 15-30% of which are "high" priority. Many of these will have out of date specs by the time engineering can pull them in. 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.

Benjammer 6y ago

>engineers almost always make poor product decisions 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.

lovehavetodo 6y ago
Weird.
pr91 6y ago
Great point! Compartmentalisation is one thing but in large orgs, everyone starts focusing on one metric they need to boost (backlogs or PRs or design mocks) and we have no idea how this will affect other teams. We just have good metrics to show.
jiveturkey 6y ago
>> 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. 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.

almostdeadguy 6y ago

You're not wrong about incentives, but an org where PMs have fully segregated duties from devs is exactly the organizational context that breeds disconnected engineers juicing their burndown chart. I mean what do you think is the predictable outcome from a PM whose main job is googling his competitors and stuffing high fantasy JIRA tickets in the engineering backlog based on his mystic customer divinations. Neither of these people has made contact with a customer in their lifetime.

jiveturkey 6y ago
agreed! 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.