Aydınlatma metni yükleniyor…
Customer interviews are among the most valuable sources of evidence in a digital product project. Yet every request heard in a meeting should not automatically become a feature. Statements such as “We need a mobile app,” “It should connect to our ERP” or “Let’s add an approval workflow” propose solutions; on their own, they do not explain which user has which problem, under what conditions it occurs or why solving it matters.
To establish a reliable product scope, interview evidence must be separated into problems, users, contexts, current processes, business rules, data, exceptions and expected outcomes. Those findings can then be converted into measurable acceptance criteria and evidence-based priorities. This gives product managers, business units, operations, IT, design, development and testing teams a shared basis for decisions.
Start with a research objective, not a feature list
The purpose of an interview is not to collect every feature the customer can imagine. It is to reduce the uncertainty surrounding important product decisions. Begin by defining the business outcome the product should support. Does the organisation need to shorten order-processing time, reduce manual data entry, track dealer requests or allow field teams to complete tasks without a reliable connection?
Set a small number of research questions for each interview round. Questions such as “How is an order created today?”, “When is manager approval required?”, “Who notices when an error occurs?” and “How does the user know the task is complete?” make the real process visible. The GOV.UK guide to using in-depth interviews likewise recommends open, neutral questions, a focus on real examples and follow-up questions that move beyond general statements.
Participant selection also shapes the resulting scope. Speaking only to executives reveals policies and targets; speaking only to end users reveals daily difficulties but may miss commercial or regulatory constraints. A B2B e-commerce platform or customer portal may involve dealers, sales representatives, operations specialists, finance teams, warehouse staff, customer service and system administrators. Compare accounts from people with different permissions and responsibilities within the same process.
Find the real need behind the requested solution
Do not dismiss a participant’s proposed solution, but investigate what sits behind it. If someone says, “We need Excel uploads,” ask how many lines they enter today, where the data originates, which errors occur and what they do when a line fails. The request can then evolve from “add Excel upload” into a user need: “A dealer operations specialist must submit a high-volume order without re-entering every line and must be able to identify and correct invalid records.”
This distinction matters because several designs could satisfy the same need: an Excel or CSV import, quick-order entry, an API or a saved order template. The related guide to planning B2B bulk ordering shows how line matching, validation, preview and ERP submission affect the wider workflow.
Ask for a specific event from the past
“What would the ideal system look like?” usually produces a hypothetical answer. Instead, ask the participant to describe the most recent order, return or approval failure step by step. Where possible, observe the screens, emails, forms and temporary spreadsheets they used. Differences between the stated process and the process actually followed often reveal critical requirements, informal workarounds and missing ownership.
Record the context, trigger and expected outcome
For every important finding, establish who initiates the action, what triggers it, which information is available, what decision must be made, whose approval is required and how success is recognised. For example, “Customers should be able to cancel an order” may actually mean that a user with a specific role can cancel only before dispatch begins, must select a reason and must send the resulting status change to the ERP.
Investigate exceptions deliberately
The happy path is usually easy to describe; the details that expand software scope are hidden in exceptions. Ask what happens when stock is insufficient, a price cannot be found, the approver is away, the ERP does not respond or the same record is submitted twice. The answers define error messages, delegation rules, retry behaviour, duplicate protection and responsibility for manual intervention.
Six steps for turning interview notes into requirements
There should be a traceable chain between raw notes and a requirement that is ready for design, development and testing. This prevents early interpretations from hardening into predetermined features and makes the evidence behind each decision visible.
1. Separate observation from interpretation
“The participant used two screens and one spreadsheet to find the price” is an observation. “The user wants a simpler dashboard” is an interpretation. Break notes into individual behaviours, statements or events, then label them with the participant’s role and an interview code. Record only the personal data genuinely needed for the research, and obtain explicit consent for recordings.
2. Group findings by problem and process theme
Cluster related notes under themes such as ordering, pricing, permissions, documents, notifications and integrations. Record how many interviews support a finding, but do not treat frequency as the only decision criterion. An uncommon security or finance exception may be more critical than a frequently reported minor usability issue. GOV.UK’s guidance on how to analyse a research session recommends separating observations collaboratively, clustering them into themes and deriving findings from evidence.
3. Write the user need without prescribing a solution
Use a structure such as: “Who needs to do what, in which context and why?” For example: “During peak ordering periods, a dealer operations specialist must transfer hundreds of product lines without typing them again, reducing entry time and product-code errors.” This definition does not mandate Excel, an API or another interface, so the team can compare design alternatives.
4. Expose business rules and data requirements
Add roles and permissions, required fields, calculations, state transitions and exceptions to the requirement. Identify each data source, owner, update frequency and destination. For ERP, CRM, payment or logistics connections, “the system will be integrated” is not sufficient. Define field mapping, unique record keys, validation, failure behaviour, retries, reconciliation and operational ownership. These concerns should be addressed as part of the project’s custom web development scope, not postponed until implementation.
5. Make acceptance criteria measurable
Acceptance criteria explain in observable terms whether a requirement has been implemented correctly. Replace “The system must be fast” with a testable statement such as: “An authorised user can see the pre-validation result for a valid 500-line file within the agreed performance target.” Cover the successful path as well as unauthorised access, missing data, duplicate submissions and integration outages.
6. Validate the requirement with users and technical teams
Read the completed requirement back to relevant participants. Is the problem accurate? Is a rule missing? Does the exception occur in practice? Does the acceptance criterion reflect the intended outcome? Then review feasibility with design, development and testing specialists. ISO/IEC/IEEE 29148 treats requirements engineering as a combination of elicitation, analysis, validation, communication, documentation and lifecycle management, as outlined on the IEEE requirements engineering standard page.
What should every requirement card contain?
A consistent requirement card connects interview evidence to product design and testing. Its depth can vary according to project risk, but the following fields create a useful shared language for web software, mobile applications, B2B e-commerce and portal projects.
Source and evidence: Interview code, observed event, support record, analytics signal or process document.
User and context: Role, authority, device, channel, operating environment and triggering condition.
Problem and objective: The current obstacle and the user or business outcome being pursued.
Business rules: Conditions, limits, calculations, approvals, delegation and state transitions.
Data and integrations: Inputs, outputs, source systems, ownership, mapping, errors and reconciliation behaviour.
Exceptions: Missing data, insufficient permissions, interrupted connections, duplicates, conflicts and rollback scenarios.
Acceptance criteria: Functional, measurable and testable conditions of success.
Priority and dependencies: Business value, risk, learning need, technical prerequisites and release decision.
Keep the card linked to its evidence, design artefacts, implementation item and test cases. That traceability allows a rule change to be followed through the product instead of remaining hidden in meeting minutes or separate spreadsheets.
| Layer | Question answered | Expected output |
|---|---|---|
| User need | Who needs to do what, and why? | Role, context and objective |
| Business rule | Which conditions and limits apply? | Permissions, limits and exceptions |
| Data and integration | Where does information come from and go? | Source, mapping and failure behaviour |
| Acceptance criterion | How can completion be demonstrated? | Measurable test scenario |
How should you prioritise product requirements?
A popular request does not automatically belong in the first release. Evaluate user impact, business objectives, risk, legal or operational necessity, data readiness and technical dependencies together. Explicitly distinguish requirements without which the process cannot operate from enhancements that make an already viable process easier.
For each requirement, record the affected user group, how often the problem occurs, the scale of its impact and the cost of the current workaround. Less visible capabilities—identity and access management, integration infrastructure, audit records or a foundational data model—may be prerequisites for customer-facing features. A mobile workflow may also require offline queues, conflict handling and synchronisation rather than just responsive screens; Kumsal Agency plans such needs within its React Native mobile application services.
Every priority decision needs an owner, date and rationale. A label such as “high” is not enough. Document why it received that priority, which dependency affects it and what new evidence could change the decision. This makes scope discussions accountable and allows later phases to be planned against visible criteria rather than stakeholder volume.
Common mistakes when eliciting requirements
Converting a request directly into a feature: Choosing a screen or technology before validating the problem can accelerate the wrong solution.
Interviewing decision-makers only: Management objectives become clear, but daily tasks, workarounds and operational exceptions remain invisible.
Asking broad questions about the future: Participants may describe ideal or socially acceptable behaviour instead of what they actually do.
Combining notes without preserving evidence: Conflicting needs from different roles can appear to be one misleading request.
Defining an integration in a single line: Data ownership, mapping, security, failure recovery and operating responsibilities remain unresolved during development.
Leaving acceptance criteria until the end: Design, development, testing and business teams form different definitions of “done.”
Prioritising by frequency alone: Rare but severe financial, security or compliance scenarios may be overlooked.
From interview evidence to a shared product scope
Good requirements work reduces uncertainty rather than producing the longest possible feature list. Every requirement is tied to a user, a problem and evidence; business rules, data flows, integrations, exceptions and acceptance criteria become explicit. As a result, commercial, design, development, testing and operations teams are less likely to proceed with incompatible assumptions.
Kumsal Agency approaches user experience and digital product planning together with business processes, user roles, data flows and integration requirements. It creates verifiable scope for bespoke web software, React Native hybrid mobile applications, B2B e-commerce platforms and customer or dealer portals.
To turn customer interviews into verifiable product requirements and plan the scope of your project with an experienced digital product team, contact Kumsal Agency.