Requirements discovery turns a vague request into a decision the buyer can defend. Start with the current situation and its consequences, define the desired state, and then set the conditions a solution must meet. Set those conditions before the buyer settles into a vendor comparison. Strong sellers help buyers define what a good decision needs to accomplish before comparison narrows.1 The sequence gives later questions a job: test fit, shape a proposal, and stop selling when the stated requirements cannot be met.
Run the discovery in this order
Use the sequence to move the conversation from context to a usable buying standard. Move on when the prospect has answered the question in the middle column with enough detail to guide the next stage.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Current situation | How the work happens today and where help is needed | Walk me through how you handle this today. |
| Consequences | What the current situation changes for the team or business | What happens when this stays as it is? |
| Ideal state | What better looks like to the prospect | "Where do you want to be? What does ideal look like for you?"2 |
| Requirements | What the solution must help them do | "What do you need in order to reduce the amount of time required to complete an RFP?"3 |
| Decision criteria | How the prospect will judge the options | What would make a solution worth choosing? |
| Alternatives | What else they have considered and whether a simpler path exists | "What else have you considered? Is there an easier solution than what we're picturing?"4 |
| Proof | What they need to see or test before deciding | What would you need to see working? |
| Fit and next step | Whether the requirements can be met and what information remains | Which requirement still needs an answer? |
Map current work
Stay with the prospect's work before asking for a feature list. A requirement is easier to judge when you can see the task, its difficulty, and where help is needed.
Ask where they need help and what challenges they face so the recommendation fits the situation.5 Trace the work across the whole customer journey because discovery should encompass that journey.6 Ask the prospect to describe what happens before the problem appears, what they do when it appears, and what follows afterward.
Listen for a concrete description of the current setup. If the answer stays at the level of a general complaint, ask for the last time the issue occurred and what the team did next. Focus on the work the solution must change. A catalogue of features the prospect has heard about will not give you that detail.
Define the ideal state
With the current work clear, ask the prospect to describe the result they want. Keep this part in their language because it will guide the rest of the conversation.
The prospect's desired outcome should determine the direction of discovery.7 Ask what would be different if the problem were handled well, who would notice the change, and what result would make the effort worthwhile. Stay with the outcome until the prospect can describe it clearly enough to recognise later.
Separate a preferred experience from a requirement. A preferred experience may sound appealing. A requirement changes the result the prospect is trying to achieve or the way the work has to be done.
Turn outcomes into requirements
Convert the desired state into conditions you can check. Each condition should connect to work the prospect described, an outcome they want, or a constraint they must respect.
Ask what the prospect needs the solution to do in the context of that work. If an RFP takes too much time, ask what would reduce the time required to complete it.3 For each requested capability, ask how the current setup handles it and where it falls short. Asking more about the current setup can reveal whether features in the solution fit the prospect's requirements.8
Ask why each requested feature or benefit matters: "Why do you need these specific features/benefits?"9 The answer shows whether the request is tied to an outcome, a process condition, or a preference. Record the requirement in the prospect's words, then add why it matters so you can test it later.
Set decision criteria
Requirements become useful when the prospect can use them to judge options. Establish that standard before the conversation turns into a product comparison.
Work with the prospect to establish the criteria they prefer. This creates the basis for competitive differentiation.10 Ask which conditions are mandatory, which improve the result, and which would make an option easier to adopt. Keep the criteria visible as the conversation moves forward.
Ask whether the solution is missing anything proposed by competitors.11 This exposes gaps while there is still time to investigate them. If the prospect raises pricing or implementation, treat the request as a signal about how to structure the next part of the conversation.12 Ask what sits behind it and whether it is a condition for approval, adoption, or continued evaluation.
Prove the requirement
A requirement remains unconfirmed until the prospect agrees on how it will be demonstrated. Turn the criteria into a small test the prospect can recognise as relevant.
Guide the prospect's success criteria toward outcomes the seller can demonstrate.13 Ask what result they expect, what evidence would count, and who needs to accept it. If a proof of concept is part of the evaluation, map the exact things the prospect wants to test before it starts.14
Use the test to expose missing requirements. If the prospect cannot say what should be tested or what result would count, return to the ideal state and ask what decision the test needs to support. Move on when the prospect can connect the test to a stated requirement and a decision.
Check fit and agree the next step
Finish by checking whether the requirements describe a reachable fit. This keeps the conversation from drifting into a proposal built on assumptions.
If the stated requirements suggest a mismatch, say that you are unsure whether the solution is a fit and requalify the opportunity.15 Keep asking until you have a clear picture of what matters to the prospect.16 The answers may change the requirements, the audience involved, or the decision itself.
When the prospect needs information from someone else, ask what they need to figure out and agree on a date to reconnect once they have it.17 Leave the call with the open requirement named, the person responsible for resolving it, and the point at which you will review the answer.
What not to do
These mistakes leave requirements too vague to guide a decision. Use the bullets as a final check before moving into a demo or proposal.
- Do not demonstrate the product before you know more about the buyer.18
- Do not accept a feature request without asking why it matters: "Why do you need these specific features/benefits?"9
- Do not treat a competitor's capability as proof that it belongs in the requirement set. Ask what the prospect is trying to accomplish and how the capability would change the result.
- Do not leave an objection at the surface. Ask about the current setup so you can find out whether the solution fits the stated requirements.8
On the next discovery call, write each requirement beside the outcome it supports. Keep the list open for revision because customer discovery is an initial and iterative process for understanding situations, needs, and pain points.19