Technical Discovery & Needs Qualification Questions

Direct answer

SPIN, MEDDIC and BANT are different tools for different jobs. SPIN is a questioning technique for a conversation: it walks the buyer from facts to felt pain. MEDDIC and BANT are qualification checklists: they tell you whether a deal is real and what you still do not know. I lean on SPIN to run the live discovery conversation, and on MEDDIC to inspect a large deal afterwards. BANT is a lighter first-pass screen.

What each is

SPIN (developed by Neil Rackham) names four question types:

• Situation: facts about their current setup.
• Problem: difficulties and dissatisfactions.
• Implication: what those problems cost or cause downstream.
• Need-payoff: what the buyer thinks a solution would be worth.

BANT is Budget, Authority, Need, Timeline: four boxes that screen whether a lead is worth pursuing.

MEDDIC is a more thorough deal-qualification checklist (qualification means judging whether a deal is real, winnable and worth effort). The letters map as: Metrics, Economic buyer, Decision criteria, Decision process, Identified pain, Champion. In words, they cover metrics (the measurable result the buyer wants), the economic buyer (the person who controls the budget and can say yes), decision criteria (how they will judge options), decision process (the steps and approvals to a signature), identified pain, and a champion (an insider who actively sells for you). Variants add letters: MEDDICC adds a second C for Competition, and MEDDPICC also adds a P for Paper process (the contract, legal and security-questionnaire steps between a verbal yes and a signature). Teams define them slightly differently, so check what your own team means before using a letter in conversation.

Comparison

When to use which: for a small, short-cycle deal with one buyer, BANT questions and a few SPIN questions are enough. For an enterprise deal with security review (the customer's check of the product against its security policy), procurement (the purchasing team that negotiates contracts) and several teams, I use SPIN questions in the room and keep a MEDDIC-style tracker afterwards, because the risk is in what I have not yet learned about the decision process and the economic buyer.

Example questions that reveal technical needs

Trade-offs and pitfalls

• Reading SPIN questions in sequence like a script feels mechanical; use them as a thinking map.
• BANT can screen out a real deal early: a buyer without a budget line today may be able to create one if the pain is large.
• MEDDIC is only as good as the evidence behind each letter. "Champion: yes" with no proof is a false comfort. Ask what the champion has done for you, not what they have said.

Direct answer

Tell a story where you made the conflict visible early instead of smoothing it over, put it in writing as options with trade-offs, and let the person who owned the decision choose. The strongest shape is: separate conversations, a side-by-side comparison, a decision session with a named owner, and a scope that records who gave up what. Below is a skeleton with an illustrative example to be replaced by your own real events.

Story shape

1. Who wanted what, and why each was reasonable.
2. How the conflict surfaced (not in the meeting everyone attended).
3. How you documented it so it was impersonal.
4. How the decision was made and by whom.
5. The prioritised scope, and a measurable result.

Illustrative example

Situation. (Terms: a sponsor is the senior person who owns the project's goal and funding; a decision record is a short written comparison of options.) A financial-services customer wanted a partner-facing application programming interface (API) within eight weeks. Three groups held different priorities:

• Product wanted it live in eight weeks to meet a partner commitment.
• Security wanted every partner connection through private networking (a dedicated link, not the public internet) and multi-factor authentication (a second proof of identity, such as a phone code, on top of a password) for all admin access.
• Operations wanted vendor support staff able to reach production quickly during incidents, which is called break-glass access: emergency access that is approved in the moment and fully logged.

Surfacing. In separate one-to-one sessions each group described its constraint as non-negotiable. Nobody realised the three collided: private networking added weeks of setup, and quick vendor access conflicted with the security rule.

Documenting. I built a one-page decision record:

Decision. I took it to the sponsor, who owned the partner commitment, with a recommendation for option 3 for launch and option 2 as a funded second phase. Security signed the conditions in writing.

Result. Launch scope was read-only partner access on the original date; write operations and private connectivity went to phase two with named owners. In this illustration, the API went live in week 9 for two partners, read-only, and the phase-two items shipped 10 weeks later; in your own story, quote what you actually shipped and when. I would also say which group gave up the most (security's preferred design), because naming the loss kept the group's trust.

Learning. I now interview groups separately first, and bring them together only once the comparison exists.

Pitfalls

• Resolving the conflict by quietly favouring the loudest group.
• Presenting a recommendation as a compromise when it is a trade the sponsor should own.
• No written record, so the same argument returns at the next review.

Direct answer

This is a behavioural question, so tell one true story in a fixed shape: the ask as stated, what you asked or observed that did not fit, the hidden need it revealed, what you changed in the proposal, and the result. Below is the skeleton I would use, filled with an illustrative example. In an interview, replace the details with a real one from your own work and keep every number you quote true.

Story shape (six parts, a longer version of situation, action, result)

1. Situation. The surface request and who made it.
2. Signal. The thing that did not add up.
3. Technique. What you did to dig (questions, data, observation).
4. Hidden need. In one sentence.
5. Change. What you proposed differently.
6. Result and learning. Something measurable, and what you now do by default.

Illustrative example

Situation. A retail operations director asked for "faster monthly sales reports". The team expected a bigger compute cluster (more servers to run the same calculations faster).

Signal. Reports ran in minutes, which did not sound like a speed problem. When I asked "walk me through what happens after the report finishes", I learned analysts exported every report to a spreadsheet.

Technique. Three things surfaced the real issue:

• Questions: "tell me about the last time the numbers were wrong" (the "last time" question gets stories where "what are your requirements" gets a list).
• Observation: I sat with two analysts through month-end. They spent about a day and a half each reconciling returns against sales (checking that returned items had been subtracted from the sales totals), because the report ignored returns booked in a second system.
• Data: the query history showed the report was re-run 4 to 5 times each month, usually after a correction.

Hidden need. Not speed but trust: a reconciled number the director could sign without a manual check.

Change. I replaced "bigger cluster" with a proposal to join the returns data into the reporting model (the set of tables the monthly report is built from) and add a reconciliation view (a saved query that lists only the rows where sales and returns disagree). The first proposal would have made a wrong number arrive faster.

Result (illustrative arithmetic, to be replaced with your real figure). Before: two analysts times 1.5 days each, or 3 analyst-days per month of reconciliation, plus 4 to 5 report re-runs per month. After (illustrative): reviewing exceptions only took about 0.5 analyst-days per month, and re-runs fell to about 1 per month. That is a drop from 3 to 0.5 analyst-days, roughly 83%. State your own measured before and after numbers, and say how you measured them.

Learning. I now ask "what happens after the output is produced" in every discovery, because the real requirement often sits in the step after the one the customer names.

Translating a business ask into a technical proposal

Pitfalls

• A story where you "just knew". Interviewers want the technique, so name what you asked or saw.
• Invented precision. If you do not remember the number, describe the change qualitatively.
• A result that is only "the customer was happy".

Direct answer

I find hidden stakeholders by asking about decisions and history instead of org charts, and by watching who others defer to. I tell a real champion from a friendly contact by testing what the person will do for the deal: a champion has influence, a personal stake in the outcome, and will take small risks on your behalf. A friendly contact gives information, enjoys the meetings, and does none of that.

Finding informal influencers and hidden stakeholders

• Ask decision-history questions. "Who was involved the last time you bought something like this, and who objected?" "If this goes ahead, whose work changes the most?" "Who will be asked whether it worked?"
• Ask the open question every time. "Who else should we make sure is comfortable with this?" People name the quiet gatekeeper surprisingly often.
• Triangulate. Ask three people the same question ("who would you ask if you were unsure about the architecture?") and see which name repeats. Repeated names are real influence.
• Watch meetings. Who do others look at before answering, who gets copied on every email thread, whose objection ends a discussion.
• Follow the work. The platform engineer who reviews every production change, the long-tenured analyst everyone asks for numbers, the procurement officer (the purchasing specialist who manages vendor contracts) who owns the vendor list. None may appear on any chart.
• Read the past. Previous vendor evaluations, incident reviews and architecture decision records (short written notes explaining why a technical choice was made) show who shaped earlier choices.

Champion or friendly contact: use tests, not feelings

A champion (an internal advocate who has power and a personal reason to want you to win) shows up in what they do under a small request:

A scripted exchange: "I want to make sure I am helping you win this internally. Who is most likely to push back, and would you be comfortable if I spent thirty minutes with them first?" A champion answers with names. A contact says "I think everyone is on board".

Worked example

At a large retailer, my day-to-day contact (a manager) praised everything and never answered a question about budget. Three different people mentioned "ask Priya in platform security before anyone signs". Priya was not on any list, and she could block go-live (the date the system is switched on for real use). A week of effort on her concerns did more than a month of calls with the manager. I also tested the manager with the table's request, "could you introduce me to the person who owns the budget?" (the budget owner is the economic buyer, the person who can say yes to the spend). He deflected with "not necessary yet", so he stayed a friendly contact and a source of information. Priya, by contrast, arranged the budget-owner meeting herself, briefed me on what that person cared about, and warned me about one security objection in advance. She had influence over go-live, a personal stake in a safe rollout, and took a small risk for me, so she became the champion I kept investing in.

Pitfalls

• Judging a champion by warmth or by how often they reply.
• Pushing a friendly contact to be a champion; use them as a source and find a champion elsewhere.
• Going around a champion to power without telling them, which burns the relationship.

Direct answer

I would open with a framing line, then ask eight open-ended questions, each aimed at one element of the buying motion (the steps the customer's organisation goes through to evaluate and buy): objectives, pain, success measures, decision criteria (the factors they will judge options by), technical validation (the checks that prove it works in their environment), the economic buyer (the person who controls the budget and can approve it) and a champion (an insider who advocates for us). The labels such as "metrics" and "timeline" in the table echo common sales-qualification frameworks such as MEDDIC and BANT, but the questions work without knowing them. Because three people are on the call, I address each question to the person best placed to answer it and tailor the concern: strategy and risk for the CIO, process and efficiency for the head of operations, features and daily usability for the power user.

Opening line: "Thanks for the time. I would like to spend most of it listening. I have eight questions; please correct anything I get wrong."

The eight questions (all open-ended, none answerable by yes or no)

How the questions shift by stakeholder

• CIO (security, risk, strategy): I would swap question 6 for "What would your security team need to see before they would approve something new?" and ask about vendor consolidation.
• Head of operations (efficiency): I lean on questions 3 and 5 and ask for volumes and cycle times so I can quantify.
• Power user (features, daily use): I ask for specifics, such as "Which screen do you use most, and what is one thing it does badly?" Power users rarely control the budget but often decide whether the tool is adopted.

What I listen for after each answer

• Vague answers to question 1 mean no real executive sponsor (a senior person who owns the outcome and backs the project) yet.
• No recent trigger in question 2 means a soft, exploratory project.
• If the operations lead and the power user describe different workflows, the process is not what leadership believes.
• If question 7 yields "it goes to a committee," I ask who chairs it and request an introduction.
• If no champion emerges in question 8, the deal is at risk until one does.

Closing the role-play

After the eighth answer I read back what I heard in one or two sentences and then propose the next step. Suppose the answers had pointed to cycle time and audit-readiness as the goals and a pilot with the operations team as the thing that would persuade them (only what was actually said goes in a real read-back). I would say: "I heard that cycle time and audit-readiness are the goals, and that a pilot with the operations team would persuade you. Shall I draft a pilot scope for review with your integration owner next week?" The first sentence is the read-back and the second is the proposed next step.

Pitfalls

• Asking all eight questions to the most senior person. The CIO cannot answer question 4 and you waste the power user.
• Treating the first answer as final. Each of these deserves one follow-up ("Say more about that."). If the CIO answers question 1 with "Efficiency", I reply: "Efficiency in what sense? If I looked at your numbers a year from now, which one would have moved, and by roughly how much?" Two words become a metric.
• Skipping question 7 because it feels awkward. Without it the deal has no map.