I built an AI tool that worked. I shut it down anyway.

The bet was simple. My product team's ticket intake was where quality went to die: vague requests, missing context, requirements that meant one thing to the person who wrote them and another to the engineer who picked them up. So I built an AI tool for my own team that auto-structured and enriched Jira tickets at intake — normalize the vague stuff before it hits the backlog, kill the downstream rework.

It worked. Requirement misunderstandings between product and engineering — which we measured as complaints from engineering about ticket quality coming out of grooming — dropped about 27% in the first month, and kept improving for months after. Teams that had never sustained a groomed backlog two sprints deep suddenly could. If you've run a product org, you know what that does for planning and velocity. I was proud of that number. I quoted it in reviews.

Nine months in, I shut the tool down.

The number that made me proud was already softening by month six — but that's not why I killed it. I killed it because of what I watched happen around the metric. Around month six, the complaints from engineering started creeping back. Not because the model's output got worse, but because some of my PMs had stopped reviewing it. The tool wrote clean, confident, well-structured tickets, and clean, confident, and well-structured is exactly what wrong looks like when nobody checks. They stopped correcting its mistakes. Errors that used to get caught upstream started landing on engineering, and the friction moved to the worst possible place: the trust boundary between product and engineering.

Here's the uncomfortable math. About a quarter fewer misunderstandings is not worth teaching a team to outsource its judgment to a black box. The first is a metric. The second is a habit, and habits compound.

So I killed it — with two PMs relying on it daily, and telling me exactly what they thought of the decision. It was still the right call.

The principle I took from it: an AI tool people can't verify — or won't — stops being an asset and becomes a liability. Not eventually. The moment verification stops. The output doesn't even have to get worse. Trust in an AI system has to be earned continuously, and the only way I know to earn it is to make the system show its work.

That principle is now load-bearing in everything I ship. The natural-language-to-SQL platform my team runs in production across 60+ markets exists in its current form because of that dead Jira tool. Non-technical users ask questions in plain language and get an answer or a chart back — and every answer carries the actual query it ran, transparent and auditable. Anyone can ask. Everyone can verify. That isn't a compliance checkbox. It's the reason enterprise clients trust it with real decisions, and why it has supported millions in revenue and client retention.

Three things I'd offer any product leader shipping AI right now

1. Instrument the humans, not just the model. My dashboards said the tool was winning. Watching how people used it said otherwise. Both were true; only one mattered long-term.
2. "It works" is where the risk starts, not where it ends. The better the output looks, the faster verification erodes. Design for the day your users trust it too much, because that day is coming.
3. Be willing to kill your wins. Anyone can shut down a failure. The decisions that shape a team are the ones where the metric says keep going and the judgment says stop.

See the principle running

I wired the same idea into a live demo on this site: it streams its reasoning steps and refuses to answer anything it can't ground. Poke at the live demo, or read how the same principle shaped the conversational analytics platform.