The one-page problem statement anyone is allowed to veto

A transformation lead at a manufacturer told me about a project that everyone supported and no two people understood the same way. It was an AI tool for the maintenance team. The plant managers thought it predicted equipment failures. The maintenance techs thought it scheduled their work. The finance sponsor thought it cut spare-parts spending. All three were nodding in the same meetings, funding the same project, picturing three different things. Nobody noticed until the first demo, when all three were disappointed for different reasons.

The failure was not technical. It was that the project had never been forced onto a single page that all three had to agree on. Each stakeholder had filled the vagueness with their own hopes, and the vagueness had survived all the way into a build. By then, satisfying one of them meant disappointing the others, and a lot of money had already been spent discovering that they never agreed in the first place.

So he made a rule. Before any AI project got resourced, it had to fit on one page. The problem, in plain words. The user, one specific role. What success looks like, concretely. And every named stakeholder had to read that page and be allowed to veto it. Cheaply, early, with no shame in saying no.

One page forces the disagreement into the open

A long document hides disagreement. There is so much text that everyone finds the part they like and skims the rest, and the contradictions never sit next to each other where someone would notice. A single page cannot do that. There is nowhere to hide. If the problem statement says “predict equipment failures” and the finance sponsor was picturing “cut parts spending,” the gap is right there on the page, and someone will catch it before it costs anything.

The page has three jobs and no more. Name the problem so plainly that the person living it would recognize it. Name the user as one role, not “stakeholders” or “the business,” because a tool for everyone is a tool for no one. State success as something you could actually observe, so you will know whether you got there. If any of the three is fuzzy, the project is not ready to fund, and the page makes the fuzziness impossible to miss.

The veto is the point

The part people resist is the veto. Giving every stakeholder the power to kill a project on one page sounds like a recipe for nothing ever getting built. In practice it does the reverse. It moves the “no” to the cheapest possible moment.

A veto on page one costs a conversation. The same objection in month five costs the build.
When anyone can veto early, people stop staying quietly skeptical and voicing it after launch.
A project that survives everyone’s veto is one where the disagreement already got resolved, before the money.
A project that gets vetoed on the page did not fail. It got stopped before it could waste a quarter.

A head of operations at a hospital network ran the same practice and told me the vetoes were the most valuable meetings she ran. Most projects passed. The few that got vetoed were always ones where two departments wanted incompatible things, and finding that out on a page, in an hour, saved months every single time. The veto was not friction. It was the cheapest quality gate she had.

The manufacturer’s maintenance project eventually shipped, but only after the one-page version forced the three stakeholders to pick which problem they were actually solving. They chose failure prediction, finance agreed the parts savings would follow from it, and the techs got a say in how it fit their day. One page, one agreed problem, one user. The version that worked was the version they were forced to write down together.

How we approach it at Density Labs

The AI Opportunity Assessment, our fixed two-week engagement at $2,500, produces exactly this kind of shared page. One problem, one user, one clear picture of success, written so every stakeholder can read it and object before anyone builds. Sometimes the most useful outcome of the two weeks is a page that gets vetoed, because a clear no in week two is worth far more than a muddled yes that three people interpret three ways for six months.

Put the problem, the user, and success on one page, and let anyone kill it there. It is the cheapest place a project will ever die.