Stated vs. Actual Requirements: Separating the Wishlist From the Real Blockers

The prospect sends a requirements spreadsheet with two hundred lines. Many were copied from a template, a previous tender or an analyst checklist. A few describe things the business genuinely cannot operate without. On paper, every line has the same weight. If you treat them that way, you will spend the evaluation defending features nobody will use, and risk losing on a line nobody really needed.

Validating stated vs. actual requirements is the skill of distinguishing wishlist features copied from a generic template from true operational blockers. It is how an SE turns a long list into a short, defensible set of criteria that reflect how the business actually works.

The problem it solves

• The need: undifferentiated requirement lists lead to feature-count evaluations, scope creep and decisions made on irrelevant gaps.
• Who faces it: SEs receiving requirement documents, questionnaires or RFP-style lists during discovery and qualification.
• Stage: discovery through qualification, before an evaluation or proof of value is scoped.
• Decision it supports: which requirements should drive the evaluation, and which can be deferred or dropped.
• Success looks like: the prospect agrees on a short list of must-haves, each tied to a real workflow or constraint.

The three-question test

Run each significant requirement through three questions, asked with genuine curiosity rather than challenge:

1. “Where does this come from?” A specific incident, regulation or workflow suggests a real need. “It was in the template” suggests a wish.
2. “What happens today without it?” If the business already operates fine without it, it is not a blocker, however reasonable it sounds.
3. “What would you do if it were missing?” If the answer is “we could not go live,” it is a blocker. If the answer is “we would manage,” it is a preference.

Sort into three groups

• Blockers: without them the solution cannot be used or approved. These become evaluation criteria.
• Differentiators: they matter and affect preference, but the business would still proceed without them.
• Wishlist: nice to have, often inherited from a template, rarely used. These should not decide the outcome.

Agree the sorting with the prospect. Your goal is not to make your gaps disappear; it is to make sure the evaluation measures what the business really needs. Sometimes that reveals a blocker you cannot meet, and finding that out early is a gift.

Adjusting to the situation

• A skeptical engineering VP on a first call: do not challenge the list. Ask which three lines they would personally fight for, and why.
• A mid-funnel review where the homegrown system “works well enough”: use the “what happens today without it?” question. Requirements the current system already fails are the real ones.
• A cross-functional call with competing priorities: each team’s blockers may conflict. Make the conflict visible instead of promising everyone everything.
• A late-stage deal with vague requirements: run the test on the top twenty lines before any further demo.
• A competitive displacement against an entrenched vendor: lists are often written around the incumbent’s features. Ask which requirements describe outcomes and which describe the current product.
• A regulated environment: regulatory requirements are usually genuine blockers, but check which rule they come from; some are interpretations, not obligations.

Common mistakes

• Arguing that a requirement is unnecessary because you cannot meet it.
• Answering every line with “yes” to avoid friction, then failing the real test later.
• Doing the sorting alone instead of with the prospect.

How you know it worked

• A short, agreed list of blockers exists, each with its source.
• The evaluation or proof of value is scoped around blockers, not the full list.
• The prospect uses your sorting in their own internal communication.

Where this skill sits in the deal

Upstream: current-state workflow mapping and non-functional requirements give you the evidence to test each line. Parallel: decision criteria definition shapes how the agreed blockers will be judged. Downstream: blockers become binary success criteria and feed a scoped mutual action plan.

Practice it before the live call

Separating the wishlist from the blockers works the same way whatever you sell, which makes it part of the 80% of Solution Engineering. SE Ignite teaches it as a free, tech-agnostic micro-skill, so you can practise asking “where does this come from?” without sounding defensive.