Customer Needs and Problem Analysis Questions

Focuses on a structured process for uncovering and diagnosing a customer's needs, goals, and problems before acting on them. Core elements include identifying the customer's business objectives and success metrics, mapping stakeholders and their roles, priorities, and decision criteria, understanding the customer's current environment, workflow, and constraints, uncovering pain points and inefficiencies through targeted questioning and observation, scoping requirements including relevant constraints such as performance, security, or compliance where applicable, verifying assumptions about timeline, resources, and available budget or capacity, performing root cause analysis to separate symptoms from underlying issues, and producing a prioritized set of customer needs with recommended next steps.

MediumTechnical

64 practiced

Provide a checklist of questions and artifacts you would request from a customer's procurement and legal teams to confirm contractual constraints (procurement cycles, vendor-of-record, data residency clauses) that will affect architecture choices.

Sample Answer

Situation: As a Solutions Architect engaging a new customer, I need a checklist for procurement and legal to surface contractual constraints (procurement cycles, vendor-of-record, data residency, etc.) that materially affect architecture choices.

Checklist — Questions to Ask- Contract scope & term - What is the expected contract start/end date and renewal cadence? - Are there fixed delivery/milestone deadlines tied to payments or penalties?- Procurement process & timelines - What are the procurement approval gates and estimated lead times (PO, SOW signoff)? - Are any vendor onboarding steps (security questionnaires, audits) required?- Vendor status & restrictions - Is there an approved vendor-of-record (VOR) list? Any disallowed vendors or partner-preferred suppliers? - Are subcontracting/third-party dependencies restricted or require pre-approval?- Data residency & sovereignty - Are there rules about where data must be stored, processed, or backed up (country/region)? - Any encryption/keys ownership requirements or restrictions on cross-border transfers?- Compliance, certifications & audits - Required certifications (ISO 27001, SOC2, PCI, HIPAA) and evidence required during procurement? - Audit rights, frequency, and acceptable remediation timelines?- Liability, indemnity & insurance - Limits of liability, indemnity clauses, and cyber/tech insurance minimums? - Are there service-level financial penalties that impact design choices (RTO/RPO)?- Intellectual property & deliverable ownership - Who owns IP for custom code, integrations, or models? Licensing restrictions?- Security & access control - Requirements for network access, VPNs, network segmentation, or on-prem connectivity? - Background checks or personnel vetting requirements for staff onsite or with access?- Exit & data return/destruction - End-of-contract data retrieval windows, format, and certified deletion requirements? - Portability constraints affecting architecture for export/import?- Change control & scope amendments - Process for change requests, pricing adjustments, and approval SLAs?

Artifacts to Request- Master Service Agreement (MSA), Sample SOW, and any existing contracts or templates- Approved vendor lists / vendor onboarding checklist- Standard security questionnaires (SIG, CAIQ) and completed versions, if available- Data processing agreement (DPA) and data flow diagrams showing regulated data paths- Required compliance reports/certificates (SOC2, ISO certs, PCI attestation)- Procurement timeline/milestone calendar and procurement contact list- Insurance certificate requirements and liability clauses excerpt- Sample change order and termination/exit clauses- Any internal architecture, network, or data classification policies

Why this matters (brief)- These questions/artifacts reveal hard constraints (where data must live, who can be used, timelines and penalties) and hidden blockers (pre-approval steps, audit windows) that directly drive choices: cloud region selection, hybrid vs. cloud-native, cross-border designs, encryption key management, and contingency budgets/timelines. Requesting them early avoids costly redesigns and speeds procurement alignment.

MediumTechnical

66 practiced

Describe how you would assess and document operational readiness and runbook completeness during discovery, and list three specific runbook checks that expose gaps that could cause outages.

Sample Answer

Assessment & documentation approach (during discovery)- Clarify scope and objectives: ask which services, SLAs/SLOs, on-call rotations, dependency map, and recent incidents.- Inventory existing runbooks, dashboards, alert rules, and access controls. Capture format, owner, last-updated, and test history.- Perform lightweight verification: walk through 2–3 critical incident scenarios with an on-call or engineer to observe how runbooks are used in practice.- Produce a readiness matrix documenting: coverage (service→runbook), actionability (steps vs. theory), access (credentials, playbook permissions), telemetry (alerts→dashboards→logs), and test status (never/tested/failed).- Deliverables: runbook catalogue, readiness score per service, prioritized remediation backlog, and template improvements (clear title, severity, pre-reqs, step-by-step remediation, verification, rollback, escalation contacts).

Three specific runbook checks that reveal outage-risk gaps1) Alert-to-Runbook Mapping Check- Verify every production alert has a single, referenced runbook and vice versa. Gaps found: alerts with no runbook, or runbooks that don't reference the exact alert name/ID — leads to slow diagnosis or duplicate effort.

2) Reproducibility & Run-Through Check- Time-boxed tabletop or live simulation where an engineer follows the runbook from alert to resolution (including credentials, CLI/API commands). Gaps: missing commands, environment assumptions, or steps requiring unavailable credentials — these cause failed mitigations during real incidents.

3) Verification & Rollback Steps Check- Ensure each remediation step includes a clear verification (what to check, expected metric/log) and an explicit rollback if the step fails. Gaps: no verification or no rollback plan — increases risk of partial fixes or cascading failures.

Why this matters (architect perspective)- These checks surface operational, security, and knowledge gaps early so designs include automation, observability, least-privilege access patterns, and runbook testing plans—reducing customer risk and improving the solution’s operability.

HardTechnical

72 practiced

Hard: After discovery you must provide both a short 'sales-friendly' recommended approach and a detailed technical appendix for engineering. Describe the structure and content differences between the two deliverables and provide three examples of content that appear only in the technical appendix.

Sample Answer

Short, sales‑friendly recommended approach (audience: decision‑makers / commercial stakeholders)- Purpose: convey value, recommended option, risks, timeline, and high‑level costs to secure buy‑in.- Tone & length: concise, persuasive, 1–2 pages or a slide, business language, minimal technical jargon.- Structure: - Executive summary: one sentence recommendation and expected business outcome - Key benefits: ROI, TCO summary, time‑to‑value - High‑level solution summary: components and how they solve the customer problem - Deployment timeline & milestones (summary) - Commercial considerations & next steps (contracts, POC, approvals)- Visuals: simple architecture diagram, ROI chart, topline timeline

Detailed technical appendix for engineering (audience: architects, engineers, implementation teams)- Purpose: provide actionable technical detail needed to estimate, build, and operate the solution.- Tone & length: technical, exhaustive, 10+ pages or a repository of artifacts.- Structure: - Detailed architecture diagrams (component, network, data flow, sequence) - System integration specs: APIs, protocols, message schemas - Non‑functional requirements mapping: SLOs, capacity, latency, availability targets - Deployment & CI/CD plan, environment separation, IaC references - Security controls: authentication flows, key management, network ACLs - Data model, transformation rules, and migration plan - Operational runbooks, monitoring, alerting thresholds - Bill of materials, sizing calculations, and third‑party dependencies- Visuals: detailed UML/sequence, network topology, capacity charts

Three examples of content that appear only in the technical appendix1. Exact API contracts and sample payloads (JSON schema, error codes, authentication headers).2. Capacity and sizing calculations with formulas and assumed growth rates (CPU/RAM/IOPS, storage sizing).3. Terraform/ARM/CloudFormation snippet examples, environment variable maps, and deployment pipeline steps.

Why this separation matters- Sales doc accelerates decisions by focusing on value; appendix de-risks delivery by giving engineers what they need to estimate and build. Provide both together and reference the appendix from the sales doc so stakeholders can dive deeper without cluttering the commercial message.

MediumTechnical

70 practiced

Medium: During discovery you find that the customer's SLAs are ambiguous. Provide three concrete SLA templates (availability, RTO/RPO, support response) with measurable thresholds tailored for a B2B platform used by enterprise customers.

Sample Answer

Context & assumptions: enterprise B2B platform delivered SaaS; multi-tenant with business-hours and 24x7 customers; SLAs exclude scheduled maintenance (≥72h notice) and force majeure. Below are three concrete, copy-ready templates.

1) Availability SLA (Production)- Objective: Service Availability measured at API and UI endpoints.- Threshold: 99.95% monthly uptime (≤22 minutes downtime/month).- Measurement: Synthetic probes every 60s from 3 global regions; availability = (Total minutes - Downtime minutes) / Total minutes.- Credits: ≥99.0% and <99.95% → 10% monthly credit; <99.0% → 25% credit.- Exclusions: Scheduled maintenance, customer network issues, agreed emergency patches.- Reporting: Monthly uptime report with incident details within 5 business days.

2) RTO / RPO (Disaster Recovery)- Objective: Maximum recovery time and data loss tolerance for production tenant.- RTO: 2 hours for critical services (auth, payment, core APIs); 8 hours for non-critical background processing.- RPO: 15 minutes for critical data stores; 4 hours for analytics/batch stores.- Verification: Quarterly failover test with customer (tabletop or live) and post-test report within 7 days.- Failure credits: Missed RTO/RPO for critical services → 20% credit for that month.

3) Support Response & Resolution- Objective: Guarantee response and resolution targets by severity.- Severity definitions: - Sev 1 (Business-Down): Complete outage impacting all users. - Sev 2 (Degraded): Major feature degraded for many users. - Sev 3 (Partial): Single-tenant feature impacted, workaround exists. - Sev 4 (Minor): Minor bug, feature request.- Targets: - Sev 1: Initial response ≤ 15 minutes (24x7), fix or workaround ≤ 4 hours. - Sev 2: Initial response ≤ 1 hour (24x7), workaround ≤ 8 hours, resolution ≤ 48 hours. - Sev 3: Initial response ≤ 4 business hours, resolution ≤ 5 business days. - Sev 4: Initial response ≤ 2 business days, resolution per roadmap.- Escalation: Automated paging for Sev1→ Engineering on-call within 15 minutes; weekly status updates until resolved.- SLAs breach credit: Failure to meet initial response for Sev1 or Sev2 → 5% credit per breach, capped at 20% monthly.

Operational controls common to all:- Monitoring: 24x7 NOC, synthetic + real-user monitoring, logs retained 90 days.- Change management: Maintenance windows with ≥72 hours notice; emergency change process documented.- Reviews: Monthly incident summaries and quarterly SLA review with customer.

These templates can be tuned (percentages, windows, credits) to match contract risk and customer requirements.

MediumTechnical

72 practiced

Create a lightweight prioritization framework you would use to rank customer requirements (example factors: business impact, implementation effort, risk, dependencies). Explain how you score and present results to stakeholders who disagree.

Unlock Full Question Bank

Get access to hundreds of Customer Needs and Problem Analysis interview questions and detailed answers.

Join thousands of developers preparing for their dream job.