For founders
Scope any AI feature on one page
RAND's study of why AI projects fail puts a misunderstood problem at the top of the list. Before I build an AI feature I write one page with five sections. It takes an afternoon and it removes the most common way these projects die.
Prashant Kumar Singh · · 4 min read
In short
- RAND's interviews with 65 data scientists and engineers found the leading cause of AI project failure was stakeholders misunderstanding or miscommunicating the problem.
- A one-page brief with five sections (user and job, data you have, three good answers, one metric, what happens when it is wrong) forces that misunderstanding into the open before any code.
- The three example answers become your first tests. The wrong-answer section becomes your UI.
In 2024 RAND interviewed 65 experienced data scientists and engineers about AI projects that failed. The first cause on their list was not the model, the data or the team. It was that the people commissioning the project misunderstood or miscommunicated the problem the AI was supposed to solve.
I have watched that happen from the inside. The fix I use is not a longer requirements document. It is a shorter one: a single page, five sections, written before anyone opens an editor. Here is the page and why each section is there.
1. The user and their job
One person, one job. Not "users" and not "the team". A sales rep who has to write a follow-up email after every call. A support lead who has to decide which of forty tickets to escalate. If you cannot name the person and the job in one sentence, the feature is a technology looking for a reason.
2. The data you actually have
Not the data you wish you had or plan to collect. What is in the database today, how clean it is, and whether the user is allowed to see it. Most AI feature ideas quietly assume a data source that does not exist yet. Writing this section is where that assumption gets caught, and it is far cheaper to catch it here than in week four.
3. Three example good answers
Write three concrete outputs the feature should produce, for three real inputs. Not descriptions of outputs, the outputs themselves. This section does two things. It makes the stakeholder commit to what good looks like, which surfaces disagreement immediately. And it becomes the first three test cases, so the engineer building the feature has something to check against from day one.
4. One metric
Usage, accuracy or time saved. Pick one. A feature with three success metrics has none, because any outcome can be called a win. If the metric is time saved, say how it will be measured and what the current number is. If nobody knows the current number, that is the first task.
5. What happens when it is wrong
This is the section nobody writes and everybody needs. The model will be wrong some of the time. What does the user see? Can they check the source? Is there a fallback? Does a person approve before anything changes? The answers decide the interface more than the model does, and they decide whether users trust the feature after the first bad answer.
Why one page works
A long requirements document hides disagreement in its length; everybody reads the parts they care about and assumes the rest. One page has nowhere to hide. If the founder and the engineer read it and picture the same thing, the project has cleared RAND's first cause of failure. If they do not, you have found out on an afternoon instead of a quarter.
I write this page at the start of every AI feature I scope, including the ones I build inside a call-intelligence platform at Ringover. The features that shipped well all had a clear answer to section five. The ones that struggled were the ones where "when it's wrong" was answered with "it won't be".
Questions people ask
- What is the most common reason AI projects fail?
- According to RAND's 2024 study of 65 practitioners, the leading cause is that stakeholders misunderstood or miscommunicated the problem the AI was meant to solve, ahead of data quality, infrastructure and model choice.
- What should an AI feature brief include?
- Five things on one page: the single user and their job, the data that actually exists today, three concrete example good answers, one success metric, and what the user sees when the model is wrong.
- How long should scoping an AI feature take?
- An afternoon for the one-page brief. The point is not depth; it is making the founder and the engineer picture the same feature before any code is written.
If you're a founder
Send me the feature you are planning, in whatever shape it is in. The free teardown will come back as this one-page brief filled in, with the gaps marked.
If you run an AI lab or data team
Section three of the brief, three concrete good answers, is the same discipline as writing a golden answer before you write a rubric. Tasks and features both fail when "good" is left to be discovered later.
Sources