MEDDICC Metrics examples: product results and business value

01

Two layers, two readers

The technical evaluators test the product number against written success criteria, and the economic buyer decides whether the business figure is worth the money and the change. GitLab's public sales handbook distinguishes technical metrics, which demonstrate the solution's capabilities, from economic metrics, which connect it to the customer's large strategic initiatives. With the economic buyer, it advises leading with business outcomes and explaining how the technical metrics contribute.

A Proof of Value starts from two to four business outcomes, in the customer's own words, agreed by the economic buyer, and then tests the product against them.

02

Write each Metrics line as a chain

Write each Metrics line as a chain: the product number, the change it makes in the customer's work, and the cost, revenue or risk that change moves.

In Datadog's story about SAS, CPU utilization for a critical microservice falls by a factor of four, resulting in roughly 75% lower compute cost.

In Palo Alto Networks' story about AutoNation, store networks could be operational in 30 minutes, compared with a wait of 60 to 90 days for new MPLS circuits. The reported $3.5M in annual savings came from retiring legacy MPLS and buying cheaper internet services.

In CrowdStrike's story about Cogentrix, strengthening the security program was followed by a 45% reduction in cyber insurance costs, saving about $300,000 over three years. In a deal like this, ask which security improvements the insurer needs to see and whether those would change the premium.

Use these examples to prepare questions. Your customer still has to confirm their own starting point, what the product must demonstrate and how that would change cost, revenue or risk.

03

A made-up MEDDICC Metrics example for invoice matching

In this made-up deal, automatic matching could release staff time; the budget effect still needs the customer's confirmation. Say you sell software that matches supplier invoices to purchase orders. The prospect is a wholesale distributor whose accounts payable team handles 5,000 invoices a month.

Product: in the Proof of Value, the software matches 80 of every 100 invoices without a person touching them. Today 25 of every 100 match automatically.

Work: the team estimates six minutes to match an invoice by hand. Suppose the proof result holds across the monthly workload and the remaining manual matches still take six minutes each. Manual matching would then fall from about 375 hours a month to about 100.

Cost: the controller puts the loaded cost of an hour in the team at €50. At that rate, 275 hours represent €13,750 of staff time a month. Ask what would change in the budget: could the customer remove temporary staff at month end or avoid a hire already planned?

Risk: ask whether delays in invoice matching cause missed early payment discounts or duplicate payments. If so, ask the controller what they cost last year and which part the proposed change could prevent.

04

Check every line before the forecast call

Every qualification element is an evidence claim, and each line of the chain is one. Put four questions to it: What do we know? How do we know it? Who confirmed it? What remains an assumption?

In the made-up deal, the accounts payable lead confirms the 80 of every 100 achieved in the proof against the agreed criteria. The accounts payable manager confirms the 5,000 monthly invoices from the ERP report. Ask the manager to confirm the current automatic matching rate of 25 in every 100 as well. The next question for the lead is whether the proof covers the mix of invoices the team normally receives.

The six minutes remains the team's estimate until someone measures the work. Ask how long the invoices left for manual matching would take. The controller supplies the €50 hourly cost, but the budget owner still needs to say which expenditure would change. Last year's missed discounts and duplicate payments give you a baseline to investigate. You also need to establish how much of that loss better matching could prevent.

GitLab's handbook notes that customers may lack measurements or be unsure what to measure. If a number is missing, agree with the person who owns it how to establish the baseline and what the proof needs to show.

When you review a Metrics field, send back any line that stops at the product number. Ask one question: what does this do to cost, revenue or risk, and who at the customer said so? The business lines are easier to find when the team has already written down which outcomes and metrics customers buy for. That is the business value part of a Value Framework: future state, outcomes and metrics.