Needs and requirements discovery

Requirements discovery should end with a buyer-specific test for whether a solution earns the purchase. Start with the future the prospect wants, work backward through the current process and requested capabilities, then agree on what must be true for a decision. A requirement earns attention when the buyer can connect it to an outcome and an evaluation decision. A feature that cannot survive that conversation needs investigation before it shapes the demo.¹

Run discovery in this order

Work from the prospect's desired result to the conditions for a purchase. Advance when the current stage gives you enough detail to test the next one.

Stage	What you are trying to learn	Example question
Desired state	What the prospect wants the future to look like	"Where do you want to be?"
Current process	How the work happens today and what surrounds it	"How does this work today?"
Requirement source	Why each requirement exists and who needs it	"Where did this requirement come from?"
Underlying outcome	What the prospect hopes a requested capability will accomplish	"What were you hoping to do with that?"
Evaluation	Which capabilities and criteria will determine fit	"What must this do for you to choose it?"
Purchase path	What the prospect needs to make a decision	"What do you need to make a purchasing decision?"

Set the desired state

Ask, "Where do you want to be? What does ideal look like for you?".² Require a business objective alongside the requirement so the conversation stays connected to what the prospect is trying to achieve.³ Use the answer as your reference point when the prospect introduces features, constraints, or competing preferences. Advance when the prospect can describe the desired result in terms they would use to judge progress.

Map the current process

Understand the current process before deciding whether software should be shown or what should be shown.⁴ The process shows where a requirement fits and what a useful demonstration needs to show. Map the prospect's technology architecture because it affects what you sell, how you sell it, and whether you can sell it.⁵ This path can reveal which applications and features the buyer would build and how those choices affect customers.⁶

Ask the prospect to take you through the work as it happens today. Listen for the point where the desired state would change the process, then record that connection in the requirement. Continue when you can explain the current process and the desired change without relying on feature language.

Trace each requirement to its source

A requirements list needs context before it can guide an evaluation. Find where the requirements list came from.⁷ Use that understanding to determine the best path forward.⁸ Ask who requested each item, what prompted it, and what would happen if it were absent. When the prospect wants a broad group involved early, run more discovery and start with the desired end state.⁹

Capture the prospect's requirements notes and use them in the next step.¹⁰ A requirements template can help the prospect make a better decision¹¹ and begin to form a vision of the desired solution.¹² Continue when every item has a reason that connects to the desired state.

Turn requests into outcomes

Prospects often describe what they want in feature language. After you understand the prospect's narrative and problems, ask why they want the requested feature.¹³ When an unexpected request appears, ask, "I'm curious, what were you hoping to do with that?".¹⁴ Translate the answer into an outcome you can check during evaluation.

If the goal is to reduce the time required to complete an RFP, ask what needs to change for that result to occur.¹⁵ Keep the outcome attached to the requirement as the conversation moves into a demonstration or technical review. Continue when the prospect can explain what the request is meant to accomplish and why that result matters.

Define evaluation requirements

Once the outcome is clear, turn it into criteria the prospect can use to judge options. Find what matters most before sorting the list.¹⁶ Ask, "What are the required capabilities that they've told you that they must have in order to make a decision?".¹ Use requirements and non-negotiables to judge whether the opportunity merits more work.¹⁷

Establishing the prospect's preferred criteria gives you a basis for competitive differentiation.¹⁸ Ask what the prospect needs to see for the solution to feel like a good fit.¹⁹ Record the criteria in the prospect's language, then separate conditions that determine the decision from preferences that shape the shortlist. Continue when the prospect can explain how each criterion will affect the choice.

Test the solution against the work

Use the criteria to make the prospect evaluate fit against the process you mapped. The call should answer their questions and help them work out how the solution could solve the problem.²⁰

Ask how the solution compares with the current approach or fits the prospect's workflow.²¹ Buyers evaluate whether the solution will do what they are purchasing it to do and whether the effort is worth it.²² After discussing the problem and current situation, ask whether you have satisfied what they need.²³

Verify the solution the prospect agreed to during solution exploration or the demonstration.²⁴ Continue when the prospect can state what fits, what still needs proof, and what would prevent a decision.

Confirm purchase conditions

Requirements discovery ends with an understanding of what it takes to buy. Fully understand the buyer's purchase requirements before deciding what can be delivered.²⁵ Use a preparation call with the champion to determine what the buyer ultimately needs to make a purchasing decision.²⁶ When the prospect signals that the initiative is a priority, understand the budgetary constraints.²⁷

Bring product leadership into the opportunity when a technical requirement needs evaluation.²⁸ Direct qualification questions give a more accurate read of what needs to happen for the prospect.²⁹ Continue when the criteria, constraints, technical path, and purchase conditions are explicit enough to test in the next conversation.

What not to do

These shortcuts leave the conversation with a feature list and no dependable purchase test.

• Do not jump on a stated need before you understand it.³⁰
• Do not demo a requested feature before understanding why the prospect asks for it.³¹
• Do not treat nice-to-haves as essential requirements.³²
• Do not leave multiple decision criteria unresolved.³³
• Do not move directly from quick problem agreement without working on solution agreement.³⁴
• Do not leave competitive gaps untested. Ask whether your solution is missing anything the competition offers.³⁵