Across seven years of doing this work, I came back to one question more than any other. Usually it was two sentences:
Is this good for the user? Is it good for us?
That's the framework. The whole framework. You can put it on a sticky note.
It looks too simple to be useful. I thought so the first few times I came across the idea. What I found, across hundreds of deals and the small judgment calls each one asks of you, is that almost every meaningful question this job will throw at you resolves cleanly when you run it through those two sentences.
How the test works
Apply it to whatever you're considering — a roadmap commitment, a pricing move, a scope expansion, a "we can probably do that" in tomorrow's deck — and one of four things happens.
If both answers are yes, you're probably on the right track. If one is no, there's work to do — usually the work of turning the no into a yes, sometimes the work of choosing a different move. If both are no, walk away. The deal that closes on a both-no looks like a win on Friday and a problem by the next quarter, and the problem tends to have a long tail.
The test doesn't tell you the answer. It tells you whether you have one. Most pre-sales mistakes come from operating in the gray space without ever forcing the question.
Why the user comes first
The two sentences aren't in random order. The user comes first because the second sentence almost takes care of itself when you get the first one right consistently. A genuinely good outcome for a user usually translates into a good outcome for your company over time. The reverse is not reliably true.
A deal that's good for you and bad for the user is the deal that closes in Q4 and shows up on the renewal-risk list by Q2. The user remembers what they were told. They tell other potential users. The reference value evaporates.
A deal that's good for the user and bad for you is rarer than people think. When that combination seems to be the case, the company has usually scoped the offer wrong, or the SA is undervaluing themselves, or there's a commercial wrinkle that isn't actually about the user at all. Worth examining honestly. Almost never the right default.
Where the test gets hard
The principle is easy to agree with and harder to live by, because the situations that test it don't announce themselves clearly.
The hard moments are quiet ones. A late-stage deal where the AE wants you to confirm a capability that's technically possible but operationally fragile. A demo where the cleanest answer involves admitting your product handles their case worse than a competitor's. A call where the user is excited about a use case and you can already see, three steps ahead, the wall they're about to hit that the demo isn't going to surface.
Each of these is small. In each, the easy path and the right path diverge by maybe ten degrees. Most of the SAs I've watched go wrong over time didn't make one big bad call. They made a thousand ten-degree compromises that compounded into a different career than the one they thought they were having.
The way you train yourself out of the drift is by recognizing the moments as they're happening and choosing deliberately. The two-sentence test is the simplest tool I've found for doing it. Is this good for the user? If the answer is anything other than a confident yes, you've found one of the moments. Now you have a decision to make.
You won't always make the harder choice. Nobody does. The deals close, the quarter ends, and sometimes you let a thing slide that you wish you hadn't. That's part of the job, and it's part of being a person doing a job. The goal isn't perfection. The goal is to notice. The SAs who notice consistently end up better than the ones who don't, because over time the small choices add up to a way of working, and the way of working becomes a reputation.
What the test isn't
A few clarifications, because the principle gets misread in both directions.
It doesn't mean the user is always right. Users are smart and they know their business better than you do, but they're often wrong about your product, your category, or the right way to solve the problem they're describing. Pushing back when their initial framing would lead them somewhere bad is part of serving the user, not a violation of the principle.
It doesn't mean ignoring your own company's interest. The test has two sentences for a reason. You're not a free consultant. You work for a company that has its own goals, and serving those goals is part of the job.
It doesn't mean being passive. Some SAs interpret "users first" as a license to be deferential — to take whatever the user says at face value, to default toward saying yes. That's not the principle. The principle is to put the user's interest at the center of your thinking, which often requires being more direct, not less. The user benefits more from a clear "I don't think that's the right path, here's why" than from a polite "we can probably do that."
It doesn't mean you have to win every internal argument. There will be times when you raise a flag and your company decides to do the thing anyway. That's not your decision to make. Your job is to surface the issue clearly and let the people whose decision it is make it with full information.
The compounding effect
Here's the part that takes a few years to see clearly.
Users-first behavior compounds. Every interaction where you tell the user something true that they didn't expect to hear, every gotcha you flag they didn't ask about, every time you walk away from a bad fit instead of forcing it through — all of those accumulate into a reputation. Not a brand-strategy reputation. A real one, in the actual heads of actual users, who tell other users.
It shows up in your fifth year, when half your pipeline is coming from people you worked with in your first three. It shows up when a user you walked away from in 2022 calls you in 2026 because they've finally hit the use case where your product is actually right for them. This is the most quietly satisfying experience in the entire job. It's also the kind of thing you cannot put on a quarterly review.
You can't manufacture it. You can only build it slowly, one decision at a time, by holding the line in the small moments. Two sentences, used consistently. Most of the job.
Adapted from Solutioneering*, available at seperformancetoolkit.com/solutioneering.*