“We need an ERP. Purchasing, sales and inventory. Reports. And we need to see it on our phones.” That's the line owners say most often when a requirements interview opens. The vendor nods, writes it down, goes back and sends a quotation. Six months later the system goes live. Purchasing, sales and inventory: done. Reports: done. Phone access: done. But the warehouse is still on its own Excel file, and sales is still taking orders on LINE. Every feature got built. Not one real problem got solved.
I'm Johnny Yang, founder of Brightstream Technology. In seven years of running this company, my team has delivered 252+ projects across 32+ industries. I've owned businesses in six industries myself, and I've lost money, so I know what owners want to hear at the interview table, and what they often leave out. After seven years, the one thing I'm most sure of: when a system is built wrong, it usually went wrong at the first interview.
A requirements interview isn't looking for “what features do you want.” It's looking for “what is leaking money, time, or customers right now.” 90 minutes is enough, if three things are true: the person who signs off and the person who handles that order every day are both in the room; you bring real documents and the Excel file people open most; and you follow four stages — talk about cost first, walk one real order from start to finish, dig out the exceptions, and cross off what shouldn't be built. When the interview ends, you need a written list of problems and features, where every item can answer “what happens if we don't build this.” If it can't, it doesn't get built yet.
The owner knows where to go, but not always how the floor gets there
To be fair first: when the owner drives requirements, the direction is usually right. You know where the company needs to grow, where it's losing money, which customer matters most. No single employee sees that full picture.
But a system handles daily actions, and the owner often hasn't done those daily actions personally in a long time. How does an order go from LINE to a shipping order? When a customer changes the quantity at the last minute, what does the salesperson update first? When the warehouse is short, who decides which customer gets stock first? The owner knows it's “roughly like this.” The real rules, exceptions and shortcuts live with the people on the front line.
If the interview only listens to the owner, the system will fit the company the owner imagines, not the company that actually runs. That's why so many systems go live, staff say “that's not how we do it,” and quietly go back to Excel.
We worked with a printing company that had spent over NT$1,000,000 on two ERP systems, and neither got used. The third one was built around their own workflow. Staff adoption went from under 20% to over 90%, and quotations that used to take 30 minutes to calculate by hand are now estimated automatically. The difference wasn't the number of features. It was that the system looked like what they actually do every day. The full story is in Over NT$1,000,000 on two ERPs nobody used.
Before the interview: who needs to be there, and what to bring?
Whether 90 minutes is enough mostly depends on the prep. The most common waste: you book the meeting, the people in the room can't give the details, they have to go check, and you book another one next week.
| Role | Why they need to be there | What happens if they're not |
|---|---|---|
| Owner or general manager | Says clearly what to solve, how much to spend, what not to build | Direction keeps shifting, scope never closes |
| The person who handles that order every day | Knows the real steps, exceptions and shortcuts | System is built on the ideal process, nobody uses it after launch |
| Finance or accounting | How numbers are defined, reconciled and closed | Report numbers don't match the books |
| Downstream managers who'll be affected | Whether changes upstream will jam them | Upstream flows, downstream clogs |
| The vendor or responsible IT | Judges feasibility and cost on the spot | You find out later it can't be done or costs a lot |
You don't need many people. Three to five is fine, but they have to be the right ones. Especially the second type: the people who actually handle the work every day can't be replaced by their manager. Managers know the rules. The floor knows the exceptions.
Bring three things: real documents from the last month (orders, shipping orders, quotations — pick a few representative ones), the Excel file everyone opens most, and the last order that went wrong. That last one is the most valuable, because it shows you exactly where the process breaks.
Also, a few days before, ask the owner to answer three questions in writing: what's the one thing you most want to solve this time, what happens a year from now if nothing changes, and how much time and budget are you willing to put in. It doesn't need to be formal. A few sentences. With those three thought through, the interview won't open with “we need an ERP.” It'll open with a specific problem, and the first fifteen minutes will be far more productive.
How to run the 90 minutes: four stages and a wrap-up
| Time | What to do | Key question | Output |
|---|---|---|---|
| 0–15 min | Talk cost, not features | What goes wrong most often, and how much does one mistake cost | Two to three of the most painful problems |
| 15–45 min | Walk one real order from start to finish | Who touches this order, where does it stop, where does it get retyped | One real workflow |
| 45–70 min | Dig out exceptions | When doesn't it go this way, and how was it handled last time | Exception list |
| 70–85 min | Cross off what not to build | What happens if we don't build this, how many times a month does it happen | Don't-build list |
| 85–90 min | Converge | If you could only fix one thing first, which one | Priorities |
0–15 min: talk cost, not features
Don't open with “what features do you need.” Ask “what's giving you the biggest headache right now” and “when was the last mistake, and how much money or time did it take to clean up.” The answers will be concrete: missed orders, wrong quotations, three days to reconcile at month-end, not being able to tell a customer the delivery date.
The point of this stage is to get everyone to the same answer on “what are we solving this time.” Features are the means. The cost is the target. Once the target is clear, every feature that comes up later can be checked against it: does this feature solve the thing we just talked about?
15–45 min: take one real order and walk it start to finish
This is the most important thirty minutes of the interview. Pick a recent real order and have the person who handled it start from the customer's first contact: who took it, where it was recorded, who it went to next, how it was handed off, where it waited and for how long, which step had it typed in again.
You'll find a lot the owner didn't know: the same data typed three times, a step that can't move until a manager replies on LINE, a step that's actually done from one senior employee's memory. Those are the places the system most needs to step in. For drawing the workflow more completely, see How to map processes: every company workflow on one sheet of paper.
45–70 min: dig out exceptions
Everyone can describe the normal flow. What actually kills systems is exceptions. In this stage, keep asking: “When doesn't it go this way?” What if the customer wants partial shipments? How do you record a specially negotiated price? Goods arrive with a quality problem and get sent back — how is that handled in the books?
For every exception, ask two things: how many times a month it happens, and how it was handled last time. Frequency decides whether it's worth putting in the system. Last time's handling decides what the system should look like.
70–85 min: cross off what not to build
This stage gets skipped most often, and it saves the most money. The line I say to owners most often is “don't build this.” Of ten things you want to automate, about two are worth writing a system for, five just need off-the-shelf tools, and three shouldn't be touched at all. Used twice a month, different rules every time, nobody maintaining it after it's built: those are the three.
Go through every requirement mentioned so far, one by one: what happens if we don't build this? If the answer is “five more minutes” or “someone handles it manually now and then,” cross it off for now. I explain why in more detail in Why I often tell clients “don't build this”.
85–90 min: converge
The last five minutes, one question: if you could only fix one thing first, which one? That answer is the scope of phase one. Everything else goes later. Not “we won't do it.” Just not all at once.
Five interview questions that work best
Once the agenda is set, how good your questions are decides how deep you get. These five are the ones I use most on site. Each one forces a concrete answer, not an abstract “we want to be more efficient.”
- “When did this last go wrong? How much did it cost?” Turns complaints into a cost you can measure. A problem nobody can answer this for is usually less serious than it seems.
- “If this stopped tomorrow, who would notice first?” Finds the real user of the step, and also finds steps nobody needs at all.
- “Who updates this Excel file? How often?” Every Excel file in long-term use represents a need the system isn't covering.
- “How many times has this rule changed in the past year?” Rules that change often need to be adjustable in the system by your own team. Rules that never change can be hard-coded.
- “Who makes this call right now? What happens when they're on leave?” Finds the rules that live only in one person's head. Those most need to be written into the system.
Question five matters most. In a lot of companies, key rules exist only in the memory of one or two senior employees. When they take leave or quit, the process stops. When you hit this in an interview, ask that employee to lay out the basis for their judgment, item by item. For example, “which customers can ship before paying” or “who gets stock first when materials are short.” If they can state the conditions, it can go into the system. If they can't, and it's a gut call every time, write it down and don't rush to automate it.
When the interview ends, what should you have in hand?
If, at the end of 90 minutes, everyone walks away with nothing but “that felt like a good conversation,” the interview was wasted. You need at least the following, in writing:
- Two to three problems to solve this time, with the cost of each
- One workflow walked through with real documents, marking where it stops and where it gets retyped
- Exception list, each item marked with roughly how many times a month it happens
- Don't-build list, with the reason for each
- Phase one scope, containing only the most painful problem
- Open questions that need to be confirmed, and who's responsible for answering each
Once organized, this becomes the first draft of the feature list. At Brightstream, we write the scope into a feature list on paper first, then quote a fixed price. No “sign first, add charges later.” With the scope written down clearly, the quotation has a basis, and both sides have something to check against later. For how to write a feature list that lets a vendor quote accurately, see How to write ERP requirements specs.
How to tell if a vendor's interview is any good
If the vendor runs the interview, you can turn it around and use it to evaluate them. Watch for these signals.
Good signs: asks to see real documents, keeps pressing on exceptions, asks “how did you handle it last time it went wrong,” volunteers that some requirements should wait, and at the end repeats back the key points so you can confirm.
Warning signs: just ticks through a feature list item by item, says “we can do that” to every requirement, asks nothing about money or time, produces nothing in writing after the interview, or starts pitching their own system's features before hearing out your workflow.
A vendor who says “yes” to everything isn't more capable. They haven't started thinking about your problem yet. The one willing to say “I don't recommend building this” on the spot is usually the one who actually understood.
FAQ
Is one 90-minute requirements interview enough?
A first interview of 90 minutes is enough to find the most painful problems and the phase one scope. But companies with complex workflows and many departments usually need a few more sessions on specific workflows, each focused on one. The first interview's job is to narrow the direction, not to ask every detail at once.
Does the owner have to attend in person?
The owner must be there for the opening fifteen minutes and the final five. The middle — walking documents and digging out exceptions — can be handed to floor managers. But crossing things off and setting priorities needs someone who can make the call. With the owner fully absent, scope keeps growing. With the owner running the whole thing, the floor staff won't tell the truth.
What if staff won't speak honestly in front of the owner?
Split off the document walkthrough: talk to floor staff on their own first, then bring the organized workflow to a session with the owner to confirm. Another approach: ask everyone to bring the orders that went wrong. Letting the documents do the talking gets real answers more easily than asking “what do you think isn't working.”
What if requirements change mid-development, after the interview?
Requirements will change. What matters is that changes follow rules. Write the new requirement down, assess its impact on scope and timeline, then decide whether it goes into this phase or the next. It doesn't get added just because someone mentioned it out loud. I've laid out a full approach to managing changes in What to do when requirements keep changing during development.
Find the leak first, then talk features
The point of a requirements interview, in one line: don't ask “what features do you want,” ask “what's costing you right now.” Get the right people in the room, bring real documents, and go through cost, workflow, exceptions, and what not to build, in that order. In 90 minutes, a vague “I need an ERP” turns into a list where every item has a cost attached.
If you're about to look for a vendor and want to sort out your own requirements first, see How ERP implementation works for what to prepare at each step from interview to go-live.
