Definition
Decision Criteria: Decision Criteria are the requirements and standards a buying group uses to compare options and choose a solution: what the solution must do, why it matters, and how options will be scored. In MEDDPICC, strong criteria are shaped, agreed and documented before the final vendor comparison.
Free course · Module 3 of 8 · 15:37
Watch the Decision Criteria module
17 chapters
Decision Criteria are how the buyer will judge you, and if you don't shape them, your competitor will. You'll learn the Technical, Relationship and Economic lenses, how to plant landmines and expand the pie, build a reverse RFP scorecard, run every demo as tell, show, tell, and lock must-haves in Solution Alignment so the buyer picks you for outcomes, not features.
Part of the free 8-module Deal Management MEDDPICC Master Class. Next: Module 4, Economic Buyer.
On this page
What Decision Criteria Really MeansDecision Criteria vs Decision ProcessFrom Preferences to Needs to OutcomesExamples: Weak vs Shaped CriteriaWhat “Done” Looks LikeCommon Decision Criteria MistakesPlays to Move Decision Criteria to GreenHow Decision Criteria Connects to Deal ManagementWhere to Go Deeper Discovery questionsWhen I sold Recruitment Process Outsourcing, almost every buyer told me the same thing in early discovery: they wanted to “improve recruiting efforts and reduce cost per hire.”
I absolutely sold a solution to that. But did that mean I was the right fit?
- If the need was shaped around “better software,” we lost to a technology provider.
- If it was shaped around “expanding our internal team,” we lost to adding headcount.
- If it was shaped around “expertise, flexibility, and predictable costs,” we won.
Same outcome. Different solution path. Different winner.
That’s Decision Criteria.
What Decision Criteria Really Means
Decision Criteria is the alignment between your solution and the client’s wish list. In Deal Management terms, it’s the needs half of the Desired Future State: the buying criteria the new solution must meet, and how the buyer believes the problem should be solved.
Here’s the part the textbook definition leaves out:
Needs aren’t just about solving the problem. Needs are the shaped criteria that make your approach the right approach.
If the criteria point to your strengths, you’re the obvious choice. If they point to a different approach, you’re dead, even if you can solve the problem.
How you shape them depends on how the deal started:
- Inbound: the buyer usually arrives with a list, sometimes influenced by a competitor. Your job is quick, tight alignment, and translating features into outcomes.
- Outbound: there’s no list yet. Your job is co-creation: must-have versus nice-to-have, and growing the criteria together so the evaluation rewards your strengths.
Decision Criteria vs Decision Process
These two get blurred constantly, and they fail in different ways.
| Decision Criteria | Decision Process | |
|---|---|---|
| The question it answers | What will they decide on, and how will they compare options? | How, by whom and when will the business decide? |
| Deal Management criterion | Desired Future State | Buying Process (business lane) |
| Who shapes it most | Problem Owners and Technical Buyers | Problem Owner, Executive Sponsor, Economic Buyer |
| The document that locks it | A scorecard of must-haves, nice-to-haves and scoring | A mutual action plan with steps, owners and dates |
| What failure sounds like | “You all look alike.” “We’re still comparing options.” | “We’re ready,” then the deal slips a quarter |
| What done looks like | Shaped, agreed, and clearly favoring you | Known, tracked, and moving in the agreed direction |
Criteria decide which vendor wins the evaluation. Process decides whether and when the business actually buys. You need both. (More on the process side in Decision Process in MEDDPICC.)
From Preferences to Needs to Outcomes
There’s an order to shaping criteria. Skip steps and you create feature shopping.
- Capture preferences. The wish list. The surface-level asks.
- Translate preferences into needs. What the solution must do, why, and how they’ll decide. Agreed on and shaped to your differentiators.
- Define outcomes. What improves, gets faster, safer, cheaper or more predictable.
Skip shaping needs, you get commoditized. Skip outcomes, you run into competing priorities. Don’t document it, the criteria drift and the deal stalls.
When a buyer says, “We need X capability,” the reframe is:
“What outcome does that drive, and what happens if you get the capability but not the outcome?”
That moves the evaluation from a checkbox exercise to a value conversation.
Examples: Weak vs Shaped Criteria
Red sounds like: “We want a modern platform.” “We want better reporting.” “We want to use AI.” It might be true, but it’s not usable.
Yellow sounds like: “They said faster is the goal.” Sound bites instead of locked criteria, and nothing documented or socialized with the executives who’ll approve the spend.
Green sounds like: “These are the criteria we’re deciding on, and these are the outcomes we’re driving toward.”
Remember that different stakeholders define “good” differently. Execs care about outcomes. Operators care about workflow. Finance cares about business impact. Security cares about risk. And criteria aren’t only features. Ask what holds across every solution the business buys: integrations, best of breed, service priority.
What “Done” Looks Like
Done is when you’ve shaped the criteria, the buyer agrees with them, and they clearly favor your solution.
In practice, green means:
- Must-haves and nice-to-haves are locked, in writing.
- Your differentiators are explicitly agreed on, tied to those locked criteria.
- Every locked criterion has an outcome attached, and every outcome becomes a line item in the business case.
- You’re Vendor of Choice, stated or strongly implied.
On timing: you want directional criteria (yellow) leaving Discovery, so you can start shaping and differentiating early. Criteria should be green by the end of Solution Alignment, the stage where criteria stop drifting.
One pressure test before you call it green:
“If we locked the solution requirements today, is there anyone who’d push back on what we’ve agreed to?”
Criteria often feel stable when they’re not, because the person who can change them hasn’t been in a meeting yet.
Common Decision Criteria Mistakes
Taking the list at face value. Validate every requirement, demo to the checklist, and you become interchangeable.
Product tours. Speed dating across features creates more confusion than clarity.
Letting one stakeholder define success for everyone. A new stakeholder shows up late and says, “That’s not what I’m looking for.”
Jumping to a proposal after a good demo. Liking a demo isn’t choosing a solution. Every time the solution shifts, the outcomes shift. Every time the outcomes shift, the criteria shift. That’s how evaluations drag on.
Plays to Move Decision Criteria to Green
Reverse RFP Scorecard. Build a simple spreadsheet with the problems to solve down the left and the criteria across the top, with columns for must-haves, nice-to-haves and a simple scoring model. Review it with the buying team and agree what’s essential versus optional and how they’ll score it. You prevent “you all look alike” and shape needs around your differentiation.
Criteria Disruption. When criteria are predefined in an RFP or templated process, treat it like an opponent-influenced document. Ask for the criteria early, schedule a review, and expand the definitions:
“When you say X, do you mean just X, or would it be better if it also did Y and Z?”
Suggest missing criteria, each linked to a real problem. And if you can’t shape or disrupt it, consider no-bidding and going to the most senior executive owner with a compelling case.
Cinematic Demo. Break the demo into short mini-movies, each tied to one need and one outcome. After each, ask what it would change for them. End by proposing the scorecard to lock criteria.
High Contrast. In a finalist demo, confirm the must-haves first, show only those, and ask the team to score each one against what else they’ve seen.
The Why Us Play. Document the problem, the key needs and the outcomes you uniquely deliver. Have your problem owner or champion correct it, then share it for consensus.
If criteria keep drifting even after you’ve shaped them and tried to lock them in, you’re not in a deal. You’re in an endless evaluation cycle. That’s one of my disqualify rules.
How Decision Criteria Connects to Deal Management
Decision Criteria maps to Desired Future State, which has two parts: needs and outcomes. MEDDICC calls the needs piece Decision Criteria and assumes you connect it back to Metrics. That connection is where most teams drop the ball.
Two other links matter:
- Stakeholders. Technical Buyers own the aggregated criteria and unlock Vendor of Choice. If you don’t influence criteria with them, someone or something else will.
- Competition. Green on Competition means strong mutual fit aligned to the decision criteria and differentiators the buyer believes. You can’t differentiate against shifting criteria.
Where to Go Deeper
- The stage where criteria get locked: The Two Sales Process Stages Nobody Builds.
- Why your demo isn’t moving criteria: Why Your Demo Isn’t Closing Deals.
- Grade every letter on evidence with the free MEDDPICC Scorecard, and see what should be green by each stage on the Stage Cheat Sheet.
Discovery questions for Decision Criteria
Don't ask these in order, and don't ask them all on the first call. Use them to check what you haven't asked yet.
- What are the most important things you're looking for in a solution? What's a nice-to-have versus a need-to-have?
- When companies evaluate solutions like ours, they typically look for A, B, C and D. Which of those are the biggest priorities, and why?
- What is causing you to look for a new solution now?
- Why are those capabilities so important? What are you going to do with them, and what outcome are you looking to drive?
- Can you stack rank your priorities right now? Is there a future vision to expand that we need to think about?
- Who would use, or benefit from the outcomes of, each piece of this solution?
- How are you comparing solutions so you can see the differences between them?
- What are you using to rank priorities and feedback on solutions across all the different stakeholders?
- When you think about the solutions your business buys, what criteria always seem to hold? Certain integrations, best of breed, service priority?
- Outside of features and functionality, is there anything else that's important to you in a provider?