> The project falls apart because Product drops the ball, but Engineering is the team at the end of the funnel, so the blame naturally tends to land on them. Product’s output is often hidden, and it’s easy for them to say, “Well, we did our part. Engineering just didn’t deliver.”
I've seen this get worse with LLMs. I've had specs that were wholly or in significant part generated by ChatGPT, but they look detailed so the are plausible workslop. I've been given a spreadsheet with nonsense items "Implement adaptive intent-driven workflows across user touchpoints" (I generated this example with GPT).
When I asked what any of it meant I was met with silence. Later through the grapevine I hear the requirements were generated by ChatGPT and the guy responsible for them doesn't understand the system at all. But guess who is responsible for delivery?
Any product person who hasn’t had years of engineering or sales needs to be taken out back and treated like Old Yeller (metaphorically of course). If you can’t deeply associate with the customer or comprehend the engineering of systems, you are not fit to be in the flow from keyboard to customer.
Oh, how sweet and naive I was to the world… hahah.
It still blows my mind that product isn’t treated like a soft engineering discipline in its own right. When product doesn’t do its own thinking, the cognitive load shifts to engineering. Suddenly, engineers are doing parts of product’s job. The result is predictable: engineering gets stretched thin, and both Product and Engineering fail to fully document or even understand what they’ve built.
The project falls apart because Product drops the ball, but Engineering is the team at the end of the funnel, so the blame naturally tends to land on them. Product’s output is often hidden, and it’s easy for them to say, “Well, we did our part. Engineering just didn’t deliver.”