The Discovery Question That Changes Everything

There’s one question that’s started showing up in almost every discovery conversation, and it changes the whole dynamic in the room when it lands right: “What would have to be true for this project to be worth it?”

Getting Past the Requirements List

Not “what are your requirements.” Not “describe your ideal future state.” That specific question, in those exact words.

Most discovery processes are built to extract requirements. What screens do you need? What reports? What integrations? Those questions produce useful documents, but they rarely get anywhere near the actual reason someone is sitting in the room. They describe the system someone thinks they want, not the outcome that would make them look back a year later and say the investment was right. “What would have to be true” skips past the feature list and goes straight for that outcome.

It’s a harder question to answer than it sounds, which is exactly why it works. People pause. They stop reciting the list they came in with and start actually thinking about what they’re chasing. And the answers that come out are rarely about software at all.

A CFO, asked this question recently, said: “I want to close the books and actually trust the number. I want to stop running parallel spreadsheets to verify what the system says.” That’s not a requirement. No line item on a spec sheet captures it. But it tells you immediately what success actually looks like for that person, and it tells you that if the new system produces a number people still feel the need to double-check by hand, the project has failed regardless of what got delivered.

An operations director answered differently: “I want to stop dreading the month-end. I want it to just be another week.” Nothing in a requirements document says “reduce dread.” But that answer points straight at where the real friction lives, and it reframes the whole project around removing a specific, lived experience rather than checking off a set of functional boxes.

What the Answers Actually Reveal

A CEO put it a third way: “I want my team to come to me with business problems, not system problems.” That single sentence says more about organizational health than any process map could. It tells you the system itself has become a distraction from the work people are actually supposed to be doing, and it makes clear what the project needs to fix isn’t a screen or a workflow, but that dynamic.

None of those three answers would show up in a traditional requirements document. Yet each one becomes the actual north star for everything that follows. It’s the thing you keep coming back to when a scope decision gets hard, or when a stakeholder wants to add one more feature that sounds reasonable but doesn’t move the real goal forward. Without that anchor, projects drift toward whatever the loudest voice in the room wants next. With it, every decision has something concrete to be measured against.

This is also why the question has to be asked in those specific words, and not paraphrased into something softer. “Describe your ideal future state” invites a description of a system. “What would have to be true” invites a description of a life that’s different—the CFO who stops running parallel spreadsheets, the ops director for whom month-end becomes forgettable, the CEO whose team brings her real problems instead of system complaints. Systems are the means. Those are the ends.

Getting to that answer takes patience, and it takes being willing to sit with an uncomfortable pause while someone works out what they actually mean. But it’s worth it. A project scoped around a feature list will get built and still miss the point. A project scoped around what would have to be true for it to matter has a real chance of actually mattering.