Required Capabilities: the jobs the solution has to do
Without the capability list the demo is a guess — and so is every differentiator you lead with.
Updated
Required Capabilities is not one of MEDDPICC’s eight letters. SalesWolf tracks it anyway, and says so here rather than quietly presenting it as part of somebody else’s methodology.
What are required capabilities?
Required capabilities are the things the solution has to actually do, stated as jobs rather than as features. This is not a MEDDPICC letter; SalesWolf tracks it because without the list the demo is a guess and every differentiator the rep leads with is a coin flip. A capability that is merely named tells you what to show, not why it matters or whether you have proved it.
What does the solution actually have to do?
Ask for jobs rather than features, then ask which one would make the whole thing not worth doing if you got it wrong. That one leads the demo.
How it actually gets missed
The capability list arrives as a feature checklist and gets answered as one. Nobody asks which items are actually load-bearing, so the demo spends its best fifteen minutes on the capability that was easiest to demo rather than the one the decision turns on.
How deep, not how many
Required Capabilities questions, from named to evidenced
Required Capabilities has three rungs, and where a deal sits on them is the difference between a dimension you have answered and one you have qualified. These are the rungs SalesWolf marks on the deal, by the same names and in the same order. What is written under each is the standard to hold a deal to. The product can only mark what is on record, so check its rung against this bar before you rely on it.
named
You know what the solution has to do. A list of features, at this point, and nothing more.
“What does it have to do for this to count as fixed — in jobs, not features?”
Gets the list in the customer’s language, which is the language they will score you in.
“Is there a list already, and who wrote it?”
Finds the document and its author before the demo is built around a guess.
tied to value
You know why each one matters — the job it does and what breaks without it. This is what turns a demo into an argument.
“Of everything on that list, which one, if we got it wrong, would make the whole thing not worth doing?”
Sorts a flat feature list into the one capability the decision actually turns on.
“What breaks today because you do not have that?”
Ties a capability to a real consequence, which is what makes it worth leading a demo with.
evidenced
They have seen it work on their own terms: their data, their workflow, their edge case. Not a recorded demo.
“What would you want to try yourself before you believed it?”
Names the evidence they would accept, so the proof step is designed rather than guessed.
“Could we run that on a sample of your own data before the next meeting?”
Proposes evidence on their terms, with a date attached.
Done when · You can name what they need the product to do, what each one is worth to them, and our edge on it.
The questions for every letter, on one page.
This page in plain text, with nothing to sign in to. Open it on a phone on the way into the call.
Sample deal · Halden Freight · Required Capabilities
On a deal, it has a position. On this one, it is confirmed at tied to value.
Qualification
Gaps aren't failures. They're the next things worth learning.
14 days free, no card, no call.