Every discovery engagement we run ends with a shorter list than it started with. That’s not a coincidence. It’s the point.
Most people think of discovery as the phase where you figure out what to build. That’s half right. The more important half is figuring out what not to build yet, and doing it before a single line of code gets written, when cutting a feature costs nothing more than a conversation.
Discovery’s job isn’t to find more requirements. It’s to decide which ones don’t earn a place in version one.
A requirements list that keeps growing looks like progress. It isn’t. A bloated scope doesn’t look expensive on day one, it looks thorough. It gets expensive three months in, when half the “nice to have” features are still unbuilt, the timeline has slipped to accommodate all of them, and nobody can remember which ones the business actually needed versus which ones just sounded reasonable at the time.
What a Bounded Discovery Process Looks Like
A discovery process worth paying for should be able to name, specifically, what got cut and why, not just what got included. If it ends with more scope than you walked in with, that’s a sign something’s missing, not a sign you got your money’s worth.
That requires someone in the room who has something to lose if the scope is drawn in the wrong place: a delivery timeline, a budget, a reputation for shipping things that work. Holding that line is the actual skill discovery is paying for. It’s also the part that’s easiest to skip, because saying no to a feature takes more judgment than saying yes to one.
The Same Problem Shows Up Differently With AI
That skill matters more, not less, now that AI tools have made it easy to generate a requirements document in minutes. Ask an AI tool to draft requirements for a new internal tool and it will hand you back a document with forty features. Authentication with role-based permissions. An admin dashboard with analytics. Notification preferences. Audit logs. Every item sounds reasonable on its own. None of it tells you which fifteen of those forty actually need to exist before launch.
That’s not a flaw in the tool. It’s what the tool is built to do. Generation is additive by design, give it a prompt and it produces plausible options, and every option is easy to justify in isolation. An AI model has no stake in what ships. It isn’t accountable for a timeline, a budget, or the team that has to build and maintain whatever gets approved. Asked “should we include audit logs,” it will explain why audit logs are generally good practice, because they are. It has no reason to ask whether this particular business, at this particular stage, actually needs them yet.
That’s the part a real discovery process still has to supply, AI-assisted or not.
This Isn't an Argument Against Using AI
AI tools are genuinely useful for the front half of discovery: drafting a starting list, surfacing options a team hadn’t considered, moving faster through the parts that are mostly research. The problem isn’t using them. It’s stopping there, and treating a generated list as a finished scope instead of raw material that still needs someone to cut it down.
Where This Leaves You
If you’re scoping a build right now, AI-assisted or otherwise, the question worth asking isn’t “does this feature make sense.” Almost everything on a generated list will make sense. The question is what your version one actually needs to prove, and what can wait until it does.
That’s the starting point of every discovery engagement we run, and it’s the conversation worth having before a build starts, not after.