‘Make it smart’ is a wish, not a requirement

A VP of engineering at a fintech told me the phrase he had learned to stop and question. “Can we make this smarter with AI.” It arrived in planning meetings attached to all sorts of features. The dashboard should be smarter. The alerts should be smarter. The onboarding should be smarter. Everyone nodded, because who wants the dumb version.

He stopped nodding after a couple of projects that consumed real budget and shipped nothing anyone could point to. The problem was not the ambition. It was that “make it smart” is a wish. It cannot be built, because it cannot be tested, and anything that cannot be tested cannot be finished.

So he started converting the wish into a requirement before any work began. He did it with three questions.

Three questions turn a wish into a requirement

The questions are simple and unforgiving. What is the input. What is the output. What counts as correct.

Take “make the alerts smarter.” On its own it means nothing. Run it through the questions and it either becomes real or falls apart. What is the input? The stream of transactions plus each customer’s recent history. What is the output? For a given transaction, a flag of suspicious or not suspicious. What counts as correct? A flag that agrees with what a fraud analyst would have decided looking at the same information.

Now you have something. You can build it, because you know what goes in and what comes out. You can test it, because you have a definition of correct to measure against. You can tell when it is done, because “done” is a level of agreement with the analyst, not a feeling that it seems smarter.

The magic of the three questions is that a lot of “smart” ideas do not survive them, and that is the point. If you cannot say what the input is, you do not have a feature. If you cannot describe the output concretely, you are going to build something and argue about whether it is right forever. And if you cannot define what counts as correct, you have no way to know whether the model works or to improve it when it does not. Better to learn that in a meeting than after a quarter of engineering.

He was strict about the third question especially. “What counts as correct” is where teams wave their hands. They will define the input and output, then say correctness is “obvious” or “we will know it when we see it.” That is not a definition. It is a promise to disagree later. He made teams write down, before building, how they would decide whether a given output was right, ideally by pointing at what a specific human would have done with the same input.

The vagueness is usually hiding a hard question

A head of support at a software company described the same move from her side. Her team wanted an AI that would “understand” customer emails. He asked her the three questions and the word “understand” dissolved. Understand to do what? To route the email to a team. Fine. Input is the email text. Output is one of eight team names. Correct means the same team a trained agent would have picked. Suddenly it was a classification task with a clear test, not a philosophical goal. And once it was concrete, they could see it was achievable, which the vague version never let them judge.

The vagueness is not laziness. It is often a place where a genuinely hard question is hiding, and the fuzzy language lets everyone avoid it. “Make it smart” sometimes unpacks into “make a judgment call that even our experts disagree on,” and the three questions drag that into the open where you can decide whether it is worth attempting at all.

How we approach it at Density Labs

A large part of the AI Opportunity Assessment, our two-week fixed engagement at $2,500, is taking the aspirational language a company arrives with and converting it, feature by feature, into inputs, outputs, and a written definition of correct. The ones that make it through become buildable projects with a clear finish line. The ones that do not usually reveal a hidden hard decision the company is better off seeing now, before funding it, than after. Either outcome is worth far more than the price of the engagement.

If someone asks you to make a feature smart, do not start building. Ask what goes in, what comes out, and how you will know it is right. If those do not have answers yet, the requirement is not ready, no matter how good the wish sounds.