Have a Product, Deliver Better

Catching up with a former IT consulting colleague, we both marveled at how good the decks used to be, how perfectly on-point — and wondered how we both ended up at this company. We also lamented how far the consulting industry has fallen.

She said there’s actually one platform that’s relatively decent to build on.

What she meant by “platform” was “product.”

For a lot of IT developers, vendors, and consulting firms, the truth is they don’t actually have a product. What they sell is man-days — every project gets built from zero.

Selling a project depends on people: a consultant’s eloquence and experience matter, showing up with a polished deck to paint a grand vision for the client matters. But the gap between a project’s complexity and the team’s actual delivery capability gets papered over by an excess of emotional persuasion — and it only gets exposed once the work actually starts.

Even once you have a “product,” you’re still fundamentally selling headcount. But life gets a little easier.

When you pitch a client, you’re not saying “trust our team, trust our brand” — you’re saying “here’s something we’ve already gotten running, look at what it can do.” A platform also draws a boundary around what can actually be delivered — it’s much harder to talk your way far beyond your real capability.

The whole commercial narrative ends up backed by something tangible. Clients can see it for themselves, which, relatively speaking, makes buy-in easier.

A product is essentially a framework — in every sense of the word: a commercial framework, a risk framework, a development (delivery) framework.

Once you have a framework, luck matters less. Capability can accumulate. Risk can be spotted ahead of time.

Of course, constrained by their DNA, plenty of IT service providers don’t have an “R&D” gene, and the “products” they end up building really aren’t very good.

So yeah — some division of labor is just written into the DNA.