MEDDICC questions to ask, and what counts as an answer

01

When an answer counts

An answer counts as evidence for the specific point its source can confirm. Every qualification element is an evidence claim, so put five questions to each one. What do we know? How do we know it? Who confirmed it? What remains an assumption? Which conversation or action could create the missing evidence?

Prepare for "Who confirmed it?" before the call. Name the role that can answer each unresolved question. If your contact is passing on someone else's account, record that source and plan how to check it.

Then the answer to "How do we know it?" takes one of three forms: the person's own words to you, a document of theirs or an action. A document might be a requirements list, an approval procedure or a report with today's number. An action might be an introduction made, a meeting booked or a step taken inside their company.

02

MEDDICC discovery questions for each element

For each element, ask the question whose answer could change what you and the customer do next, and plan how to reach the person who can confirm it.

03

Identify Pain

Pain counts when the customer says it is a problem for them. What you infer from their tools or their industry stays an assumption. A customer who runs an old system has told you what they use, and nothing yet about wanting to change it.

GitLab's handbook asks its sellers: "Who has the pain and who is in charge of fixing it?" Put both halves of that question to the customer. The person who feels the problem every day can describe it. The person in charge of fixing it can say what happens if it is still there at a date they care about.

The answer counts when it names a consequence in cost, revenue or risk that the customer recognises, and you can name the person who described it. Then ask who else would describe it the same way.

04

Economic Buyer and Champion

Confirm the economic buyer's authority for this purchase, and test a potential champion through a request. The MEDDICC site, meddicc.com, cautions: "The Economic Buyer is unlikely to raise their hand and tell you they’re the EB."

Ask who approved the last comparable purchase, then use the answer to identify whom to speak to about this one. With that person, ask: "What can you approve for this purchase, and whose agreement do you need?" Then ask which business outcome would make the purchase worth approving. Record their approval role and the outcome they need as separate answers.

Ask your contact to introduce you to the economic buyer. The economic buyer page on meddicc.com warns: "If your Champion is unwilling or unable to introduce you to the EB, this could be a signal that they aren’t a true Champion, and you have work to do." An introduction gives you evidence of access. Keep testing what the person can influence and what they actually do to move the decision inside the company. Until that is established, call them a potential champion and keep in mind that you may be dealing with a coach. In a deal review, ask what they have done since your last call.

05

Decision Process and Paper Process

Confirm each decision and approval step with its owner, including what completes it and when it needs to happen. meddicc.com says the decision process "usually consists of two parts: technical validation and business approval". Ask who runs each part and what has to be true for each step to be done.

More meetings do not show that the deal is moving. meddicc.com cautions against judging progress "based on the amount of engagement you have had with a customer". Ask which agreed validation or approval step the latest demo or reference call completed.

A decision to buy still leaves the route to signature to confirm. Even after the champion and the economic buyer have agreed to buy, meddicc.com warns, a deal "can stall in legal review, security sign-offs, vendor questionnaires, or Master Service Agreement (MSA) negotiations." Ask the people in procurement, legal and security for their own steps and how long each takes.

GitLab's handbook gives its sellers a question that also works with the customer: "Has a purchase of this size happened before?" If it has, ask how it went and who signed. If it has not, the people you talk to may not know every step yet, so ask who would.

06

Metrics, Decision Criteria and Competition

Metrics, decision criteria and competition count when they stand in the customer's own numbers, documents and comparisons. For Metrics, ask the person who owns the number for today's baseline from their own report. Then write each line in two layers: the product number, and what it does to cost, revenue or risk.

"Your customer often won’t have defined criteria," meddicc.com notes, and helping them write the criteria is part of the work. Ask the technical evaluators and the business stakeholders to confirm the criteria and how they will be prioritised. The customer's pain and the metrics you have quantified "only influence the outcome if they show up in the criteria used to make the decision."

Competition is wider than other suppliers. meddicc.com defines it as "any person, vendor, or initiative competing for the same funds or resources you are." Ask the customer what else they are considering, including changing nothing and building it themselves. GitLab's handbook asks its sellers where they are strong and weak "as perceived by the customer", and then: "Have you discussed this with your client?" So ask the customer how they see each alternative.

07

Questions your manager will ask in a deal review

Prepare for a deal review by identifying the customer conversation that can answer each open question. GitLab's public handbook page on MEDDPPICC lists qualifying questions for each element, written for the seller about the deal. Three of them show how a review question points back to the customer:

Economic Buyer. GitLab asks: "How do you know they’re actually the EB (versus someone higher in the organization)?" Ask the customer: "Who can authorise this purchase?" With that person, confirm: "What can you approve, and whose agreement do you need?" The last comparable purchase gives you a starting point, not confirmation of current authority.

Decision Process. GitLab asks: "Are you and the customer vested in the above workback plan?" Ask the customer: "Can we agree who will do each step and by when?" Review the plan with the people responsible for those steps and record what they commit to.

Decision Criteria. GitLab asks: "Have all key customer stakeholders helped shape the above requirements?" Ask the customer: "Who needs to help set these requirements, and who has contributed so far?" Confirm the criteria with the people named, including those whose input is still missing.

08

What to write down after the call

Record each answer with its source, date, form and the specific point it supports. For anything still unconfirmed, write down who needs to answer and what you need to ask. An entry might read: "The IT manager named the finance director as the economic buyer. Approval authority for this purchase is unconfirmed. Next: ask the finance director what they can approve and whose agreement they need."

Sales Engineers hear many of these answers first. They meet the technical evaluators, watch the decision criteria take shape during the evaluation and often notice early whether the economic buyer is involved. Ask them to record what they hear in the same way: who said it, and how they know.

Use the gaps that could affect the customer's decision to prepare the next meeting. In my opportunity qualification training with MEDDICC, a widely used third-party framework, each participant brings a current opportunity and leaves with the next customer meeting prepared. Managers get review questions for pipeline reviews and one-to-ones.