The Government Published a “Masterclass”
It showed up on my timeline. Japan’s Ministry of Economy, Trade and Industry, in collaboration with Abeam Consulting, published what they called “The Art of Requirements Definition.” A comprehensive guide covering business flow analysis, issue extraction, system architecture, functional and non-functional requirements. Complete with interview templates.
The reposts were glowing. “So useful!” Everywhere.
The day before, I had just finished formalizing a methodology built on the rejection of requirements definition entirely. Then the government dropped their “masterclass.” I laughed.
The Interview Template Fallacy
Interview templates assume a simple premise: ask, and you shall receive.
Walk me through your business flow. What are your current pain points? Describe your ideal state. Each question carefully documented. Organized. Converted into requirements. Signed off. Built.
This straight line does not hold.
Clients cannot articulate what they truly need. When someone says “I want a system that does X,” that is surface-level desire, not the underlying problem. No matter how refined your interview template, you can only capture what the other person is able to put into words.
”That’s Not It” Is the Prize
On a recent project, I built a mockup that perfectly matched the client’s stated requirements. Every color, every layout, every feature — exactly as described in the brief.
The response: “Hmm, something feels off.”
“Something feels off” does not appear on any requirements checklist. There is no field for it in any interview template.
Yet this reaction is the most valuable thing you can get. The moment someone says “that’s not it,” contours begin to emerge. What’s wrong? Where does it catch? The deeper truth — the thing they couldn’t verbalize — surfaces only when confronted with something concrete.
Rejection is the most valuable response. “Close, but this part is wrong” sharpens the resolution. “Looking at this, I just realized…” means the real need has finally broken through.
What questions couldn’t extract, a prototype did.
Stop Asking. Start Building.
This pattern became a methodology. I call it “Making as Asking.”
The traditional approach: Ask. Document. Agree. Build.
Making as Asking: Listen. Probe. Diagnose. Excavate. Repeat. Present.
“Probe” means a mockup, a prototype, an MVP. When a client tells you what they want, don’t respond with words. Respond with something they can see and touch.
It’s fine if it’s wrong. Better, even. “That’s not it” gives you edges. Build something disposable, show it, read the reaction. The reaction reveals what the interview never could.
Requirements are not defined. They are surfaced.
What Makes This Possible
This methodology has prerequisites.
You need to work across every domain — design, code, infrastructure, strategy. And you need AI’s speed of creation. With both, you can produce a probe in hours, not weeks.
Show a mockup the day after the first meeting. Read the reaction. Revise. Show again. This loop runs multiple times a week.
When requirements definition was invented, this speed did not exist. You had to extract everything through interviews, write it into documents, get sign-off, then finally start building. That methodology was born from constraint.
The constraint is gone. So why study its “masterclass”?
Past the “Masterclass”
I’m not dismissing the government’s document. Those interview templates will help plenty of teams avoid missing obvious questions.
But there is a gap between a world that calls this the “art” of the craft and a world that knows interviews alone will never reach the truth.
Between you and your client, two information gaps exist. The first: the client doesn’t know what they actually need. The second: the client doesn’t know what’s technically possible. Interview templates can’t close even the first gap.
Requirements definition was a methodology born from a previous era’s constraints. When one person commands every discipline and AI can produce working artifacts in hours, the old playbook loses relevance.
Make to ask. Ask to dig.
Requirements are not gathered through questions. They are surfaced by building, showing, reading the response, and building again.