The kickoff you should refuse until the problem is named

A CTO at a mid-market professional-services firm told me about the meeting he learned to end early. A team would come in excited, with an AI idea and a rough plan to start building next sprint. He used to say yes. Momentum felt good, and saying yes was easier than the alternative. After watching a few of those projects wander for months and quietly die, he started doing something that made him briefly unpopular. He refused to start.

Not forever. Until three things were written down. What problem this solves. Who has that problem. What success looks like, in terms he could check later. If a team could not put those three on a page, he sent them back, and he did not schedule the build.

Enthusiasm is not a spec

His reasoning was earned the hard way. Every project that had wandered shared the same origin. It started from a capability, an eagerness to use AI, a sense that there was value somewhere in the data. None of them started from a named problem with a named owner and a definition of done. So they built, and because nobody had written down what they were solving, there was no way to tell when they had solved it. The projects did not fail loudly. They drifted, because they never had a shape to hold.

The three questions look almost too simple to matter. That is exactly why they get skipped. Naming the problem forces you to admit whether there is one, or whether you just have a technology you want to use. Naming the user forces you to point at a real person, not a vague beneficiary, and vague beneficiaries are how features get built for nobody. Naming success forces you to say, before you start, how you will know it worked, which is the only thing that lets you ever stop. A project without those three can run indefinitely, because it has no way to be finished.

This is the thread running through most of the ways AI projects go wrong. The team that automated the slow step that was starved from upstream had not named the problem, only the symptom. The feature that solved a problem the users did not have had never named the real user. The pilot that looked great and failed in production had never written down what success meant under real conditions. Each of those was a kickoff that should have been refused until the page existed. The refusal is not bureaucracy. It is the cheapest quality gate a project has, and it happens before you spend anything.

There is data behind the caution. MIT found in 2025 that around 95 percent of enterprise generative AI pilots deliver no measurable return. A large share of that is not a modeling failure. It is projects that started before anyone could say what problem they solved or how they would know it worked. You cannot measure a return on a project that never defined what winning looked like.

A colleague who leads engineering at a healthcare company enforces the same rule with a lighter touch. She does not refuse kickoffs outright. She asks the team to write the press release for the finished feature first, the short version describing who it helped and how. If they cannot write it, they do not understand the project yet, and she treats that as the signal to keep scoping rather than start coding.

Write the page before you build

The practice is small and it holds up. Before an AI project gets a sprint, it gets a page, and the page answers three questions:

What specific problem does this solve, and for whom?
Who is the real person who has this problem today, and how do they handle it now?
What does success look like, in something you can check later?

If those cannot be answered, the project is not ready, and starting it will cost more than the delay of writing them down. The refusal feels like friction in the moment. It is the moment that saves the quarter.

None of this slows a good project. A team with a real problem, a real user, and a clear definition of success can fill the page in an afternoon, because they already know the answers. The teams that cannot fill it are the ones you most want to catch before they build, and the page is what catches them.

How we approach it at Density Labs

Naming the problem, the user, and the definition of success is the spine of the AI Opportunity Assessment, our two-week fixed engagement at $2,500. We do not scope a build until those three are on a page the client agrees with. Sometimes the outcome is a clear, funded project. Sometimes it is the honest finding that there is no problem worth a model yet, and that is a far cheaper thing to learn in two weeks than in two quarters of a drifting build. Either way, the client leaves knowing what they are solving and how they will know it is solved.

Do not start building until you can name the problem, the person who has it, and what success looks like. The kickoff you refuse is cheaper than the project that never should have begun.