Most AI projects don’t fail because the technology couldn’t do the job. They fail because nobody wrote down what the job was.
I’ve watched this happen more than once. Someone gets excited about what AI can do, spins up a project to “improve efficiency” or “save time,” builds something, and six weeks later the thing is running but nobody can say whether it worked. There’s no number to check. So when the next priority arrives, the project quietly gets shelved, and everyone moves on. It didn’t fail. It just never got the chance to succeed.
A goal you can’t measure can’t be defended
“Improve efficiency” feels like a goal. It’s really just a direction.
The problem shows up later, when you need to justify the time you spent. If the goal was “save time,” how much time? Compared to what? A vague goal has no baseline, so there’s nothing to compare against, so there’s no way to prove the work paid off. A project you can’t prove is a project you can’t defend. It dies undefended, not because it failed but because nobody could argue it succeeded.
This hits solopreneurs harder than anyone. You don’t have a team to absorb a stalled project. Every hour you spend building the wrong thing is an hour off your own calendar. You need to know early whether something is working, and “it feels a bit faster” is not knowing.
Write the target before you build
The fix is boring and it works. Before you build anything, turn the vague goal into a number. Three parts:
- Baseline — the number today, measured, not guessed. “Roughly a day” is not a baseline. “6.2 hours on average across last quarter” is.
- Target — the specific number that makes the work worth it, by a specific date.
- Measurement — where the number comes from and when you’ll check it.
That’s it. If you can’t fill in all three, you don’t have a project yet. You have a wish.
The reason to do this first, not after, is that the numbers change what you build. A target of “under three hours” points you at a different tool than “under thirty minutes.” Decide the finish line before you start running, or you’ll build toward whichever line is easiest to reach and call it a win.
Vague vs measurable
Here’s the same project stated both ways.
Vague: “Use AI to help with our customer support.”
You can build against that forever. There’s no version of it that’s done.
Measurable: “Cut average ticket resolution time from 4.2 hours to under 3 hours within 90 days, measured from the ticket system, without customer satisfaction dropping below 3.8 out of 5.”
Now the project can succeed or fail, which means it can teach you something either way. Notice that last clause. Resolution time on its own is gameable: close tickets faster without solving anything and the number drops while your customers get angrier. So you pair it with a metric that moves the opposite way if the first one gets gamed. The satisfaction score is the tripwire.
Measurable goals give you one more thing vague ones can’t: a point at which you stop. “If we’re not under 3.5 hours by day 60, we reassess.” Without that line, a struggling project keeps eating your Tuesdays, because there’s never an obvious moment to kill it.
The number is the cheap part
Writing the target takes ten minutes. Building the wrong thing takes six weeks. That’s the trade, and it isn’t close.
This is one of the framework-superpowers we reach for before any build: decide what winning looks like, in numbers, before a single line of the thing exists. It sits next to the question validate-superpowers asks first, which is whether you should build the thing at all. Both come before the fun part, and both spare you the most expensive kind of AI project, the one that runs forever and proves nothing.
So before your next build, answer three things. What number are you moving? What is it now? What would make the work worth it, and by when?
If you can’t answer those, don’t start yet. If you can, you’ve already done the part most people skip.
Stuck turning a fuzzy goal into a number? That’s exactly the conversation we like having. Get in touch.