Answer a Feature Checklist Without Hiding the Gaps

A feature checklist can be a useful first filter. It can also turn nuanced requirements into yes-or-no answers that obscure important conditions.

Read the signal

A feature may exist only on a certain tier, require configuration, or work differently from what the buyer expects. Marking yes without those conditions can create a false impression and a painful later review.

Make the next move

For each requested capability, state availability, package, dependency, and evidence. Ask which requirements are mandatory. Offer to demonstrate the critical ones in the buyer’s workflow instead of relying solely on a spreadsheet.

Language you can adapt

Illustrative wording:

I completed the checklist with notes on scope and dependencies. Which three items are deal requirements? I would like to verify those in your use case before you score the options.

The wording is a starting point. Replace the problem, evidence, and request with details the buyer actually gave you. If those details are missing, ask a question before sending a polished message. Specificity makes it easier for the buyer to correct your understanding and easier for you to see whether the opportunity is moving.

Decide what happens next

If a mandatory requirement is not met, mark it plainly. Do not hope a vague answer survives technical validation.

Write the result in your deal notes as an observable fact: who responded, what they agreed to do, and when. A friendly reply is useful, but a decision, a named owner, or a scheduled review tells you more. If the next step remains vague, treat that as information about the deal rather than a reason to send the same follow-up again.

Use these examples responsibly. Describe your product, pricing, and customer results accurately, and adapt every suggestion to the buyer’s stated process.