Technical Discovery & Needs Qualification Questions

Direct answer

The playbook is a short, structured question set plus a decision map that turns the customer's answers into three outputs: which regulations and customer policies apply, which of our controls and certifications already cover them, and which gaps could block the deal. I would build it in layers (a universal core, then an industry overlay for finance, healthcare and government), run it in the first or second discovery call, and attach a pre-approved evidence pack so the customer's security team is reviewing documents in week one rather than week six.

(Where to start: the universal core questions below are the part to learn first, since they apply to every regulated deal. The industry overlays are only used when the customer is in that industry. SOC 2 and a DPA come up in almost every deal; PCI DSS and HIPAA/BAA only when card data or health data is involved; DORA and FedRAMP are region- and sector-specific, so I check them only when the customer's location or sector calls for them.)

(Terms used here. SA means solutions architect, the presales engineer in the dialogue below. NDA (non-disclosure agreement) is a confidentiality contract. SSO is single sign-on. The account team is the salesperson and the people supporting the deal. Presales is the pre-contract technical function that supports a sale. Discovery is the early fact-finding conversation with the customer. A blocker is any requirement that, unmet, stops the deal or delays it past the customer's deadline.)

What the playbook contains

Industry overlays (each is 8 to 12 questions, not a lecture):

• Finance. Ask whether the system is in scope for payment card rules (PCI DSS, the Payment Card Industry Data Security Standard), whether the customer is a regulated bank or insurer with its own outsourcing and third-party risk rules, whether they require audit rights over us (the customer's right to inspect our systems or have them inspected), exit and portability plans, and concentration-risk questions (the risk of depending too heavily on one provider, such as a single cloud vendor). For EU financial entities, ask whether DORA (the EU Digital Operational Resilience Act) contract terms are expected.
• Healthcare. Ask whether the data includes protected health information, whether the customer is a US HIPAA (Health Insurance Portability and Accountability Act) covered entity that will require a BAA (business associate agreement, a contract in which we, as a business associate handling their protected health information, accept HIPAA safeguarding duties), which of the services we would use are covered by that agreement, and how patient data is de-identified for non-production use.
• Government. Ask which classification level applies, whether a government authorization is mandatory for any cloud service (in the US, FedRAMP, the Federal Risk and Authorization Management Program, at Low, Moderate or High impact), whether staff must be nationals or screened, whether data and support personnel must stay in-country, and what the contracting vehicle is (the pre-approved government contract or purchasing route through which the purchase must be made).

Regulations change, so the playbook records "last verified" and an owner for every row, and I confirm the exact current obligation with our compliance team before I state it to a customer.

How it spots blockers early

Blockers cluster into a handful of shapes. The playbook asks the question that exposes each one:

1. Missing certification or authorization. Question: "Is any named certification a hard requirement for go-live, and by what date?" A FedRAMP-Moderate requirement we do not hold, with a go-live in 90 days, is a red.
2. Residency or sovereignty (legal control of data by the country where it sits). "Must data, backups, logs and support access all stay in-country?" Support access and backups are the parts people forget.
3. Key and access control. "Must the customer hold the encryption keys?" That changes the architecture, not just a checkbox.
4. Contract terms we cannot sign. Uncapped liability (no limit on the damages we would owe), audit rights over our shared infrastructure, a right to inspect our data centres. Flag these to legal in week one.
5. The approval process itself. "Who must approve us, in what order, and how long did the last vendor take?" A 16-week vendor risk review against a 12-week project plan is a blocker even if every technical answer is green.

Scoring is simple: red means we cannot meet it as stated and need a workaround or an exec decision; amber means we can meet it with a named action and owner; green means covered by existing evidence. A sample control-to-evidence row looks like this: Requirement: "Customer data encrypted at rest and in transit" | Our answer: "Yes, with provider-managed keys; customer-held keys are on request" | Evidence: SOC 2 report, section on encryption; architecture diagram v4 | Owner: security lead | Last reviewed: 2026-08-15.

Any red goes to the account team the same day, because a red found in week 8 costs a quarter.

Worked example: a regional bank, 3 questions in

Discovery call with the bank's risk lead. Our questions and her answers:

SA: "Which data would the service process, and is any of it customer account data?" Risk lead: "Yes, transaction histories."
SA: "Does your outsourcing policy require audit rights and a tested exit plan for a critical vendor?" Risk lead: "Both, and we need that in the contract."
SA: "What was the longest vendor approval you ran in the last year?" Risk lead: "About five months, because the questionnaire went back and forth."

Playbook output: data classification high (amber: transaction histories are customer account data, so the sensitivity is high; we can meet it, but only once we have confirmed encryption and residency answers and can point to the evidence, so it needs a named action rather than being green), audit rights (red until legal reviews, because we do not grant on-site audit of shared infrastructure; the standard workaround is a third-party audit report plus a remote audit procedure, to be agreed with legal), approval time (red: the longest recent approval was about five months, and for this example I assume the bank's go-live target is four months out, so the review alone would overrun it). The action list the same day: send the evidence pack, request the bank's questionnaire in advance, book a joint review with their risk team and our security lead, and ask legal to pre-clear the audit-rights language.

How I speed up approvals

• Front-load evidence. Send the evidence pack after the first call, under NDA, before they ask. The five-month loop in the example was caused by questionnaire back-and-forth, so the pack answers the common questions up front.
• Pre-fill their questionnaire. Keep a maintained answer library (approved text) so a 200-row questionnaire is mostly pasted and reviewed, not written. Security and legal own the library; a presales engineer cannot freelance an answer.
• Run the approval in parallel, not serially. Map their approval chain in the first meeting and start the long poles (the slowest steps, which set the finish date: legal, privacy, security review) at the same time as the technical evaluation.
• Name a customer-side owner and a date for each step, and keep the plan in a shared document both sides can see.
• Have a standing escalation path to our own security and legal leads with a same-week response commitment.

Trade-offs and pitfalls

• A playbook that tries to be a full compliance audit becomes a 300-question form nobody finishes. Keep the discovery layer to roughly the first 20 questions and push detail into the evidence pack.
• Never answer a compliance question from memory in a live call. "I will confirm that in writing today" is the right answer to anything not in the approved library.
• Over-promising a certification that is "in progress" is the costliest error; state its status and expected date exactly as the compliance owner gives it.
• A stale playbook is worse than none. Give every row an owner and a review date, and retire rows when regulations change.

Direct answer

I would treat "too complex" as a hypothesis to test, not a fact. I would run focused discovery on the ERP (enterprise resource planning system, the core system that runs finance, orders and inventory), find out exactly which data and transactions we need to touch, what interfaces the system actually exposes, and who has done integration before. Then I would call it a real blocker only if one of three things is true: no supported interface exists for the required data, the change cost exceeds the business value, or the customer cannot staff or approve the work. The deliverable is a go / no-go / conditional-go call (proceed, stop, or proceed if stated conditions hold) with the evidence behind it.

Questions I ask

1. Scope first: Which exact flows do we need: read-only master data (the slow-changing reference records, such as products and customers), or writing back orders and invoices? Reading a nightly extract and posting transactions are very different problems.
2. Interfaces that exist: Does the ERP expose an API, web service, message queue, database views (saved read-only queries the database exposes like virtual tables), file exchange (SFTP, which is secure file transfer, or flat files such as CSV exports), or only screens? What version and which vendor modules?
3. Prior integrations: What else already connects to it, who built that, and what broke? An existing interface may be reusable.
4. Where the complexity comes from: Custom code or heavy customisation? Undocumented business rules? Batch windows? Which part specifically is "too complex": data model, authentication, performance, vendor licensing, or lack of people?
5. Change control: Who must approve changes, how long does a change request take, and are there freeze periods?
6. Expertise: Who knows the system? If one person retires, can anyone else?
7. Data quality and volume: Duplicates, missing keys, how many records, peak transactions.
8. Alternatives they have considered: Middleware (software that sits between two systems and translates between them), an integration platform (a product that manages many such connections), file-based exchange, reading from a replica (a read-only copy of the database, so the live system is not touched).

Artifacts I request

• Interface or API documentation for the ERP modules in scope, and the vendor and version.
• Data model or sample extracts (redacted) of the entities we need.
• A list of existing integrations with their method and owner.
• Authentication method and any service-account policy (the rules for the non-human logins that integrations use).
• Previous integration project notes or incident reports.
• Batch schedule and maintenance windows.

How I decide if it is a real blocker

Worked example

Customer: "The ERP is 15 years old, we cannot integrate." I ask what exactly we need and learn: product and price data read once a night, and order status read back. The ERP exposes nightly CSV exports and an order-status database view. Verdict: conditional go. I write: "Read-only integration via nightly file plus status view is feasible; freshness limit 24 hours for product data; real-time pricing would not be supported." That last limit follows from the file itself: a file produced once a night is up to 24 hours old, so a price changed at 10:00 would not reach us until the next day. The "showstopper" shrinks to a stated limitation, and I take it to the customer for confirmation.

Trade-offs and pitfalls

• Declaring it fine to please sales before checking the interface.
• Believing "too complex" without asking who said it and from what experience.
• Leaving the verdict implicit: write the go / conditional / no-go reasoning down and send it.
• What would flip my call: a vendor statement that forbids the integration method, or proof the customer cannot allocate an owner for the ERP side.

Direct answer

My rapid feasibility check is a five-criterion scorecard (technical fit, effort, commercial risk, uncertainty, dependencies) that I can run in my head on the call and fill in properly within a day, followed by a proof-of-concept decision rule. Together they answer: is it technically doable, what will it cost to build and support, what commercial risk does it create, how uncertain am I, and does it need a proof of concept (POC, a time-boxed trial that proves the capability works). On the call I never say yes or no. I say "let me confirm with our engineering team and come back by Thursday", then score it.

The scorecard

Each criterion is scored from 1 (bad for us) to 5 (good for us), so a high number is always good: effort 3 means a moderate build, commercial risk 2 means fairly risky, uncertainty 2 means we know little. Weights add to 100%. The weights and thresholds are my own illustrative defaults, to be calibrated (adjusted until scores match what past requests actually cost and risked) against your team's history.

Worked example. A prospect asks us to export audit logs into their security information and event management (SIEM) system in near real time. Scores: technical fit 4, effort 3, commercial risk 2 (they want it contractually guaranteed), uncertainty 2 (we have never streamed that volume), dependencies 4.

$$\text{Score} = 0.30(4) + 0.25(3) + 0.20(2) + 0.15(2) + 0.10(4) = 1.20 + 0.75 + 0.40 + 0.30 + 0.40 = 3.05$$

Bands: 4.0 and above: say "yes, with confirmation". From 3.0 up to but not including 4.0: "probably", and confirm with engineering and consider a POC. Below 3.0: do not commit, offer an alternative. This scores 3.05, so "probably, confirm and scope a small POC". Notice it sits just above the line, so a small change in technical fit or effort moves it: if the volume test fails, it drops below 3.0 and I would not commit (worked below).

When a POC is needed

• Any criterion I scored 2 or lower on uncertainty (here, volume),
• The capability is a gating item for the customer's decision,
• A POC is cheaper than the cost of being wrong.

The sensitivity check: the score is only as good as its least certain input. Which way does a failed volume test move the score? On this scale a high number is good, so a test that settles the question REMOVES uncertainty and the uncertainty score rises, from 2 to 4 (we now know the answer, even though the answer is bad). The damage lands elsewhere: technical fit falls from 4 to 2 (it cannot take that volume as built) and effort from 3 to 2 (a rebuild is needed). The weighted score becomes 0.30(2) + 0.25(2) + 0.20(2) + 0.15(4) + 0.10(4) = 0.60 + 0.50 + 0.40 + 0.60 + 0.40 = 2.50, which is below 3.0, so I would not commit. Holding the other scores at their original values and changing only uncertainty to 4 would give 3.35, which shows why the uncertainty score alone must never be read as 'good news': a resolved unknown is only good if the answer is also good.

A POC for this would test the stream at their volume, with a written success criterion such as "events appear in their system within a set delay for a full day of traffic".

Who I consult

What I say on the call

"That is a reasonable ask and I want to give you a straight answer rather than a quick one. Let me check with engineering on volume and effort and I will come back to you Thursday with what we can do and what we would need to try first."

Pitfalls

• A yes on the call because the deal feels at stake. A false yes costs more than a delayed one.
• Treating a custom request as only technical. The commercial promise is usually the larger risk.

Direct answer

I would hand over a short discovery summary (about six to ten pages) that proves we listened, records the facts we will build on, ranks what matters, and names what is still unknown. It is not a solution design or a price. It ends with decisions the customer needs to make and a sign-off line, so the work cannot quietly drift.

The outline I would use

Excerpt of section 4 (illustrative)

"Must / Should / Could" is MoSCoW prioritisation (Must have, Should have, Could have, Will not have this time). Priority: Must means the project fails without it. "Must (gate)" is a Must that is also a pass or fail condition: a design that cannot satisfy it is rejected outright, whatever else it offers. Confidence is High when we have verified the requirement and the numbers behind it, Medium when the source is credible but unmeasured, and Low when it rests on one person's opinion or missing data. Every requirement carries a source, so any disagreement can be traced to a person.

Excerpt of sections 5 and 6 (illustrative)

What I would deliberately leave out

• Pricing and commercial terms (they belong in a proposal and change the tone of a fact-finding document).
• A detailed architecture or a product feature list (the document would turn into a premature design and anchor the customer (fix their expectations) on a solution before priorities are agreed).
• Raw interview notes with names attached, and any comment on internal politics or individuals.
• Unverified claims. Anything we did not confirm goes in open questions, not in current state.
• Commitments on dates or outcomes. We list risks, not promises.
• Marketing claims about our product.

Making discovery capture consistent

• Process: prepare from public and provided material, run interviews with a standard question set, write notes within 24 hours, hold a weekly read-back with the customer lead, then draft the document.
• Template: the table above, reused for every account so findings can be compared.
• Cadence: weekly 30-minute playback, so the customer corrects errors while they are cheap.
• Sign-off criteria: done means every requirement has a source, priority and acceptance criterion; every open question has an owner and a date; and a named customer owner confirms in writing "this reflects what we heard" within, say, five business days. Silence is not sign-off.

Pitfall

A summary so long nobody reads it, or one that is a disguised sales pitch. If a section does not change a decision, cut it.

Direct answer

For a hospital moving patients between facilities, I would probe the non-functional requirements (NFRs, the qualities a system must have beyond its features: speed, uptime, security, compliance) in six groups: availability, latency and dispatch timing, privacy and compliance, auditability, integration with hospital systems, and safety and accessibility rules. The ones that would most change the architecture are privacy and compliance (it forces how data is stored, isolated and logged) and availability (it forces redundancy and failover), followed by integration with clinical systems. A seventh point sits outside the six probing groups because it comes from the product's own behaviour rather than from a hospital requirement: pricing and fairness rules (below).

What I probe, and why each matters

That is six rows because the question deserves breadth; in a real call I would prioritise by asking which two the hospital would fire a vendor over.

Which ones change the architecture most

1. Privacy and compliance. A consumer ride-booking app (riders request a vehicle, dispatch assigns one, and an ETA, the estimated time of arrival, is shown) mixes data from many riders. A hospital deployment may need PHI kept apart from general data, encrypted with customer-controlled keys (encryption keys the hospital holds, so we cannot read the data without them), restricted by region, and logged on every access. That can mean a separate tenant or deployment, not a configuration flag. Concretely: the consumer app keeps all riders in one shared database, whereas the hospital would get its own database and encryption key in an approved region, so its patient records never sit beside other customers' data.
2. Availability. A missed patient transfer has clinical consequences, so single-region, best-effort uptime is not enough. That pushes toward multi-zone deployment (running copies in several separate data centres in one region so losing one does not stop service), failover (automatic switch to a standby copy), a tested fallback process and a stricter service-level agreement (SLA, the contractual uptime and response promise).
3. Pricing and fairness rules (not one of the six groups; I raise it because our own product behaves differently from what the hospital needs). Surge pricing (raising fares when demand is high) is acceptable for consumer rides and plainly unacceptable for patient transport, so the pricing service must be switchable per customer.

Linking each business objective to one technical metric

The hospital's goals are business sentences. I convert each into one number I can test, using the surge-pricing example for contrast:

The figures above are illustrative: I ask the customer for their real thresholds.

Pitfalls

• Accepting "high availability" as a requirement. It is a wish until it has a number and a consequence.
• Treating compliance as paperwork at the end. It decides the architecture at the start.