TEDDICC: The Technical Deal Framework

MEDDICC qualifies the deal from the AE’s seat. It says nothing about whether the product actually fits, whether the proof will land, or what technical risk is hiding under a confident demo. That work belongs to the Sales Engineer, and most SE orgs leave it undefined.

TEDDICC defines it. Seven letters, each one something the SE drives rather than waits on, run in parallel with MEDDICC. The test is simple: if an SE can’t answer for a letter, that’s a gap in the deal, and the SE owns closing it.

I built this for my team so “technical win” stops being a gut feel and becomes something you can run in a pipeline review.

My SEs are drivers of the deal, not passengers. Each letter is something the SE actively drives and has a perspective on, not something they wait for the AE to surface. If an SE cannot answer for a letter, that is a gap in the deal, and the SE owns closing it.

The Framework at a Glance

TEDDICC in Detail

T — Tech Fit

Confirm and expand the technical pain before assuming a solution fits. The pain must be real, specific, and acknowledged by the customer, not inferred. From there, establish that the product genuinely meets their technical needs, both for what they need today and for where they are heading at scale. This is the first question of the deal: can we actually meet their needs from a technical product perspective?

DIAGNOSTIC QUESTION What specific technical pain has the customer confirmed in their own words, and where does our product genuinely not fit yet?

E — Environment

Map the world the product has to live in. That means the customer’s architecture, existing tooling, key workflows, integration points, data realities, and security posture, and just as importantly, the people: the architects, operators, and end users who will work with the product day to day. The SE builds a clear picture of the technical and human terrain so nothing about the customer’s environment becomes a late surprise.

DIAGNOSTIC QUESTION What in their architecture, tooling, workflows, or security posture could break, block, or complicate our deployment, and who owns each of those?

D — Desired Outcomes

Uncover what the customer is trying to achieve and what they would need to see to believe it is achievable. This is the destination: the technical and business outcomes that define success, and the bar the customer will measure “proven” against. The SE owns getting this explicit and agreed, because every later motion is judged against it.

DIAGNOSTIC QUESTION What has the customer explicitly said they need to see to believe this works, and would they agree that is the bar?

D — Decision Path

Map and own the route the customer must travel to reach the confidence to buy. The SE helps the customer understand what they need to go through to get there, then scopes the right proving motion, whether a POC, POV, proof of technology, workshop, custom demo, or executive briefing, along with the milestones on the way. The path is timed to land inside the customer’s decision window, so the customer experiences a deliberate route to a technical yes rather than a scattered set of activities.

DIAGNOSTIC QUESTION What is the sequence of steps that gets this customer to a confident technical yes, and does it land before their decision window closes?

I — Impact

Quantify the cost of the status quo and connect technical capability to business value, including value the customer had not yet recognized. The SE makes the value case proactively rather than waiting for the customer to volunteer the numbers: the current state and its negative consequences, the future state and the positive business outcomes that come with it.

DIAGNOSTIC QUESTION In numbers the business cares about, what is the status quo costing them, and what is solving it worth?

C — Coalition

Build a technical coalition inside the account, not a single point of failure. Strong deals are carried by multiple champions who co-own the technical narrative when the vendor is not in the room. This includes alignment with the technical economic buyer, the senior technical decision-maker who can bless or veto the deal.

DIAGNOSTIC QUESTION Who carries our technical narrative when we are not in the room, and who can technically veto this deal?

C — Critical Risks

Hunt the risks that survive everything else. A deal can have strong tech fit, clear outcomes, a successful proof, and a real coalition, and still die. The SE digs for what can still go wrong: product gaps, security and compliance review such as SOC 2, FedRAMP, questionnaires, and pen tests, competitive landmines and rigged evaluation criteria, and a clean post-sales handoff, because a botched handoff risks account health, the renewal, and the expansion that follows.

DIAGNOSTIC QUESTION What is most likely to kill or stall this deal even if everything else goes well, and what are we doing about it?

Using the Diagnostic Questions

These questions are gap-finders, not scorecard fields. In a pipeline review or 1:1, the right answer is sometimes “I don’t know yet”, and that is the question doing its job and naming the work. If every question earns a clean answer every time, the questions have quietly decayed into box-ticking, which is the failure mode to watch for.

Run the questions as a review instead of reading them. The companion skill reads your existing deal notes, walks the seven letters as a conversation, scores each, and hands back the gaps the SE owns closing.