Technical Discovery & Needs Qualification Questions

Direct answer

Pick a real story where something you learned after your first proposal broke an assumption, and show three things: how fast and honestly you told the customer, how you re-shaped the proposal with options instead of one fixed answer, and what process change you made afterward. Below is a skeleton with an illustrative example. In the interview, use your own events and only numbers you can defend.

Story shape

1. The first proposal and the assumption underneath it.
2. The discovery that broke the assumption, and how it surfaced.
3. What you did the same day: tell the customer, in plain words, with evidence.
4. The re-worked proposal: options, trade-offs, revised acceptance criteria.
5. Outcome, then the lesson as a habit you changed.

Illustrative example

First proposal. For a logistics customer I proposed a real-time event stream from a partner's warehouse system into their dashboard, with updates within seconds, based on a call with the product owner.

Discovery. Two weeks into deeper technical sessions, I met the partner-integration engineer, who said the warehouse system exposes only a nightly file drop over SFTP (file transfer over a secure channel). Nobody had mentioned it because the product owner had never needed the interface.

What I did. Within a day I told the customer. The opening line: "I need to change something I proposed. The warehouse system gives us a nightly file, not a live feed, so the seconds-level update I described is not possible from that source. Here is what is possible, and what each option costs."

Options I brought. (An API, application programming interface, is a way for one system to send data to another on request or automatically.)

I recommended A for the first release with B as the second phase, and rewrote the acceptance criteria (the written conditions the customer uses to accept the delivered work): "data no older than 24 hours" for phase one and "within 2 minutes for priority flows" for phase two. I also logged the change, with the reason, in the shared document so nobody could say they had not been told.

Result. The customer kept the project, and the delta (the difference between what I first proposed and what we now planned) was visible in writing. In this illustration, phase one (the nightly-file release) went live on the original date, 1 June, because the file already existed; phase two (scan events for priority flows) followed three weeks later, on 22 June. Without the early correction, the real-time feed would have missed the date by an open-ended amount. These figures are illustrative: in your own story, state what actually happened, such as whether the go-live date held or moved and by how many days.

Learning. I now build an interface inventory in week one (a list of every upstream and downstream system, what it can actually expose, and who confirmed it). I also label early proposals as hypotheses with a list of assumptions, so the customer expects some to change.

What interviewers listen for

Speed of disclosure, ownership without blaming the customer, options rather than a single apology, and a concrete habit that changed.

Pitfalls

• Blaming the customer for "not telling you".
• Concealing the change inside a quietly updated document.
• A lesson that is only "communicate more".

Direct answer

A first technical discovery call (discovery is the structured conversation where you learn what the customer is trying to achieve and what constrains them, before proposing anything) is run as a guided interview, not a presentation. I spend roughly 80% of the time listening. By the end I want five things: the business objective and why it matters now, the technical landscape and hard constraints, who is involved in the decision, how the customer will measure success, and a dated next step both sides agreed to. I leave with a written discovery summary, an architecture sketch of their current state, a list of open questions with owners, and the commitments logged in the CRM (customer relationship management system, the sales team's record of each deal).

The flow, step by step

Sample questions with the reason each earns its place:

• "What prompted this project now rather than last year?" Surfaces the trigger and urgency.
• "If nothing changed for 12 months, what would that cost you?" Surfaces impact in the customer's own terms.
• "Walk me through how an order moves from entry to shipment. Which systems does it touch?" Gets the real architecture, not the slide version.
• "Which parts of this are fixed (regulation, contract, a platform standard) and which are preferences?" Separates constraints from opinions.
• "Who else needs to be comfortable before this is approved?" Starts the stakeholder map.
• "How will you know in six months this worked?" Yields success metrics I can later tie to a proof of concept (POC, a small time-boxed trial that tests whether the solution works in their environment).

Worked example: manufacturing ERP modernization

The prospect is a manufacturer replacing a 15-year-old on-premises ERP (enterprise resource planning: the system that runs orders, inventory and finance).

• Topics: plant systems feeding the ERP, reporting pain, month-end close, the integration with a warehouse system, and any plant-floor downtime windows.
• Personas: the CIO (budget and risk), the head of operations (process pain), the ERP administrator (technical truth), a finance lead (close process).
• Metrics to capture: month-end close days (for example 9 days now, target 5), order-to-ship cycle time, manual re-keying hours per week, unplanned downtime hours per quarter.
• Red flags: "we have no documentation of the integrations" (scope risk: the work will turn out larger than quoted), "the decision is the parent company's" (hidden decision-maker: someone with approval power we have not met), "we need it live by quarter end" with no named project owner (soft date: a deadline with no event or owner behind it), a plant that cannot tolerate cutover downtime (the planned outage while the old system is switched off and the new one switched on).
• Artifacts I leave with: a hand-drawn current-state diagram (ERP, warehouse system, plant systems, data feeds), a numbered list of integrations, the list of named stakeholders, and the 2-3 metrics above with their baselines.

Recording commitments

Within an hour of the call I send a recap email: what I heard, the metrics, the open questions with an owner and a date, and the agreed next step. Customers correct misunderstandings when they see them in writing, which is a cheap check on my notes. A short example:

Subject: Recap of today's call and next steps
Thanks for the time today. What I heard: the 15-year-old ERP is slowing month-end close (9 days now, target 5), and re-keying orders costs about 20 hours a week. The trigger is the vendor ending support in March. The warehouse integration is undocumented and the parent company must approve spend. Open items: (1) your IT lead sends the interface list, by Friday; (2) you confirm who at the parent company approves, by next Wednesday; (3) I send a current-state diagram for you to correct, tomorrow. Next step: a 60-minute technical session with your ERP administrator on Thursday the 14th. Please correct anything I got wrong.

The 20 hours and the dates are illustrative. In the CRM I log the stakeholders and roles, the stated pain and trigger, the metrics with baselines, the constraints, the next meeting date, and my honest read on risk. I attach the diagram. A commitment that is not in the CRM with a date and owner is not a commitment.

Trade-offs and pitfalls

• Pitching early. Demoing before you understand the problem turns discovery into a feature debate. Hold the demo until the pain is stated in the customer's words.
• Interrogating. A rapid-fire list feels like an audit. Follow the customer's answer one level deeper before moving to the next topic.
• Only talking to the technical contact. Without a business-side voice you win the technical argument and lose the budget.
• Treating the stated requirement as the need. "We need a new database" is a solution; ask what problem it fixes.
• No next step. A call that ends with "we'll be in touch" is a stalled deal.

Direct answer

When discovery shows the customer's timeline or feature expectations cannot be met (scope, meaning the list of capabilities included in the deal, or the date), I tell them early, in person, with evidence, and with alternatives ready. I tell the champion first and privately (the champion is the person inside the customer who wants our solution to win and sells it internally), then the technical and business groups in separate framings, and I protect credibility by being exact about what is a commitment and what is not. Bad news delivered promptly with options builds trust. The same news delivered late damages the relationship far more.

Before I say anything

1. Verify internally. Confirm with product and engineering that it really cannot be done, so I am not delivering a guess.
2. Prepare alternatives. I do not arrive with only a problem.
3. Align with my account executive (AE, the commercial owner of the deal), who must agree on what we can offer.

Who hears it, in what order

1. The champion, privately, so they are not surprised in a group.
2. Technical stakeholders, focused on facts and options.
3. Business stakeholders, focused on date, cost and risk.

What I say

To the champion:

"I need to share something before the wider meeting. After checking with our engineers, we cannot deliver the full scope by your March date. I would rather you hear it from me now with options than find out in the project. Here is what we can do."

To technical stakeholders:

"The requirement for real-time sync across all three systems is not supported today. We can do near real time for two of them, with a nightly reconciliation for the third. Here is how that behaves and what its limits are."

(Near real time means updates arrive within seconds to a few minutes rather than instantly. A nightly reconciliation is a scheduled overnight job that compares the two systems and corrects differences, so the third system can be up to a day behind.)

To business stakeholders:

"We can have the core process live by your date. Two of the capabilities you asked for will follow in a second phase. I want to be clear about which is which, so your plans are not built on something we cannot deliver."

Alternatives I put on the table

Applied to the March example: phase one, live by March, is the core process plus near real time sync for two of the three systems. Phase two, dated only if product confirms it in writing (say June), adds the two remaining capabilities and replaces the nightly reconciliation on the third system. The customer's plans for March rest only on phase one. If instead their central need were real-time sync across all three, no phasing covers it and that is the "not the right fit" row.

Protecting the relationship and my credibility

• Be early. Each week I wait raises the cost of the news.
• Separate fact from hope. "Supported", "possible with work" and "planned" are three different phrases and I use only the one that is true.
• Follow up in writing within a day, so the conversation is a record.
• Do not trade a lie for a deal. If a sales colleague wants me to soften it, I decline and explain that a commitment we miss costs the account later.

Judgement call

If the missing capability is the customer's central need, I recommend saying so and walking away from the deal. I would stay in the deal only where phasing or a workaround honestly covers their priority. What would change my view: a product-confirmed delivery date that is acceptable to them.

Pitfalls

• Delivering the news by email.
• Offering a roadmap promise to fill the gap without product's sign-off.

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.

Direct answer

Treat the champion's claim ("we have budget and need go-live in eight weeks") as a hypothesis, not a fact. A champion is the person inside the customer who wants your solution to win and sells it internally on your behalf. Champions are usually sincere but sit below the people who control money and calendars, chiefly the economic buyer (the person with authority to release the budget) and procurement. Go-live means the day real users start working on the system. I test the claim by asking for the mechanics behind it (who signs, which purchase process, what has to be true by week eight) as part of normal planning, then I confirm the answers with a second person. If the claim turns out to be optimistic, I say so early, reset the plan around the real dates, and keep the champion looking credible.

Testing it without an interrogation

Interrogations feel like "prove it". Planning feels like "help me help you". So I frame every question as building the plan to hit their date.

What I want evidence on (each maps to one claim):

Sample exchange:

Me: "Great, eight weeks is doable on our side if the pieces line up. To build the plan backwards, can I check a few dates with you? When would a signed order need to land for you to start on time?"
Champion: "I think procurement takes a couple of weeks."
Me: "Helpful. Have you bought through them for a vendor like us before, or is this a first? And is the budget already approved, or does someone still have to release it?"
Champion: "It's in the plan but the VP signs off at the end of the month."
Me: "Got it. Would it help if I joined a 20-minute call with the VP's office so I can answer their questions directly and we don't lose a week to back and forth?"

The last line is the key move: I ask to meet the economic buyer (the person with authority to release the budget) as a service to the champion, not as a check on them. I also write the answers into a shared mutual action plan (a dated list of steps and owners that both sides edit). Its first rows might read: (1) budget release confirmed, owner: VP's office, due the 30th; (2) security review started, owner: customer security team, due week 2; (3) order form sent to procurement, owner: me and the AE, due the day after sign-off; (4) test environment and two named engineers available, owner: champion, due week 4.

If it is optimistic

1. Quantify the gap, using their own dates and showing the sum. Suppose today is the 1st, so the VP's sign-off on the 30th is about 4 weeks away. Procurement then takes three more weeks (the champion guessed "a couple of weeks"; champions' estimates tend to run short, so I use three until procurement confirms its own figure, and even at two weeks signature lands in week 6 and go-live in week 13, still not week 8), so a signed contract lands at the end of week 7 (4 + 3). If integration and rollout need about seven weeks after signature (the customer's own estimate, which I confirm with their engineers), go-live is week 14 (7 + 7), not week 8. I say it as: "If the VP signs on the 30th and procurement takes three weeks, signature lands in week seven, so go-live is realistically week 14 or later."
2. Tell the champion first, privately, with a path forward: "Here is what I think we can do by week eight, and here is the full go-live."
3. Offer mitigations: start technical work in parallel under a short paid pilot (a small, time-limited trial the customer pays for) or a letter of intent (a non-binding written statement that they plan to buy, which some legal teams allow to authorise early work), cut an initial scope that can go live by week eight, or pre-clear security review and legal paperwork now.
4. Update my own forecast honestly. The forecast is the sales team's prediction of which deals will close and when. Tell my account executive (AE, the commercial owner of the deal) the date is at risk so the deal is not forecast on a date I no longer believe.

Trade-offs and pitfalls

• Asking "do you really have budget?" puts the champion on the defensive. Asking "who releases it and when?" gets the same answer.
• Never take one person's word on money. Two independent sources is the bar.
• Optimism is often the champion protecting their own credibility, so give them an exit that keeps it.
• What would change my call: a signed order form (the short contract document listing what is bought and at what price), or a PO number, turns the claim from hypothesis into fact and I stop probing.