Leading PreSales · 2026-10-30 · 6 min
Key moments - from our scoring
Substance score
38 / 100
Five dimensions, 20 points each
This episode tackles the build-versus-buy decision for SE tools through a concrete example: a PoC platform that works in theory but creates constant workarounds in practice. The hosts explore how to evaluate whether a tool genuinely limits revenue or if teams are just chasing shiny features. The framework is deceptively simple: start by defining the customer outcome you want, treat security and compliance as solvable problems rather than opening constraints, then name one senior person as a "brake" - someone who asks whether this is truly your biggest bottleneck right now. The episode emphasizes the cost of distraction: a director once let two of his best SEs spend most of a quarter building a custom demo data generator while his region's competitive win rate tanked. Instead of relying on committee judgment or Slack complaints, the leader recommends a structured Friday log where each SE records gaps customers hit in POCs. When the same gap appears three times in a month, it signals a real problem worth solving. Only then does the build idea come to the table with evidence, not emotion.
Hosted by Jan-Erik Jank & Tim Brömme. The show scores 63.0/100 on substance across its analysed episodes. See the full show profile.
Track workarounds in a structured log - when the same workaround appears three times in a month or the same customer request shows up across multiple SEs week after week, that's a real signal. Slack grumbling is data you can't use; a Friday log where each SE records one line about what customers couldn't do in the PoC creates accountability.
Start by defining the customer outcome you want, then treat security and data protection as problems to solve once you know what you're protecting. Opening with constraints causes teams to design the smallest thing that passes review instead of the right thing.
Name one senior person as the decision-maker (the "brake") and timebox exploration to 1-2 hours. That person asks: "Is this our biggest bottleneck right now?" If yes, go; if not, park it and keep logging until evidence justifies returning to it.
A director once let two of his best SEs spend most of a quarter building a custom demo data generator while his region's competitive win rate slid; it took another month to get them back onto live deals. Every hour spent building is an hour not in front of customers.
Committees stall rather than stop decisions because nobody owns the "no." A single named decision-maker with a clear question (biggest bottleneck?) prevents months of delays and prevents good ideas from becoming mission creep.
Our reviewer’s read on each dimension, with quotes from the episode.
For a 6-minute episode there is a reasonable cluster of concrete mechanisms: outcome-first framing, a named single 'brake' person instead of a committee, a 1-2 hour unconstrained dream session, the 'biggest bottleneck' gate question, a weekly gap-log, and a workaround-frequency signal. Density is above average for the runtime, though the ideas themselves are not deeply sophisticated.
If you open with constraints, you design the smallest thing that'll pass review. If you open with the outcome, you design the right thing and then you figure out how to make it safe.
When the same workaround shows up three times in a month, that's a pattern.
The 'outcome-first, constraints second' reframe is a useful inversion but not a novel idea; the named brake person vs. stalling committee distinction is the most original practical point. Overall the thinking is sensible and applied, but not contrarian or first-principles in any meaningful way.
committees don't break, they stall. Because nobody owns the no.
If you open with constraints, you design the smallest thing that'll pass review. If you open with the outcome, you design the right thing and then you figure out how to make it safe.
There are no real guests - the episode explicitly uses AI-generated fictional hosts (Nate and Eva) to dramatise composite coaching scenarios. The underlying experience belongs to the off-mic founder, who never appears in the substantive content, making the 'practitioner credibility' entirely indirect and unverifiable.
We use AI to bring these stories to life through our, uh, two hosts, Nate and Eva. But the insights come straight from the trenches.
There are a few grounding numbers (12 SEs logging the same gaps, 3-workaround threshold, 1-2 hour timebox, 'most of a quarter' lost to a side project) that make the advice feel field-tested. However, all named characters and companies are fictional composites, so the evidence cannot be independently verified or benchmarked.
12ses, same few gaps, week after week.
one of my SE directors let two of his best people spend most of a quarter building a custom demo data generator. Brilliant tool, genuinely. Meanwhile, his region's competitive win rate was sliding
The scripted dialogue does simulate productive pushback in places, but it is entirely pre-written, so there is no genuine spontaneous follow-up, no real uncertainty, and no moment where an unexpected answer reshapes the conversation. The challenge exchanges are staged rather than earned.
Sounds a bit like semantics to me.
So here's what I actually want to know. How do you tell when Buy is genuinely failing, rather than people just wanting a shiny new toy?
Computed from the transcript - who did the talking, and the words that came up most.
Lead build-vs-buy calls: outcome first, then one hard bottleneck question Ava's team kept duct-taping workarounds onto a bought POC platform until one SE built the tool she actually wanted in an afternoon. Nate pushes back on skipping constraints, and together they work out how to pair unconstrained dreaming with a named brake so build ideas don't turn into distractions. What Nate and Ava discuss Why opening with security and data-protection constraints kills good tool ideas, and how to treat them as problems to solve instead Pairing a builder with one named 'brake' and timeboxing the no-limits phase to one or two hours Spotting when 'buy' is really failing: repeat workarounds and a weekly log of customer asks you couldn't deliver The move Give the next build idea a one-to-two-hour session with no constraints. Then have one named person ask whether this is your biggest bottleneck right now. If it's not, park it, and keep a weekly log of 'we couldn't do it' moments so it comes back with evidence. Resources & Links: paths.to/presales Book a Discovery Call: calendly.com/serockstars-tim/discovery-call
Transcribed and scored by The B2B Podcast Index.
Speaker A: Hey there and welcome to Leading Presales, 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 SE 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, uh, two hosts, Nate and Eva. But the insights come straight from the trenches. Each episode gives you one actionable takeaway you can apply immediately, whether you're already leading a team or working your way into that role. Alright, let's get into it.
Speaker B: Nate, I have a confession. A year ago, I told my team out loud, we are not a software company. We buy tools, we don't build them. And we buy our PoC platform. The thing that spins up trial environments and tracks what the customer tested. Except my SEs keep hitting its walls. Every other week, someone shows me a new workaround. A spreadsheet here, a script there, a Slackbot glued on top. Nothing talks to anything.
Speaker C: I know that museum. Every big org I've worked in had a whole wing of it
Speaker B: right then, One of my SEs, Priya, built a rough prototype of the POC workspace she actually wanted one afternoon. Ugly. But it worked. And suddenly the question in my head wasn't if anymore. It was when.
Speaker C: And that, I'm afraid, is exactly the moment that makes me nervous.
Speaker B: Welcome to leading presales. I'm Ava.
Speaker C: And I'm Nate. Every episode. One idea, five minutes. This is part three of our Value in Velocity series. And, uh, today, how to lead build versus buy decisions without killing innovation or drowning in it.
Speaker B: So here's the thing. When most leaders evaluate a tool idea, they start with the security review. Data protection, performance, who maintains it, and by minute 10, the idea is dead.
Speaker C: Look, sometimes the idea deserves to die. Security isn't a mood. When one of my managers wants a new tool, it goes through procurement, Infosec, legal architecture review. We're talking months.
Speaker B: Totally. I'm not saying skip it. I'm saying don't open with it. Start with where do I actually want to go? What should the customer feel in a poc? Then treat security and data protection as problems to solve later once you know what you're protecting.
Speaker C: Hmm, Sounds a bit like semantics to me.
Speaker B: It's a huge difference in practice. If you open with constraints, you design the smallest thing that'll pass review. If you open with the outcome, you design the right thing and then you figure out how to make it safe.
Speaker C: Fair point. I've watched whole teams design for the review board rather than the customer, but here's my You've got an excited SE with a prototype and a leader who's just as excited. Who's the adult in the room?
Speaker B: Huh? That's the other half. I need a break. For me, that's Marcus, my most senior se. He told me I look like a kid building Lego in the attic when I get going on this stuff.
Speaker C: I rather like Marcus, though. At my scale, the break is usually a committee. And committees don't break, they stall. Because nobody owns the no.
Speaker B: Which is why I'd name one person. And we time box it one to two hours, where Priya and I go completely wild. No constraints, just sketch the dream. Then Marcus walks in and asks one question. Is this our biggest bottleneck right now? Because every hour Priya spends building is an hour she's not in front of a customer.
Speaker C: And what did he say?
Speaker B: He said, not yet. Our bigger problem this quarter was messy handoffs from SE to customer success after the technical win. So we parked it. Honestly, it stung. Priya was not thrilled with me either.
Speaker C: That's the bit I'd underlined twice. A couple of years back, one of my SE directors let two of his best people spend most of a quarter building a custom demo data generator. Brilliant tool, genuinely. Meanwhile, his region's competitive win rate was sliding and nobody was looking at it.
Speaker B: Oof. Uh, so what happened?
Speaker C: I asked him Marcus's question. He went very quiet. Took us another month to get those two back onto live deals. So here's what I actually want to know. How do you tell when Buy is genuinely failing, rather than people just wanting a shiny new toy?
Speaker B: I watch the workarounds. When the same workaround shows up three times in a month, that's a pattern. And the platform is telling you something. And I track the ideas we can't build. Every Friday, each SE logs one line. A customer wanted this in the poc, and we couldn't do it
Speaker C: Structured then. Not just grumbling in Slack.
Speaker B: Exactly. Grumbling is data you can't use. The log is how Priya's prototype got taken seriously in the first place. 12ses, same few gaps, week after week.
Speaker C: Right. So the move. Next time someone brings you a build idea, give it a time boxed session. One or two hours, no constraints. Name one person as the break, then ask the only question that is this our biggest bottleneck right now? If yes, go. If not, park it and write down why.
Speaker B: And my twist? Keep the Friday log running while it's parked. When the we couldn't list keeps growing, the idea comes back to the table with evidence attached.
Speaker C: Evidence I can work with. I'm Nate.
Speaker B: And I'm Eva. See you next episode.
Speaker A: Thanks for listening to Leading Presales if you are leading a pre sales team in Europe, wherever you're stuck right now, chances are someone has already solved it. The pre Sales leadership community is where you find them. 250/SE leaders across Europe from companies such as SAP ServiceNow and Salesforce, talks from leaders who've actually done it, and a network that goes beyond your own company. It's free and nobody's selling you anything in there and it's 100% exclusive only to solutions leaders. Apply@serockstars.com community links of course in the show notes until next time and keep leading from the front.
Your SEs Don't Need the Price List. They Need the Metric. [57]63 / 100Thirty Seconds That Sells [45]52 / 100Garbage In, Confidence Out [34]88 / 100I Don't Know - And That's the Right Answer [30]54 / 100Stop Hiring Resumes [29]52 / 100