Retire The Technical Win Trophy [71]
The episode critiques celebrating technical wins too early in the sales cycle, arguing that a technical checkpoint means nothing if the deal ultimately fails. The hosts propose redefining technical wins as validation that you're still in contention (one of 2-3 vendors) and establishing specific post-POC activities rather than retiring the metric entirely.
Summary
Tim introduces a common problem: a Slack channel celebrating technical wins with trophy emojis creates misaligned incentives. An SE posted a technical win on a deal that subsequently died on price six weeks later, with zero customer contact during that period. The SE had mentally marked the deal as complete, treating the technical win as the finish line rather than a checkpoint.
The discussion challenges what "technical win" actually means. From a customer perspective, it's a meaningless phrase—it simply indicates the POC closed and the vendor wasn't disqualified. The hosts reframe it as a checkpoint that keeps you in contention, typically one of 2-3 remaining vendors, not actual victory.
A critical insight emerges: enterprise deals often extend long after technical evaluation concludes. One example describes a deal where technical evaluation finished in month four but procurement continued until month eleven; another mentions a reverse auction driven purely by price where the SE's technical work held zero value.
To address the issue, the hosts propose three concrete activities: (1) a follow-up call with the customer's technical contact after POC sign-off with no agenda, just addressing remaining concerns; (2) a three-minute forwardable video from the SE to the champion explaining how the solution solves their specific pain; and (3) the SE asking the AE one question when contract phase starts: "What would help you get this over the line?" This third question serves as a permission structure that re-engages the SE without requiring them to invent justification.
The recommendation is to keep the quarterly metric but reframe it to answer: "Does our solution consistently resonate?" instead of "How many trophies did we collect?" The key behavioral change is celebrating closed deals, not checkpoints. The implementation advice is to quietly change what gets celebrated rather than announcing a new process—the team will adapt faster.
About this episode
Ava noticed her team throwing a party at the technical win and going quiet for the six weeks that actually decide the deal. She and Nate argue about whether the metric should stay, and land on what presales owes the deal after the POC is signed off.
Key Insights
- The speaker observes that a technical win posted in a Slack channel held zero predictive value for deal closure—the deal died on price six weeks later while the SE remained mentally disengaged, indicating the organization had built a scoreboard that incentivized the wrong moment of celebration.
- The hosts argue that technical evaluation in enterprise deals often concludes months before deal closure (one example cited month four completion but month eleven final closure), meaning SEs who disengage after technical sign-off abandon deals during their most commercially sensitive phase.
- The speaker claims that a reverse auction scenario demonstrates the complete irrelevance of technical SE work to the final deal outcome, positioning price negotiation as the actual determining factor after technical evaluation concludes.
Topics
Transcript
Hey there and welcome to Leading Pre-Sales, the show for solution engineering leaders who want to build teams that drive revenue and not just demos. My name is Tim and I'm the co-founder of SE Rockstars and together with Jan, we've coached over 350 solution engineers and their leaders across several dozens of companies. Every conversation you hear on this show is based on real coaching situations, real challenges, real problems that as e-leaders like you are dealing with right now. None of this is made up. We use AI to bring these stories to life through our two hosts, Nate and Ava, but the insights come straight from the trenches. Each episode gives you one actionable takeaway you can…
Full transcript available for MurmurCast members
Sign Up to AccessMore from Leading PreSales | The Solution Engineering Leadership Show
Never Lie, Never Answer Reflexively [70]
Solution engineers often answer questions reflexively without understanding their context, which can damage deals even when the answer is technically honest. The key principle is distinguishing between genuine honesty and unfiltered explaining, and training SEs to ask clarifying questions before responding.
Stop Begging For Headcount [69]
An SE leader shares how building a capacity model instead of requesting headcount revealed that one AE was consuming 38% of pre-sales resources with below-average deal value, leading to better resource allocation and CRO buy-in without hiring three additional engineers.
When the ICP Moves, PreSales Pays the Bill [68]
When companies shift their Ideal Customer Profile (ICP), pre-sales teams bear the heaviest operational cost despite decisions being made at the executive level. Building a named second ICP with dedicated SEs before crisis hits—rather than after—enables survival when market conditions force a pivot.
Your CRO No Longer Wants a PreSales Department [67]
A CRO's desire to eliminate the presales department stems from revenue growth being concentrated in renewals and expansion, not new logos. The solution isn't renaming teams or restructuring, but strategically deploying SE skills to high-impact moments in the customer lifecycle with proper compensation alignment and narrow pilots before full organizational change.
Return on Token: Who Owns the Hours AI Gives Back [66]
This episode discusses the concept of "Return on Token" — ensuring that time saved by AI tools is intentionally allocated to specific business outcomes rather than absorbed into unmeasured activities. Leaders must decide what freed capacity will be used for before purchasing tools and track outcomes through managers rather than individual audits.