SE Performance Toolkit

The two-sentence test

There's a question I've come back to more often than any other across seven years of doing this work:

Is this good for the user? Is it good for us?

That's it. That's the entire framework. If the answer to both is yes, you're probably on the right track. If the answer to one is no, there's work to do. If the answer to both is no, walk away from whatever you were about to do.

I'll use this question repeatedly throughout the book, because it's the only frame I've found that holds up across every situation the job throws at you. The technical decisions, the deal decisions, the contract decisions, the moments where you're tempted to overpromise, the moments where you're tempted to undersell — all of them resolve cleanly when you put them through the two-sentence test.

This chapter is about the first sentence. The user side. The reason it comes first isn't sentimentality; it's that the second sentence almost takes care of itself if 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.

What "users first" actually means

The phrase is so common in B2B software that it's lost most of its meaning. Every company says they put users first. Many of them mean it, in the sense that they have it on a slide. Far fewer have actually thought about what it requires when the user's interest and the company's short-term interest pull in opposite directions.

For an SA, "users first" is a working principle, not a value statement. It shows up in concrete decisions. Here are some of them.

You tell the user the truth about fit. If your product isn't the right answer for what they're trying to build, they need to know. You don't have to say it in the first call, and you don't have to say it loudly, but you can't let them buy something that won't solve their problem. The deal you close on a bad fit is a customer you'll lose in eighteen months, plus a reference you can't use, plus a story they tell other potential users. The deal you walk away from cleanly is a relationship that often comes back later for the right reason.

You don't sell the roadmap. You sell what's on the truck — what your product does today, in production, that they can actually use. If a feature is six months away and it's the thing that would make the deal close, the right move is to say "that's on the roadmap, here's the rough timeframe, here's what we have today that gets you part of the way there." The wrong move is to lean on the future date as if it's a commitment. Roadmaps slip. Priorities shift. Companies reorganize. The user who bought based on a roadmap promise is the user who's furious eighteen months later when the feature didn't ship on the timeline they expected. We'll come back to this in Chapter 10, but it starts here.

You answer the question they actually asked. When a user asks a hard technical question, the temptation is to answer the easier question next to it — the one you have a confident answer for. Don't. If they asked whether your platform handles a specific edge case in their flow, and the answer is "we handle most of it but not this part," tell them. Specifically. The relationship is built on the moments where you say the harder thing.

You bring up things they didn't think to ask about. This is the move that separates a good SA from an order-taker. The user is operating with imperfect information. They don't know what they don't know about your category, your product, or the failure modes of the integration they're considering. Part of your job is to surface those things, even when they make the deal more complicated. The user who learns about a gotcha from you, before they hit it, becomes a customer for life. The user who learns about it after they signed becomes a churn risk.

You hold the line on what you don't know. The pressure to seem confident is constant, especially in front of users who are themselves senior and skeptical. Resist it when you actually don't know something. Saying "I don't know, let me follow up after the call" costs nothing and earns trust. Making something up costs everything when the user catches it later, which they will.

These aren't sacrifices. They're investments. Every one of them looks, in the moment, like it's slowing the deal down or making it smaller. Over time, they're what makes the function durable. The users you treat this way come back. They expand. They refer. They give you the kind of feedback you can actually use to build a better practice.

Where this gets hard

The principle is easy to agree with and hard to live by, because the situations that test it don't announce themselves clearly.

The hard moments are usually quiet ones. A late-stage deal where the AE wants you to confirm a capability that you know is technically possible but operationally fragile. A demo where the user asks a question and 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 see, three steps ahead, that they're going to hit a wall the demo isn't going to surface. Each of these is a small moment, and in each of them the easy path and the right path diverge by maybe ten degrees. Most of the SAs I've seen go wrong over time didn't make one big bad call; they made a thousand small ten-degree compromises that compounded.

The way you train yourself out of the ten-degree drift is by recognizing the moments as they're happening and choosing deliberately. The two-sentence test is a way to slow down enough to recognize them. 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 and the quarter ends and sometimes you'll 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 "users first" doesn't mean

It's worth being clear about what the principle isn't, because it 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. Part of the job is pushing back when their initial framing of the solution would lead them somewhere bad. "Users first" doesn't mean "do whatever the user says." It means "actually serve the user's interest," which sometimes requires telling them they're heading in the wrong direction.

It doesn't mean ignoring your own company's interest. The two-sentence 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. The principle is that the user's interest and the company's interest, properly understood, almost always align over a long enough horizon. If they seem to be diverging, that's usually a signal that something is off — either the user isn't a good fit, or the company is asking for something it shouldn't be.

It doesn't mean being passive or accommodating. Some SAs interpret "users first" as a license to be deferential — to take whatever the user says at face value, to avoid disagreement, 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." The phrase I came back to most often, over the years, was "I have thoughts." It's a soft warning shot — it tells the user (or the AE, or the room) that you're about to share something they may not want to hear, and it gives them a beat to lean in instead of bracing.

It doesn't mean you have to win every argument internally. 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. Sometimes they'll be right and you'll be wrong. Sometimes you'll be right and the deal will close anyway and the user will be fine. Sometimes you'll be right and it'll bite the company later and the lesson will get learned. All of that is part of the system working. The thing you control is whether the issue got raised.

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 moment where you flag a gotcha 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.

In any given B2B category, there's a small group of people who become known as the trustworthy ones. The SAs whose users come back when they change companies. The SAs whose old users introduce them to new users without being asked. The SAs whose deals tend to expand quietly over time without much commercial pressure. These people don't usually have a system for it. They have a habit of choosing the harder right answer in the small moments, sustained over years.

This is the most undersold form of compounding in the job. It doesn't show up in your quarterly numbers. It shows up in your fifth year, when half your pipeline is coming from people you worked with in your first three years. 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. It shows up when an AE you've never worked with messages you out of the blue because three of their prospects mentioned your name.

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 this. You can only build it slowly, one decision at a time, by holding the line in the small moments.

A note for builders

If you're building an SA function, the leverage point for users-first behavior is hiring and tone, not policy.

You can't write a "users first" rule that survives quarterly pressure. You can hire people whose default is already in the right place, set the tone from the top about what you actually reward, and then back the SAs when they make calls that cost you a deal in service of doing the right thing. That last one is the hardest and the most important. The first time an SA on your team walks away from a deal because the fit was wrong, what you do in that moment defines the function for the next two years. If you celebrate the call, you've built a culture. If you grumble about the lost number, you've trained the team to never do it again.

The other thing you can do is design the metrics so they don't actively work against the principle. SAs who are measured purely on attached deal volume will, over time, attach to anything. SAs who are also measured on user outcomes — implementation quality, post-sale satisfaction, expansion in their accounts — will be more deliberate about which deals they're pushing through. The metrics aren't everything, but they're part of the environment, and an environment that punishes good judgment will eventually erode it.