I have to disagree with the central argument, which is to give engineers more product management responsibilities. A way I’ve handled priorities as a PM is by setting the order of the backlog. At sprint planning, the team collectively decides what to pull off the backlog, and it doesn’t have to be the top stories that add up to our expected points goal. If the team goes diving to the bottom of the list for a bunch of trivial stories, then that sparks a conversation about why we have different priorities. Product owner isn’t a dictator, but they are ultimately responsible for the product.
Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role. I think some engineers like the side quests because they’re fun. In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls. If everyone in the kitchen had to do market research at other restaurants, pick up ingredients from local farms, and test new menu concepts, the place would be out of business in short order.
Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.
Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role. I think some engineers like the side quests because they’re fun. In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls. If everyone in the kitchen had to do market research at other restaurants, pick up ingredients from local farms, and test new menu concepts, the place would be out of business in short order.
Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.