shiptalk

Two things I learned from a week of QSRs

Sitting in a run of QSRs this week surfaced a couple of things worth writing down — less “here’s a framework,” more “here’s what actually came up and what I did with it.”

When the customer doesn’t want to run a POV

One opportunity this week: the prospect wanted to skip a technical proof of concept entirely and move straight from a lengthy RFP into commercial conversations. The instinct is to read that as a red flag — no validation, no proof, more risk. But it’s usually not a rejection of technical rigor. It’s more often a rejection of time. The real question becomes: how do you preserve the validation without the timeline cost the customer is clearly trying to avoid?

A few ways to do that without a live POV:

  • A solution architecture doc, mapped to their actual environment — their stack, their integration points, their data flows. Less “trust us,” more “here’s exactly how this fits.”
  • A scoped “paper POC” — walk their stated requirements through your capabilities in writing. Does the technical analysis a POC would do, without the multi-week commitment.
  • A targeted risk/gap assessment — call out plainly what’s low-risk and well-trodden versus what needs real attention. Signals maturity; you’re pricing in the uncertainty instead of hiding it.
  • A reference architecture from a comparable environment — borrowed validation instead of built-from-scratch validation.
  • A short technical workshop instead of a full POC — 60–90 minutes with the right stakeholders can extract most of what a POC would have, compressed into one sitting.

But skipping a POV can also hide something else, something that isn’t technical at all: a qualification gap wearing a technical conversation as a disguise. Worth checking, actively rather than assuming:

  • Budget — is there a real, sized number, or is “let’s move fast” a sign the budget isn’t actually locked?
  • Exec alignment — is an actual economic buyer driving this, or is the RFP being run by a team a level below approval?
  • Quantified business pain — has the cost of the problem been put in real terms, or is it still “this would help”?
  • Delayed time impact — what does slipping a quarter actually cost the customer? If there’s no real number behind it, the urgency behind “let’s skip ahead” may not hold up on its own.

If those are soft, more solution architecture work won’t fix the actual risk. That’s a conversation to have directly with the AE, not just something to compensate for quietly.

Finding the real wedge, not just a feature list

A separate thing came up in a different conversation this week, and it’s stuck with me since.

A prospect was already frustrated with a platform that had caused real outages as their usage grew — and the incumbent’s proposed fix was more spend, to shore up the same architecture that caused the problem in the first place. That’s an odd position for a customer to be in: pay more to patch instability, instead of having it resolved as part of what they already pay for. That’s a values-level opening as much as a technical one — the incumbent’s answer to instability was more of the customer’s money, not more reliability.

The sharper move wasn’t stopping there, though. This same customer was also actively investing in a specific, separate area of their stack — unrelated to the outages — and had adopted a tool built for that one purpose. That tool did its one job well, but it didn’t connect to the rest of their operational picture.

That’s the real technique, and it generalizes well past this one conversation: look for where a customer has a genuine coverage gap around something they’re actively investing in, then pair that gap with pain they’re already feeling elsewhere. Either one alone is a decent pitch. Together, they turn three separate, weaker asks into one clear question — and that’s usually the difference between a conversation that moves and one that stalls out in “we’ll think about it.”

What ties both of these together

Neither of these showed up as a framework I walked in with. Both showed up as a question, asked at the right moment, that reframed a conversation that was otherwise stalling. The QSR itself is a good forum for surfacing these — not because the answer lives in the room, but because saying the stuck thing out loud, to people who aren’t buried in the day-to-day of the deal, is often what produces the question that actually moves it.

If you want something more concrete than a mindset to walk away with, I put together the actual prompts I run before a QSR — deal summary, qualification gaps, champion health check — in a post earlier.

Have a reaction, a story of your own, or a disagreement? I'd genuinely like to hear it — email me or find me on LinkedIn.