JDD

There is a version of Product Management work that AI can probably do. It can certainly summarize interviews, cluster feedback, draft PRDs and epics, answer questions about product data, and produce mockups. Do enough of that well enough, and the role starts to look like an information processing layer with some communication on top. But that is not what Product Management is all about. The center of the role was never the paperwork. It was always judgment: deciding what problem matters, interpreting incomplete and conflicting signals, making tradeoffs under uncertainty and pressure, defining success, and taking responsibility for the call. ...

In the previous post, I argued that defining decision boundaries is necessary if we want judgment to survive in an AI-accelerated development environment. When execution becomes cheap, the number of decisions explodes. Without clarity around who decides what, speed simply amplifies risk. But defining boundaries alone is not enough. The next question is more practical: how does work actually flow through those boundaries? How does an idea move from a conversation with a customer to something running in production, while AI accelerates the process without collapsing responsibility across roles? ...

The Stages of Judgment-Driven Development Most of the pain I’ve seen in software wasn’t caused by bad code. It was caused by bad decisions that were never treated explicitly as such. In the last two posts, I argued that execution is no longer the bottleneck. AI made building cheap. Judgment is now the scarce resource. If that’s true, the way we develop software must change, not in terminology or ceremonies, but in where and how we place judgment. ...