A founder once walked me through their product, a tool that automatically drafted replies to customer support tickets. The demo was clean. A ticket came in, the system read it, pulled the relevant account details, and produced a polished response in seconds. The room was impressed. I asked one question: how does your support team handle tickets today? There was a long pause.
That pause is where most AI products quietly die. Not in a dramatic failure, not in a server crash, but in the silence that follows a simple question nobody thought to ask early enough. The product was solving for speed of drafting. But when we traced how that team actually worked, drafting was never the slow part. Their agents could type a reply in under a minute. What ate their day was figuring out which tickets mattered, chasing answers across three systems that didn’t talk to each other, and second-guessing whether a reply was safe to send without a manager’s sign-off. The clever part of the product was aimed at the one step that didn’t hurt.
This is the trap, and it has almost nothing to do with the model. The model works. The engineering is often genuinely good. The demo lands, everyone nods, and the thing ships. Then the usage graph stays flat, and the team reaches for the wrong fixes. Better prompts. Faster responses. A cleaner interface. All of it polishing a solution to a problem the user didn’t actually have.
The reason this keeps happening is that building is more comfortable than understanding. Understanding means sitting with a user while they do their job badly, watching them cope, and resisting the urge to pitch your solution before you’ve earned the right to. Building means opening your editor and feeling productive within the hour. One of those feels like progress. The other one is progress.
Who is in pain right now, and how do they cope today without us?
There’s a question worth asking before a single line of code gets written: who is in pain right now, and how do they cope today without us? The second half is the one people skip, and it’s the more important, because how someone copes tells you what you’re really competing against. A spreadsheet. A junior employee doing tedious work by hand. A workaround so ingrained nobody calls it a problem anymore.
The founders who get this can answer in one clean sentence. The freight broker reconciles rate confirmations by hand for two hours a day, and copes by staying late. When the sentence is that sharp, the product almost designs itself. When you can’t write it, no model will save you.
So I treat that sentence as a gate. If a problem can’t survive being stated plainly, it isn’t ready to be built, and that’s a gift. It’s far cheaper to kill an idea at the sentence stage than after a quarter of engineering. The best thing a product can do is remove a reason someone is struggling. The model, the interface, the automation, is just the shape that relief takes. Stay loyal to the problem, and you’ll always be free to change the shape.
