MEDDIC in the Field Part 2 - The Solution Engineer's Real Job: Owning Decision Criteria, Not Just the Demo

The solution engineer had built what she believed was a flawless demo. Every feature the prospect asked about was covered, the environment ran without a hitch, and the room nodded along for the full hour. Afterward, the account executive felt great about the deal.

Three weeks later, the prospect chose a competitor. The evaluation scorecard, when the team finally saw it, weighted “implementation timeline” and “existing integrations” far higher than the technical depth the solution engineer had spent the hour demonstrating. Nobody on the selling team had ever asked how the criteria would be weighted, or who wrote the scorecard in the first place.

The solution engineer had done an excellent job answering the questions the prospect asked. She had done nothing to shape the questions the prospect was asking.

Decision Criteria Is Not the Prospect's Job to Hand You

Most technical evaluations are not neutral. The criteria on a scorecard usually reflect whatever the evaluation team already knows, which often means they favor whatever tool they have used before, whatever a competitor has already pitched, or whatever a single influential stakeholder cares most about. If you walk into a demo without having shaped the criteria first, you are being graded on someone else's rubric, and there is a good chance it was not built with your strengths in mind.

This is where the solution engineer's role goes far beyond running the demo. The SE is usually the person with the deepest access to the technical stakeholders, which makes the SE the best positioned person on the deal to influence what “good” looks like before the evaluation even begins.

How to Shape Criteria Before You Ever Open the Demo Environment

Ask before you build. Before creating a single demo environment, ask the technical buyer directly: “What does your evaluation scorecard look like, and who wrote it?” If no scorecard exists yet, that is an opportunity, not a gap. Offer to help build the framework, and you will naturally shape it around what you do best. In fact, take some time to build a few templates that you can have at the ready.

Find the unstated criteria. Prospects rarely list “how much support the vendor provides after go live” or “how quickly we can migrate from our current tool” on their first pass. These often matter more than the features they do list. Surface these directly by asking what has gone wrong with previous tools they have implemented.

Introduce criteria your competitor cannot meet. If you know a competitor's product requires a lengthy professional services engagement to configure, and yours does not, make implementation speed part of the criteria conversation before the prospect ever builds their scorecard.

Confirm the weighting, not just the list. A criterion that is listed but weighted at five percent is not worth fighting for. Ask directly how the evaluation team will score each item, and push to understand which three or four criteria will actually decide the outcome.

A Real Example

If a prospect's stated Metric is reducing onboarding time from six weeks to two, and one of your platform's core strengths is self-service onboarding, that should become a named, weighted criterion on the scorecard, not a feature you happen to mention during the demo.

The connection between Metric and Decision Criteria is where technical evaluations are actually won.

Take Action

• Before your next demo, ask the technical buyer directly whether a scorecard exists and who is writing it.

• Identify at least one unstated criterion your prospect has not mentioned but clearly cares about, based on what has failed for them before.

• Propose one criterion that plays directly to your platform's strength and your competitor's weakness.

• Confirm how each criterion will be weighted, not just whether it appears on the list.

• Tie your demo agenda directly to the prospect's stated Metric, not just their feature requests.