The most important sentence in pre-sales
There's a phrase that's been around in technology sales for a long time: sell what's on the truck.
It comes from a different kind of selling — the version where there were actual trucks, with actual products on them. If a customer wanted something that wasn't on the truck, you couldn't sell it. You could promise to bring it next week. You could try to talk them into something else that was on the truck. What you couldn't do was ship them a feeling. The discipline carried over into software, even though most software SAs have never seen the truck in question.
Sell what's on the truck means: solve the customer's problem with the tools you have today, in production, that actually work. Don't sell the roadmap. Don't sell the beta. Don't lean on a future date as if it's a present capability. The customer should be making their decision based on what your product does now, not what it might do later.
This sounds obvious. Almost every SA I've worked with would, if asked, agree with it. In practice, the discipline is much harder to live by than to articulate, because the moments where the temptation to violate it is strongest are exactly the moments where the deal is most at stake.
Why the temptation is so strong
The temptation to sell future capability shows up in predictable patterns.
The user has a specific requirement that your current product doesn't fully meet. There's a roadmap item that would address it, expected sometime in the next two or three quarters. The deal is otherwise a good fit. The cleanest way to make the deal work is to lean on the future capability — to position it as something that's "coming soon" or "in the next release" — and let the user form their decision around it.
Or: the user is excited about a beta feature you have access to. It's not generally available, but it works most of the time, and demoing it would be impressive. The temptation is to demo it as if it were a core part of your offering, knowing that the user will remember the demo and not remember the asterisks.
Or: the AE is under quarter-end pressure and asks you to confirm a capability that's technically possible but operationally fragile. The system can do the thing, in some sense — but it's not how anyone actually runs it in production, and there are real failure modes you'd want to call out. The temptation is to give the cleaner answer, leave the caveats for later, and let the deal close.
In all of these cases, the future-leaning answer makes the present moment easier. It also creates a problem that's worse than the one you avoided. The user signs based on capability that doesn't yet exist, that may not exist on the timeline they expect, and that they're going to be furious about when reality doesn't match what they remember being told.
What goes wrong, specifically
The damage from selling beyond the truck takes a few forms, and it compounds over time.
The user's implementation breaks against reality. They've designed their system around what they were told the product would do. When that turns out to be different — different timeline, different shape, different reliability — they have to redesign. The redesign is on their time and their cost. They remember exactly who told them what, and the trust is gone.
The renewal becomes contested. The deal that closed on a future-capability promise comes up for renewal a year or two later, and now the user is doing the math on what they actually got versus what they expected. If the gap is meaningful, the conversation is hard. The renewal might happen, but the relationship is colder, the expansion is smaller, and the reference value is gone.
Your reputation, specifically, takes the hit. The AE moves to a new account. The product team isn't in the user's meetings. The CS person inherits the relationship and explains away as much as they can. The one person whose name the user remembers is yours, because you're the one who told them what the product would do. You might never hear about the consequences directly, but the user mentions it to other potential users in your category, and your name gets a quiet asterisk attached to it.
The function loses internal credibility. When SAs are known to overpromise, the rest of the company adjusts. Engineering treats SA-sourced requirements with skepticism. Product discounts what SAs report from the field. CS expects to inherit messes. The role becomes harder to do well because the trust that the role depends on has been eroded.
None of this happens dramatically. It happens slowly, deal by deal, in small increments. But it happens, and it's preventable.
The discipline, day to day
Living the discipline doesn't require heroics. It requires a few specific habits.
When you describe what the product does, describe what it does today. Use present tense. "The platform handles this case in the following way." Not "The platform will handle this..." unless you're explicitly talking about something that's not yet shipped, in which case label it as such. The verb tense matters more than people realize. Future-tense descriptions of present capability subtly bleed into present-tense descriptions of future capability.
When you mention something that isn't yet available, label it clearly. "That's on the roadmap; the rough timeframe is X, but I'd encourage you not to plan around that date." The label is the discipline. The moment you mention a future capability without labeling it, you've blurred the line, and the user will remember it as something more concrete than you intended.
When the user asks if the product can do something, and the honest answer is "sort of," say "sort of" — and then be specific. The vague yes is the trap. "Yes, kind of" is fine. "Yes, but here are the specific edges" is better. "Not exactly, here's what we can do" is sometimes the right answer. Specificity is your friend. Vagueness in the moment becomes a problem you inherit later.
Push back when the AE wants you to stretch the truth. This is uncomfortable and necessary. Most AEs aren't trying to mislead the user; they're trying to close the deal, and they're sometimes willing to lean further into future capability than you'd like. The right move is to talk about it, privately, between you and the AE. "I don't want to commit to that timeline. Here's what I'm comfortable saying." Most AEs will accept this if you offer them a clear alternative. The ones who don't are a different problem, and we'll come back to that.
If you've already overpromised, correct it. This is the hardest one. You're three meetings into a deal and you realize you said something in an earlier meeting that wasn't quite right — or wasn't quite as solid as it sounded. The temptation is to let it lie and hope the user doesn't notice. Don't. The cost of correcting it now is small. The cost of correcting it after they've signed is large. "I want to revisit something I said last week — I described it more confidently than I should have. Here's the more accurate version." That sentence is uncomfortable to say. It's also the difference between being someone the user trusts and someone they don't.
The exception that isn't
There's a version of selling-future-capability that some SAs convince themselves is okay: when the future capability is genuinely on the roadmap, with a real commitment, and the timeline is short. "This is shipping in eight weeks, I've talked to the team, it's solid."
Be cautious here. Software ships when it ships. The timeline you've heard from the team is the timeline they're working toward, not a guarantee. Things slip. Priorities shift. Companies reorganize. The eight-week feature becomes a sixteen-week feature, sometimes, and occasionally it becomes a "we decided to deprioritize that work" feature. This is not a moral failure on anyone's part. That is simply how building products works.
You can mention near-term roadmap items. You should mention them. What you should not do is build the deal around them. The deal should make sense based on what your product does today. If the user would only sign because of a feature that's eight weeks away, the deal isn't ready. Either help the user wait until the feature ships, or close the deal on the merits of the current capability and let the future feature be a bonus rather than a foundation.
The discipline is to make the future capability additive, not load-bearing. "Here's what the product does today, which solves your core problem. There's also some work coming in the next few quarters that should make this even better." That framing is honest and it doesn't trap you. The other framing — "Today the product does X, and in eight weeks it'll do Y, which is what you really need" — does trap you, because if Y doesn't ship on time, the foundation of the deal is broken.
The connection to "users first"
Selling what's on the truck is what the users-first principle looks like in this specific situation. The user's interest is to make a buying decision based on accurate information. Your interest, properly understood, is the same — because users who buy based on accurate information stay, expand, and refer. The short-term incentive to overpromise is misaligned with the long-term incentive to build a durable practice.
The two-sentence test from Chapter 3 is built for these moments. Is leaning on this future capability good for the user? Almost always, no. Is it good for us? In the short term sometimes, in the long term almost never. When both answers point in the same direction — and on this question they almost always do — the right call is clear. The hard part is making it consistently, in the moment, when commercial pressure is pulling the other way.
A note for builders
This is one of the hardest principles to operationalize at the function level, because the pressure to violate it doesn't come from the SA function itself. It comes from sales leadership, from finance, from the CEO at quarter-end. The SA function absorbs the pressure but doesn't generate it.
The best leaders I've seen on this issue do two things.
First, they're explicit and consistent about what they reward. They celebrate the deals that closed cleanly on accurate capability. They notice — and quietly raise — the deals that closed on stretched commitments and went sideways later. The pattern of attention shapes the team's behavior more than any policy.
Second, they create cover for SAs who push back. When an SA says "I'm not comfortable committing to that timeline," the leader supports them, including in front of the AE and the AE's manager. The first time this happens visibly, the team learns that the discipline is real and supported. If the leader instead pressures the SA to give the AE what they want, the team learns the opposite — the discipline is rhetoric, and what's actually rewarded is closing deals at any cost.
The function doesn't choose which version of itself it becomes. The leadership chooses. The leadership choice is whether to live with the short-term pain of harder deals or the long-term pain of an eroded practice. The companies that choose the former end up with a function that's worth what they pay for it. The companies that choose the latter eventually end up rebuilding the function from scratch, often without quite understanding why the previous version stopped working.