The 30-Tab Model My CEO Killed in Four Minutes

The Model Was Excellent. The Question Was Wrong.

I spent two weeks analyzing a portfolio deal. One teammate was working through the seller's data. I was building the model. We were asking good questions. We were also being slow.

My CEO answered the deal in about four minutes on a Friday management call. No spreadsheet. He didn't need one.

That gap between how I was thinking about the deal and how he resolved it in four minutes is the thing I want to unpack. Because it shows up in finance teams constantly, and it's getting worse, not better.

What We Built

A deal came across my desk. Motivated seller, reasonable ask, a clear opportunity to put capital to work.

So we did what we do.

My team is good at this. When a deal lands, the process kicks in automatically. Pull the data. Build the model. Layer in the scenarios. Run the sensitivities. Look at it from five angles before pricing. I'll put our workflow against any analytical shop I respect.

The model we built had thirty tabs. Scenario toggles for base, downside, and stress. Sensitivity tables. A returns profile cut by cohort, by duration, by every slice of the data you'd want. Clean formatting, logical structure, no hardcoded numbers feeding the summary.

It was, honestly, a beautiful piece of work.

Then I pushed back on my own team. The dataset the seller sent covered the wins. It didn't show anything still in flight, still at risk, still capable of going the other way. I told the team we needed the complete picture before I priced anything. That was the right instinct.

It's also the instinct that was about to cost us a week.

What My CEO Did Instead

On our Friday daily, my CEO asked where we were on the deal. I started to explain. He cut through it before I could finish.

The shape of what he said was this: don't wait on the broker. Structure it ourselves. Price it. Make an offer the broker isn't going to love, and send it today.

Then he whiteboarded the deal on the call.

He named the obligations already sitting on the asset. He positioned our capital behind them. He set a preferred return. He sketched a fee structure that would compound regardless of how the underlying performed. He ended with, "the probability of failure on that is almost zero."

Four minutes. No spreadsheet.

I said something like: "So we are overthinking this. You're right."

The term sheet went out a few days later.

Why He Could Answer in Four Minutes

The answer isn't that my CEO is a genius, though he is. The answer is that he was solving a different question than I was.

I was building a pricing model. Its job was to answer: what's the fair economic return on this book?

He was doing a risk assessment. His question was: what's the probability this deal loses money?

Those sound like the same question. They're not.

Pricing requires the full picture. Reserve math. Scenario returns. Sensitivity to the stuff you can't see yet. You need the data I was waiting on.

Risk assessment requires structure. If you can put your capital behind a large existing obligation, against a much larger asset base, with a preferred return and a fee contract that compounds regardless of performance, the probability-of-failure question is answered before you open Excel.

The model wasn't wrong. It just wasn't the question.

The Distinction That Actually Matters

Here's what I'm writing down from this one.

The quality of a financial model isn't measured by its complexity. It's measured by whether it answers the binary question someone needs to make a decision.

My CEO didn't need the right answer to three decimal places. He needed to know: do we do this deal or not? And he already had the structural intuition to answer yes, as long as we positioned our capital correctly.

Where I got this wrong isn't the work. The work was good. Where I got it wrong is the sequencing.

The binary question should always come first. Before the model. Before the full dataset. Before the next meeting.

Given what we know right now, what's the plausible range of outcomes, and is there a structure under which the worst case is acceptable?

If yes, you ship a term sheet and refine it under live negotiation. The model follows.

If no, you save yourself two weeks.

When the Model Is Actually the Answer

I want to be honest about where this lesson stops.

There's another kind of deal where the 30-tab model is exactly the right tool. I'm in one right now. Every basis point matters. Advance rates, blended discounts, haircuts on the tougher part of the book. The entire value of the deal lives in the fourth and fifth decimals. Binary instinct doesn't help me here. The other side has better modelers than I do, and I will lose on math I didn't do.

Two different deals. Two different answers.

So the first question isn't whether you need a model. The first question is: is this deal going to be won on terms, or on basis points?

Terms deals (subordination, preferred return, fees, carve-outs) get you 90% of the answer from structural intuition. Structure eats model. Ship the term sheet, refine live.

Basis points deals (financing rates, discount curves, advance ratios) are the opposite. The model is the answer. Build it, pressure-test it, defend it line by line.

My mistake with the portfolio deal was treating a terms deal like a basis points deal. Two weeks of the wrong tool for the wrong question.

The Trap Is Worse Now

Here's the uncomfortable part for 2026.

The only thing that used to stop us from over-modeling was effort. Building 30 tabs took a week of real work. You'd hit the wall around tab 15 and start asking whether you needed the rest. Effort was the brake.

AI removed the brake.

I can generate a full sensitivity analysis in an afternoon. I can build a scenario toggle that would have taken three days in 2023. I can produce a binder of output my team couldn't have produced at all a year ago, faster than I can read it.

So the temptation to over-build is higher, not lower. And the discipline to ask the binary question first is more valuable, not less.

Every CFO I know is producing more analysis now than a year ago. Almost none of them are producing better decisions. The quality of the decision didn't scale with the volume of output. Why would it?

AI makes the model cheaper. It doesn't make the question better. You still have to pick the right one.

Three Questions I Ask on Every Deal Now

First question: is this a terms deal or a basis points deal? Terms means structure wins. Basis points means math wins. Picking the wrong lane is the expensive mistake.

Second question on any terms deal: if the numbers are broadly right, is there a structure under which we lose money? If there isn't, ship the term sheet and model in parallel.

Third question on every model I build: am I building this because the deal needs it, or because AI made it cheap? Cheap is not a reason to build. It's a reason to be more suspicious of what I build.

I still believe in thorough analysis. I'm not going to stop asking for the complete dataset or the net returns. But I'm going to stop making those questions the gate when the deal doesn't need them.

The deal closes when you send a piece of paper. Everything else is rehearsal.

What This Means for Your Finance Function

If you're the CFO or the head of FP&A at a mid-market company, the pattern I described probably looks familiar. Not because of deals specifically, but because of the broader dynamic: a team doing technically excellent work while the decision-maker is waiting for something simpler.

The CEO doesn't want less rigor. They want the right rigor at the right time. That distinction is harder to teach than any model-building skill, and most finance teams never make it explicit.

It starts with the question before the model. Before the dataset. Before the analysis.

What binary question does this person actually need answered? And what's the minimum structure required to answer it honestly?

Get that right, and the model becomes a tool instead of a habit.