Sales Frameworks Were Built for Salespeople. So Why Are SEs Expected to Run Them?

MEDDIC, SPIN, Challenger, and their various offspring were designed to help salespeople qualify opportunities and control conversations. They assume a generalist seller talking to a buyer about business outcomes. When solutions engineers apply these frameworks to technical discovery, demos, and POC scoping, the fit is poor - and the damage is often invisible until the deal is already lost.

This isn’t a controversial observation if you’ve lived it. But it’s a surprisingly rare one in the literature, which tends to focus on whether salespeople are using frameworks correctly. The more interesting question is what happens downstream, when SEs inherit those frameworks secondhand and try to apply them to conversations they were never designed for.

The answer, mostly, is that demos get built on assumptions, POCs get scoped too broadly, and technical champions quietly disengage while everyone argues about whether the methodology was followed.

The Frameworks Do What They Were Designed to Do

Credit where it’s due. MEDDIC gives sales teams a shared qualification language. SPIN provides a structured way to uncover needs through questioning. Challenger offers a model for reframing a buyer’s thinking when they’re stuck in the status quo. These are genuinely useful tools for the problems they were built to solve - qualifying out bad deals, multi-threading enterprise opportunities, giving managers a common vocabulary for pipeline reviews.

The trouble starts when organisations treat them as the operating system for the entire deal, rather than the operating system for the sales motion within the deal.

An SE gets handed a MEDDIC-qualified opportunity. The AE says: “We’ve confirmed the Economic Buyer, there’s a compelling event in Q3, and the Champion is engaged. Go build the demo.”

The SE walks into technical discovery and immediately encounters problems the framework didn’t surface. The technical champion has a completely different success metric than the Economic Buyer. The existing stack creates integration constraints that will blow up the proposed timeline. The “compelling event” is actually a soft deadline with no engineering resources allocated to it - a date on a slide, not a date on a project plan.

MEDDIC told the AE the deal was real. It told the SE nothing useful about how to make the demo land.

This isn’t a failure of MEDDIC. It’s a category error. Sales frameworks optimise for deal qualification. SEs need tools that optimise for technical fit and demo relevance. These are different problems, and pretending they’re the same one is where things start to quietly fall apart.

What Happens When SEs Run Discovery the Sales Way

When SEs use sales-style discovery questions - focused on pain, budget, and business outcomes - they tend to get answers that are too vague to build anything from. “We want to improve pipeline visibility” is a perfectly good sales discovery output. It tells the AE that there’s a recognised problem and probably budget attached to solving it.

It tells the SE almost nothing.

What the SE actually needs to know: what CRM are they on, who owns the data, what does the current reporting workflow look like, where does it break, who complains about it loudest, and what would have to be true for them to change it. The gap between “improve pipeline visibility” and those six questions is exactly where demos go wrong.

The SE builds a pipeline dashboard demo. The technical champion wanted workflow automation. The demo doesn’t land. The AE blames the SE’s delivery. The SE knows the real problem was upstream, but articulating that without sounding like they’re making excuses is a skill most people don’t develop until they’ve been burned enough times to stop caring about the politics.

There’s a career cost here that doesn’t get discussed much. SEs who can’t articulate this gap - or who articulate it too bluntly - get labelled as “not business-focused” or “too in the weeds.” The actual issue is that they were handed bad inputs and expected to produce good outputs. That’s not a skills problem. That’s a process problem wearing a skills problem’s clothes.

The mismatch runs deeper than just the questions. Sales discovery is designed to surface organisational pain and buying intent. Technical discovery needs to surface current architecture, integration constraints, team capability, and the specific workflow the product will touch. These require different questions, different conversation dynamics, and a fundamentally different relationship with silence and follow-up.

An SE asking “what does success look like for your team?” will get a polite, abstract answer. An SE asking “walk me through how your team handles X today, step by step” will get the kind of detail you can actually build a demo around. The first question sounds more strategic. The second one is more useful. Sales frameworks consistently optimise for the first kind.

The Challenger Problem in Technical Conversations

The Challenger model asks sellers to teach, tailor, and take control. As a posture for reframing a buyer’s business thinking, this can work well. In technical conversations, it often reads as condescending. Engineers and architects don’t generally want to be “taught” by someone they suspect knows less about their stack than they do.

There are moments where an SE should challenge a prospect’s assumptions - about what’s possible, about the cost of their current approach, about the risk they’re carrying without realising it. The principle isn’t wrong. The posture is.

Here’s the specific failure mode. An SE has been coached to open with a “reframe” - a provocative insight designed to shift the prospect’s thinking. They deploy it on a technical discovery call. The prospect’s lead engineer immediately pushes back with a counterexample from their own environment. The SE, trained to “maintain the tension,” holds their position. The engineer disengages. Not angrily - just quietly. They stop volunteering information. They start giving shorter answers. The technical champion goes from warm to lukewarm, and nobody on the selling side quite understands why.

The AE doesn’t see a problem. From their perspective, the SE did exactly what the playbook said. The SE might not even recognise what happened, because the feedback is absence rather than objection. The engineer didn’t argue. They just stopped helping.

The better posture for SEs in technical conversations isn’t Challenger. It’s something closer to credible curiosity - demonstrating enough depth to be taken seriously, then asking questions that show you’re genuinely trying to understand their environment rather than score points against it. Technical buyers extend trust to people who seem to actually care about getting the details right. They withdraw it from people who seem to be performing expertise for tactical advantage, even when the expertise is real.

This is a subtlety that framework-driven coaching tends to flatten. The difference between challenging someone’s assumptions and making them feel like you think they’re wrong is mostly tonal, and it’s almost impossible to train through a methodology deck.

What SEs Actually Need

Rather than adapting a sales framework, SEs benefit more from a technical engagement model built around three things: environment mapping, constraint surfacing, and relevance anchoring. This isn’t a new acronym to put on a slide. It’s a recognition that the SE’s job in a deal is fundamentally different from the AE’s, and that trying to run the same playbook creates confusion for everyone.

Environment mapping means that before any demo, the SE should be able to describe the prospect’s current state in enough detail to explain why the default demo is wrong for this account. Not “they use Salesforce” but “they use Salesforce with a heavily customised opportunity object, their reporting runs through a separate BI tool that pulls from a data warehouse, and the team that owns pipeline data is not the team that requested this evaluation.” If you can’t describe the environment at that level, you’re not ready to demo. You’re guessing.

Constraint surfacing is the part that saves deals - or, more accurately, saves everyone the time of running a POC that was never going to work. Every deal has at least one technical constraint that will determine whether the POC succeeds: integration timelines, security review requirements, data structure assumptions, team time for implementation. Finding it early is the SE’s job, and it’s a job that no sales framework assigns to anyone.

Relevance anchoring is what makes demos land. Each demo section should be explicitly tied to something the prospect said in discovery, by name. Not “this feature helps with reporting” but “you mentioned your RevOps team rebuilds the pipeline report manually every Friday - here’s what that looks like when it’s automated.” The difference between a demo that gets polite nods and a demo that gets the technical champion leaning forward is almost always this: did the SE connect the capability to a specific, named problem that the prospect recognises as theirs?

Sales frameworks don’t teach any of this, because they weren’t built for it. That’s not a criticism. My toaster doesn’t teach it either, and I don’t hold that against the toaster.

Who Owns the Fix

SEs inherit sales frameworks because sales leadership designs the go-to-market motion and presales sits downstream of it. This is an organisational reality, not a conspiracy, and treating it as something to rail against is roughly as productive as complaining about weather.

The more useful move is for SEs to advocate for a distinct technical engagement model - not as a rejection of sales process, but as a complement that actually makes the sales framework work better. A well-run MEDDIC process with good technical discovery feeding into it is significantly more powerful than MEDDIC alone. The AE gets better qualification data. The SE gets better inputs for demo prep. The deal moves faster because the POC is scoped to something that can actually succeed.

Practically, this means SEs need to get comfortable asking for specific inputs before they agree to build a demo. Before any demo prep, the SE asks the AE for three things: the technical champion’s specific workflow pain (not the business pain the Economic Buyer articulated), any integration or security constraints that surfaced in discovery, and the AE’s read on what would make the technical champion a strong internal advocate.

If the AE doesn’t have those answers, that’s not a failure - it’s useful information. It means technical discovery hasn’t happened yet, and the demo should be delayed or scoped down to a discovery demo rather than a solution demo. A discovery demo is a perfectly legitimate move. It’s just not the same move as a solution demo, and conflating them is how you end up showing features to people who needed a conversation.

SEs who can articulate what they need and why - without framing it as a complaint about the process - are the ones who get pulled into deal strategy conversations earlier. That’s where influence in deals actually lives. Not in the demo itself, but in the planning that happens before anyone opens a browser.

The Uncomfortable Part

None of this is easy to implement, partly because it requires SEs to push back on timelines and partly because it requires AEs to accept that qualification isn’t complete until technical discovery has happened. Both of those conversations involve someone being told that the deal isn’t as far along as they thought, which is nobody’s favourite message to deliver or receive.

But the alternative is the status quo: SEs building demos from insufficient inputs, deals stalling in technical validation because the POC was scoped wrong, and everyone blaming execution when the problem was upstream.

Sales frameworks aren’t broken. They do what they were designed to do, for the people they were designed for. The issue is that SEs aren’t those people, the technical conversation isn’t that conversation, and the framework’s silence on what happens after qualification is not the same as the framework saying nothing needs to happen.

It’s just not yours. Build what’s yours.