The first guess is supposed to be wrong

A pile of disconnected projects that happen to bring in cash isn’t a business. But from the inside of an organization, the two look almost identical. Every project has a customer attached, every project generates an invoice, and everyone on the team looks exhausted.

I spent a stretch working alongside an enterprise software division that was built exactly this way. It was a factory for tiny software products. Every two weeks, I’d uncover another one hiding in the portfolio: a spreadsheet somebody had maintained for a year that got turned into a standalone web app, a one-off feature hacked together for a single client that sales was now tasked with selling to the market, or an internal operations script that someone decided was enterprise-ready.

Each one arrived with its own repository, its own database, its own deployment pipeline, and its own customer support headaches. There were eight or ten of these micro-products scattered across the business. The company had the engineering bandwidth to properly support two.

Software only generates attractive unit economics one way: you build the machine once, and you sell it many times so the cost of serving the next customer rounds down toward zero. With single-tenant bespoke tools, the math completely inverts.

Say one of these bespoke applications brings in $50,000 in annual recurring revenue, but keeping it alive burns 400 engineering hours a year. That’s security patches, dependency updates, broken APIs, and custom integrations when a client changes their internal systems. At a hundred dollars an hour, that’s $40,000 in engineering overhead just to defend $50,000 of top-line revenue. Now multiply that across eight products. You’re burning thirty-two hundred hours a year, which is more than an engineer and a half doing nothing but keeping yesterday’s experiments on life support. Those tiny apps add up to a massive operational drain.

So why on earth would anyone build the next one?

My initial theory was simple: the guy running the division was a tinkerer who loved building things. He had an engineering budget, a development team, and zero commercial supervision. From the outside, it looked like a classic case of somebody screwing around with corporate capital to build pet projects. A few executives I interviewed quietly shared the exact same suspicion.

It was a tidy, convenient explanation. It was also completely dead wrong. I had reduced an organizational breakdown to a personal character flaw, which is the laziest mistake a diagnostician can make.

When the disagreement is the data

So I kept digging. Who owns this specific codebase? Where did that tool originate? Why did an Excel sheet suddenly become a SaaS offering, and is anyone actively selling it?

When you interview five different executives and hear five conflicting accounts of the same historical event, the conflict itself is the signal. You aren’t hunting for consensus. You’re hunting for the structural reason the stories diverge.

Eventually, I sat down with a veteran who had been with the company for a decade and understood its unwritten history. As it turned out, the leader running that division hadn’t gone rogue at all. Three years earlier, during an executive offsite, a senior board member had explicitly commanded him to “go make money with software.”

That was the entire mandate. Which was wild, in hindsight. He was doing exactly what he had been told to do.

That single piece of context changed the meaning of every fact on the ground. That’s the moment of coherence you’re actually aiming for in a diagnostic. You aren’t looking for sterile certainty. You’re looking for the missing variable that makes everything else click into place.

The first guess isn’t the diagnosis

There’s a comfortable corporate myth that good strategic judgment means withholding all opinions until every scrap of data has been collected and analyzed. In a real operating company, that mindset leaves you dead in the water for six months. You will never have perfect information. Financials tell one story, the CRM tells another, and the most critical decisions were made verbally in hallways by executives who left two years ago.

The real discipline is forming a working hypothesis almost immediately, and holding it loosely.

The closest mental model I have for this is gradient descent in machine learning. You don’t need to see the bottom of the valley before you take a step. You take a step in the direction that looks steepest, measure what changed, adjust your vector, and step again. You form an explanation on day one, and then spend day two aggressively trying to kill it.

Take that division leader: if he was building pet projects purely for his own amusement, I should have found tools clustering around his specific technical hobbies, with no customer contracts anywhere near them. When I went looking for that evidence, it didn’t exist. The hypothesis died, and the investigation moved forward.

When rational people look crazy

As an intentional portfolio strategy, what that division was doing was completely indefensible. But seen through the eyes of an operator who had been handed a vague board mandate to monetize software, it was the only rational path available. Leave human incentives out of your analysis, and rational behavior will always look like pure nonsense.

That changes the entire remediation plan. If my initial theory had been right, the fix was strict governance: put an approval committee in place to police what he was allowed to build.

The real question sat an entire floor higher: what was this software unit actually supposed to be? Was it an independent venture incubator? Was it a product studio spinning out standalone businesses? Or did it exist purely to make the core consulting business more defensible?

Those are three completely different corporate strategies requiring three completely different capital allocations. Nobody had ever written down which one the company was pursuing. So the operators filled in the vacuum themselves, doing their best with the last clear instruction they had received.

AI and the local minimum trap

Gradient descent has a well-known vulnerability: you can easily get trapped in a local minimum. You follow the slope downhill, arrive at an answer that neatly fits the facts right in front of you, and declare victory while missing the real truth a hundred yards away. If you only interview sales reps, the sales explanation becomes completely convincing by Thursday afternoon.

Modern AI makes falling into local minimums dangerously easy. Feed a model a collection of meeting notes and financial reports, and it will construct a beautifully reasoned, persuasive narrative that feels like magic. But the model can’t interview the disgruntled engineer who wasn’t invited to the meeting, and it has no access to the verbal hallway agreement made in 2022.

To avoid the trap, you have to break the pattern. You interview the junior analyst everyone takes for granted. You look at the invoice nobody wanted to pull. And you constantly ask what would make this apparently insane operating behavior completely logical.

The real advantage of seasoned operators isn’t that they have better initial answers. It’s that they have better initial guesses, and they’ve been wrong enough times in their careers that abandoning a dead-end thesis doesn’t hurt their pride.

Your first guess is supposed to be wrong. Its only job is to get you moving.