Where I think I’m wrong

My argument that AI frees up time for the important work assumes the time goes there. It might not. Freed capacity has a way of getting filled (with more output, more meetings, more tickets) simply because it can be, and because a calendar abhors a vacuum. The honest version is that AI gives me the option of spending more time on strategy. Whether I take it is a matter of discipline, and discipline is not something a tool can install.

There is a quieter problem underneath that. If AI can make a mediocre operator look productive (polished documents, fast turnarounds, a tidy board), it gets harder, not easier, to tell good product work from busy product work. Including my own. The signals I would use to check myself are exactly the ones AI is best at inflating.

I argue that the thinking matters and the typing doesn't, and that AI can absorb the typing. But writing is not only transcription. The act of writing something down is often what exposes the hole in your reasoning: the requirement you hadn't thought through, the edge case you were hoping to ignore. If I let a model produce the words, I might keep the appearance of a well-formed ticket while skipping the exact moment that would have caught my own confusion. Outsourcing the writing can outsource a little of the thinking without me ever noticing it left.

“Data usually wins over a long horizon” is the kind of claim that is easy to believe because you remember the times it was true and forget the times it wasn't. Data is also conservative by nature. It rewards the measurable and the incremental, and it looks skeptical at exactly the big, awkward, category-defining bets that don't have a data point yet. Plenty of things that mattered looked bad in the numbers early, and a strict enough reading of the data would have killed them in week one.

And “let the data decide” can be a way to avoid owning a decision rather than a way to make a better one. A number is a wonderful place to hide from responsibility. Sometimes ending the discussion is the problem, not the goal.

The case for Product Managers building has an obvious failure mode: a weekend project teaches you just enough to be dangerous. It is easy to build a toy, feel the real rush of it working, and walk away more confident and less accurate about what real production work costs. Your version had no real users, no legacy, no one else's data to protect. A PM who has shipped a small app might start dictating implementation, or underestimate the hard parts precisely because their own version skipped every one of them. A little technical knowledge, held with too much confidence, can make you a worse collaborator, not a better one.

This is the idea I believe most and can defend least. It may simply not survive contact with scale. Who owns a bug in code an AI generated and a Product Manager opened? When the person accountable for something is not the person who wrote it (and doesn't fully understand it), accountability gets blurry in a way that usually ends badly and quietly.

There is also an anchoring cost. If I arrive with a working proposal, I make it harder for the team to reach a better one. A first draft is a strong prior, and strong priors kill alternatives before anyone says them out loud. And the whole model rests on AI drafts being good enough to be worth reviewing. If they plateau just below that line, the system doesn't get slower. It goes negative, and everyone is too busy to notice why.

None of this makes me think I am wrong. It makes me think these are positions worth holding loosely: strongly enough to act on, lightly enough to drop. I would rather be the kind of product person who can argue against his own conclusions than one who is certain and hopes nobody pushes back. If any of this ages badly, at least this is the page I will have seen it coming from.