Converting Objections to Requirements

Every objection has a version that becomes a condition of approval. The presenter who treats objections as obstacles to overcome is trying to remove them from the conversation. The presenter who treats objections as conditions is trying to satisfy them on the way to approval. These are different orientations that produce different conversation dynamics — and different outcomes.

The conversion technique is a specific question: "What would need to be true about [the objection topic] for you to feel comfortable approving this?" This question does two things simultaneously. It accepts that the objection is legitimate — you are not dismissing it. And it moves the conversation from "should we approve?" to "under what conditions should we approve?" The second question is answerable. The first often is not.

## CONVERTING OBJECTIONS TO REQUIREMENTS

FORMAT: "What would need to be true about [objection topic]
         for you to feel comfortable moving forward?"

═══════════════════════════════════════════════════════════════════
OBJECTION: "This seems risky."
REQUIREMENT QUESTION: "What would need to be true about the risk
                       mitigation for you to feel comfortable with
                       a Q2 deployment?"

TYPICAL ANSWER: "I'd need to see the phased rollout plan and
                 understand what the rollback procedure looks like."

WHAT YOU NOW HAVE: A specific, buildable specification. The objection
"this seems risky" just became "provide phased rollout plan + rollback
procedure." That is a document, not a barrier.

═══════════════════════════════════════════════════════════════════
OBJECTION: "Your data seems weak."
REQUIREMENT QUESTION: "What sample size or methodology would give
                       you confidence in a deployment decision?"

TYPICAL ANSWER: "I'd want to see at least 1,500 claims, or have
                 a third-party review the methodology."

WHAT YOU NOW HAVE: 1,500 claims (a 30-day pilot extension)
or third-party review. Both are achievable. The data challenge just
became a specification for a pilot extension proposal.

═══════════════════════════════════════════════════════════════════
OBJECTION: "I'm not sure the timing is right."
REQUIREMENT QUESTION: "What would need to change about the timing
                       or the organizational context for this to be
                       the right moment?"

TYPICAL ANSWER: "I'd want the Q3 transformation project wrapped
                 first — we are stretched on implementation capacity."

WHAT YOU NOW HAVE: A timing dependency, not a fundamental objection.
The recommendation is not rejected — it is sequenced. The conversation
is now about whether Q4 launch is acceptable vs. indefinite deferral.

═══════════════════════════════════════════════════════════════════
RULE: An objection that cannot be converted to a requirement is
      either fundamental opposition (not a condition) or an undisclosed
      concern (the stated objection is not the real one).
      If the executive cannot answer the requirement question, probe
      for the underlying concern before proceeding.