tai rahman

Sales performance

What does it actually take to make a sale?

The short version

  • A VP of Inside Sales once asked me what we actually tell a new salesperson about what it takes to make a sale. I couldn't really answer because I didn't trust the data enough to make the answer useful, so I built a fictional SaaS company where I knew what was supposed to be true and checked whether the analysis could find it.
  • North America looked like it had better sales performance than APAC, but once we accounted for the reps, the regional effect basically disappeared. That's where I started thinking about the difference between seeing something in data and actually understanding it.
  • If you count all of the activity on an opportunity, closed-lost deals can end up with more of it than closed-won ones, because a deal that's going badly stays open and the salesperson keeps trying. Asking what happened early in the deal, before we knew how it would end, was a much better question.
  • My answer to the VP today would be that it depends on the team, the region, the customer, the type of deal and the rep. That isn't very satisfying if you want one number, but it's probably a more honest answer.
  • AI wrote a lot of the code, but I had the business context, the questions and the hypotheses. I'm not sure it saved me much time, but it changed what I spent that time doing, and more of it went into asking questions.

A couple of years ago, a VP of Inside Sales asked me a question that I thought was much more interesting than it initially sounded. When we hire a new salesperson, what do we actually tell them about what it takes to make a sale? How many meetings should they expect to have? How many calls? What does the average sales cycle look like? Ultimately, what are the unit economics of a salesperson?

At the time, I couldn't really answer it. Not because we didn't have enough data in the abstract, but because I didn't trust the data enough to make the answer useful. That's a recurring problem in analytics. You can build a beautiful analysis on top of a dataset and still end up with an answer that nobody in the business trusts because the underlying process that produced the data is messy.

So I started thinking about a kind of magic-wand scenario. What if we could assume the CRM was actually right? Say 95% of the data was accurate. We didn't have to spend half the analysis explaining why somebody didn't log an activity, or why a field wasn't populated, or whether a particular team followed the process differently from another team. If we could take all of those excuses off the table, could we actually figure out what it takes to sell something?

There was another reason I wanted to explore the question. In sales organizations, you often see a group of top performers who do an enormous amount of activity. They have more meetings, more demos, more calls, and generally more of everything that the CRM happens to measure. It's pretty easy to look at that and conclude that more activity produces more sales. But then you find another group of people who are also consistently at the top of the leaderboard, except their CRM activity is surprisingly low. In some cases, they're barely logging anything compared with the first group.

That doesn't necessarily mean one group is working harder than the other. It may mean that they're working differently. Someone in inside sales might spend most of their day on calls and online meetings, all of which leave a fairly obvious trail in the CRM. Someone in field sales might spend six hours driving between customers and sitting in meetings. If the CRM isn't designed to capture that work automatically, comparing the two people based on logged activity is really comparing two different sales motions through the lens of one imperfect system.

That was the question I wanted to investigate. If I didn't already know anything about the sales organization, could I look only at the data and reconstruct some of the things I would normally learn by talking to salespeople and watching how they actually work? Could the data tell me that different sales motions behave differently? Could it distinguish between something that is genuinely driving performance and something that is simply more visible in the CRM?

So I built a fake company

Real sales data is private. So I made my own. I created a fictional SaaS company with sales reps, customer accounts, opportunities, activities, different deal sizes, different sales cycles and different types of customers.

And I basically left cookie crumbs all over the dataset. The idea was that I would know what was supposed to be true. Then I could see whether the analysis could actually find it.

Meetings should matter. Speed to first contact should matter, especially for some types of customers. Some sources of leads should be better than others. Existing customers buying more should behave differently from brand-new customers. Competitors should make things harder. Bigger deals should be harder. Different customer segments shouldn't necessarily behave the same way.

And some things shouldn't matter at all. Region shouldn't matter. Industry shouldn't matter. At least, that's what I put into the simulation. Then I basically said: okay, find the cookie crumbs.

Doing it backwards

This was kind of the opposite of what happens in the real world. Normally you have a business. The business creates data. The data is messy. You analyze it. You find some pattern. And then somebody says, “Okay, but is that actually what's happening?”

And that's a fair question. With this project, we reversed the process. We started with a fictional version of reality where we knew some of the relationships. Then we generated the data. Then we analyzed it.

That gave us a way to test ourselves. If the analysis found something we knew was there, good. If it missed something we knew was there, that was interesting too. And if it found something we didn't put there? That was probably the most interesting outcome of all.

Because that is exactly what happens in real analytics. You don't just get the answer. Sometimes you get something that looks like an answer.

The region problem

One of the things I found really interesting was region. At first glance, you might look at the data and say: North America has a better sales performance than APAC. Okay. So the product must sell better in North America.

But wait. Who is selling in North America? And who is selling in APAC? They're not necessarily the same people.

So is the difference actually the region? Or is it the salespeople working in those regions?

That distinction matters a lot. And in our fictional data, once we accounted for the reps, the regional effect basically disappeared. The reps were the thing driving the difference.

This is one of those things that sounds obvious after you see it. But it's very easy to miss when you're staring at a spreadsheet or a dashboard. You see APAC with a lower win rate and your brain wants to explain it. Maybe the market is different. Maybe the product doesn't resonate there. Maybe the competition is stronger.

But sometimes the answer is much simpler. Maybe you have different people selling there.

And this is where I started thinking about the difference between seeing something in data and actually understanding it. A pattern is not an explanation.

Can you brute-force sales?

Another question started bothering me. Can you brute-force your way to sales?

If I have a really good sales team, can I just add more salespeople and keep growing revenue? Or is there a point where adding another rep doesn't really help? Put differently, would I rather have a SWAT team of exceptional salespeople or an army of average salespeople?

If I'm a business leader and I want to grow revenue, what is the lever I can actually pull? Is the number of salespeople a lever I can keep pulling indefinitely? Or do I eventually hit diminishing returns?

Those are much more interesting questions to me than simply asking whether activity correlates with revenue. Because now we're getting closer to the original question about unit economics. What is one more salesperson actually worth? And the answer probably isn't the same everywhere.

More activity can even look worse

One of the funny things about the analysis was that if you aren't careful, you can convince yourself that more activity is actually bad. You could see closed-lost opportunities with more activities than closed-won opportunities.

At first glance, that's weird. Shouldn't the deals with more meetings and calls be the ones we win?

But think about what happens when a deal is going badly. It stays open. The salesperson keeps trying. More calls. More emails. More meetings. More follow-up.

Eventually you can end up with a closed-lost opportunity that has a huge amount of activity attached to it. So if you simply count all the activity that happened during the life of the opportunity, you can get a completely backwards answer.

That's why we started looking at activity early in the sales cycle instead. Not how much activity did this deal eventually have? But what happened early in the deal, before we knew how it was going to end?

That is a much better question. And that's a pattern I recognize from real analytics work. You can have technically correct data and still ask the wrong question of it.

Which brings me back to that VP

Remember the question? How many meetings does it take to make a sale?

I think today I'd give him a different answer. I'd say it depends. Which team? Which region? Which customer? Which type of deal? Which sales motion? Which rep? Who does the rep report to? And then maybe we can talk about the unit economics.

That isn't a very satisfying answer if you're looking for one number. But it's probably a more honest one.

Businesses love broad averages. They're useful. But they can also hide the thing you're actually trying to understand. Sometimes you have to put the business under a magnifying glass. Look at the subsets. Understand how the pieces behave. Then build the bigger picture from there.

What AI changed about doing analysis

This project also made me think differently about what it means to actually do analysis in 2026. A lot of the code in this project was written with AI. The SQL is more refined than the SQL I probably would have written five years ago. The Python is not something I could sit down and reproduce line by line from memory. And I'm not going to pretend otherwise.

But I also don't think that means AI did the analysis for me. A calculator can do the math. But it doesn't know what math problem you should be solving.

That's how I think about AI. I had the business context. I had the questions. I had the hypotheses. I had the experience of looking at sales organizations and knowing that something didn't pass the gut check. AI helped me turn those questions into code and work through the analysis much faster.

And here's the funny part. I'm not sure I actually saved that much time. I probably spent close to the same amount of time on the project as I would have otherwise. I just spent that time differently.

Five years ago, I would have spent a much larger percentage of my time writing the code. Figuring out the syntax. Cleaning up the technical pieces. Ironing out the data. Getting everything to run. And then eventually getting to the actual analysis.

With AI, I could spend more of that time being a detective. I could ask another question. Then another one. Why does this look like this? What if we control for that? What happens if we look at this segment separately? Is this actually region? Or is it the reps? Why are closed-lost deals showing more activity? Does that make sense?

The technical barrier got lower. The number of questions I could ask got higher. And that, to me, is the interesting part.

What is the moat now?

I don't think the lesson is that you don't need to know SQL anymore. I know SQL. I think understanding code still matters. You need to know what the code is doing. You need to know when something looks wrong. You need to be able to challenge the output.

But I'm not sure that being able to write beautiful SQL from scratch is the moat it once was. AI can write beautiful SQL.

So what matters more? Knowing what question to ask. Knowing which assumptions might be wrong. Knowing when the answer doesn't make sense. Knowing what context is missing. And knowing when the data doesn't pass the gut check.

That's probably always been important. AI just makes it harder to ignore. Because when the technical work gets easier, you have fewer excuses for not spending time thinking.

And maybe that's the weirdest thing about this whole project. Did AI make me faster? I don't know. I think it changed what I spent my time doing.