Run the Same Math on Yours

I've told you twice to run the math on your own business and handed you nothing to run it with. Here's the instrument: six questions, in order, with what each answer means.

The homework I never handed out

Chuck ended last week's piece by pointing out that I've told you twice to run the math on your own business and handed you nothing to run it with. He's right. The closest I came was three weeks ago, when I closed with "go run the same math on yours before you copy our conclusion." An instruction with no instrument attached.

This is the instrument. Six questions, in a deliberate order, because each one decides how much the next one matters. You can run all six in an afternoon without hiring anyone, and most of them take minutes. Back in June I gave you a different diagnostic, one for finding where your business is actually breaking. This one assumes you already know the break and are deciding whether to own the fix or keep renting it.

One thing before you start. A useful instrument has to be able to tell you no.

If every question funnels you toward building your own layer, you're not holding a diagnostic, you're holding a pitch.

Plenty of businesses should run this and conclude they should keep renting nearly everything. That's a passing grade too.

Question one: count the logins

It's Monday morning and you want to know the state of your business. Cash, pipeline, delivery, who's working on what. Count how many systems you'd have to open to answer.

One place means you already have a connected layer, whatever you call it, and the later questions on this list matter more for you than this one does. Four or five logins plus a spreadsheet somebody maintains by hand means you're at the first stage with good intentions, and the spreadsheet is doing the layer's job one manual update at a time. If the real answer is that you'd ask three people and wait, write that down too.

That's still a login count. It's just measured in hours.

The trap answer is "we have a dashboard." Look at what the dashboard reads from. If it reads from one system, you have a nicer login. The question isn't whether you can see one thing clearly. It's whether anything in the building can see across.

Question two: write the paragraph

Pick the workflow you're most tempted to automate, buy for, or build for. Now write one paragraph stating what a system would be allowed to decide there without you, and what it would have to route to a person.

I keep returning to this because it's where the real gap almost always is. I've sat across from operators who could describe their product beautifully and couldn't produce this paragraph for a single workflow in their own building. If the paragraph comes easily, you're closer to governed autonomy than most, and every vendor conversation you have gets sharper, because you know exactly what you're asking any system to hold.

If you can't write it, stop shopping. Nothing you buy or build before this paragraph exists will survive contact with real work, because every system needs the boundary, and right now the boundary is you, undocumented. The encouraging part: writing it is an operator skill. It costs nothing to practice, and it transfers directly to job descriptions, scopes of work, and every delegation you'll ever hand someone.

The trap answer is writing down what the system does instead of what it may decide.

A feature list is not a boundary.

Question three: count backward from five

Whatever you're evaluating right now, ask whether it's the first thing you'd be building or the fifth thing on scaffolding that already exists.

Count what's underneath, and be strict about it. Context written down where a system could actually use it. A record of decisions that explains why things are the way they are. A working definition of done. Reusable patterns left over from the last build. If the count is zero, the thing in front of you is the first thing, and the first thing almost never pays, because it has to justify all the scaffolding by itself and one module never does. Rent it.

The math flips in two situations, and you need at least one. Either you can see five or six of these builds coming, close enough together that the shared scaffolding pays for itself across all of them. Or coordination is becoming the product itself, which was our situation and is very few businesses' situation. If neither applies, rent the point solution and put the energy into getting to one view of the business. I'd tell a client exactly that, so I'll tell you.

The trap answer is counting tools you've bought as scaffolding you've built.

Five subscriptions is the first stage five times over.

Question four: ask every vendor what you walk away with

You've seen this one. Ask what you're holding the day after you leave. Not whether you can leave. What you're holding.

Run it on the vendors you have no intention of leaving, because the point isn't the exit. It's the price of the exit, and that number quietly sits inside every renewal conversation you'll ever have, whether or not anyone says it out loud. Time the answer too. A firm that has thought about the line answers immediately, because they had to decide where it went in order to build anything. A slow answer is the finding.

And don't accept "you can export your data" as passing. An export is a box of parts. Ask what still runs the day after, what's readable, and what a team that wasn't in any of the meetings could operate without a discovery phase.

Question five: ask when the record was last written to

Chuck added this one last week when he ran our own exit test, and it's the question I'd most like to have thought of first. Whatever documented version of your systems exists, wherever it lives: when did it last change, and what forces it to change?

Possession turned out to be the easy half. We hold every record we've told you to hold, and some of them describe a system that has since grown a whole new surface.

A record nothing writes to is a snapshot, and snapshots age into fiction without anyone deciding to lie.

If your answer is "we documented everything during onboarding," then what you own is a photograph of your business as it looked at onboarding.

The trap answer is pointing at the wiki. Whether documentation exists was never in question. The question is what mechanism rewrites it when the running system changes, and if the mechanism is "someone remembers to," you already know how that ends.

Question six: name who fixes it when nobody is billing

This one only applies to what you own, and we flunked it in public last week, so I get to ask it with a straight face.

A vendor fixes your bug because you might leave. The day you own the system, that mechanism is gone, and what replaces it is whatever discipline you actually have rather than the discipline you believe you have.

So name it. The person, the ritual, the forcing function that picks up the defect that isn't blocking anyone this morning. When Chuck counted last week, we couldn't, which is how our own operating system was carrying a month-old bug while the things that blocked somebody's morning got fixed fast, one of them eleven minutes after it was filed.

If you can name the mechanism, you're ahead of us, and I'd like to hear what it is. If you can't, that isn't a reason to rent forever. It's a line item in the true cost of owning, the one nobody budgets for, and it belongs in the math from question three.

What your answers add up to

Not a score. Three shapes.

Most businesses land here: several logins, no paragraph, a first thing rather than a fifth. If that's you, this instrument just saved you a build you'd have regretted. Keep renting the point solutions, spend the next stretch getting to one view of the business and learning to write the paragraph, and rerun the six questions when something changes. That's the cheapest correct answer available, and there's no shame anywhere in it.

Some of you land differently: a connected layer already standing, paragraphs you can write today, several builds visibly coming. For you the math may really flip, and the place to start is the workflow whose paragraph you can already write. Not the most painful workflow. The best-defined one.

And everyone, whatever your shape, should run questions four through six anyway, because they price relationships you already have. Two of them apply to vendors you're happy with. The third applies the day you own anything at all.

What this instrument won't do

It won't find where your business is breaking. That's a different diagnostic, and I wrote it in June; if you're choosing between fixing a foundation and building something new, that decision comes first. It won't tell you whether a specific vendor is any good, only whether they've thought about the line. And it won't run itself, which I can say with some authority, because we scored well on our own exit test right up until Chuck ran it properly and came back with findings. A good score is a claim. Last week was what testing a claim looks like.

Land the plane

This piece closes a loop that opened in July. We promised a maturity model, honest economics, and the architecture underneath our own system. We delivered those, ran the stress test on ourselves, and now you have the instrument, which was the missing piece from the start: the model, the economics, the architecture, the audit, and the thing you can run on a Tuesday without us in the room.

So run it. Then tell me where you landed. Leave a comment, especially if an answer surprised you, and most of all if one of the six questions failed you, because where the instrument fails is the most useful thing you could send me. What comes back will shape what we write next.