Technology, product and business are one decision, not three

Most organisations split a new product into three conversations. The business side decides what it should earn. The product side decides what it should do. The technology side decides how it should be built. Each conversation is competent. The result is often incoherent.

It is incoherent because the three questions are not independent. They are the same question asked from three angles, and the answers constrain each other in ways that only show up when you hold them together.

An example from the ordinary middle of a project

Take something as dull as pricing an AI feature. The business view is a monthly subscription, because that is what customers expect. The product view is generous usage, because the feature is only good when people use it freely. The technology view is a model that costs money on every call.

Put side by side, these are not three requirements. They are one tension: a flat price, unbounded usage and a variable cost cannot all be true at once. Something has to give — a usage cap, a tiered plan, a cheaper model for the common path, a different price shape entirely. That choice is simultaneously a business decision, a product decision and an architectural one. Made in three separate rooms, nobody makes it at all, and it arrives six months later as a margin problem.

What changes when it is one decision

When the same person, or the same small group, holds all three, a few things happen.

Constraints show up early. The cost of a model call is known on day one, so the product can be designed around it rather than discovering it on the invoice.

Scope gets cheaper. Half of what gets built in a split organisation is each side hedging against what the others might decide. Together, you can simply agree not to build it.

Trade-offs become explicit. "We will cap usage at this tier" is a sentence someone has to say out loud and defend. In a split model it is nobody's sentence, so it never gets said.

This is not an argument for generalists

It would be easy to read this as "hire people who can do everything". That is not the point. Deep specialists are essential; a system is only as good as its weakest serious component.

The point is that someone has to own the joins. The places where the pricing model meets the data model, where the user flow meets the infrastructure bill, where a sales promise meets a performance budget. Those joins are where products quietly fail, and they belong to no specialist by default.

The practical version

Before a project starts, I try to write three short paragraphs on one page: what it must earn, what it must do, and what it will cost to run. Then I read them against each other and look for the sentence in one that contradicts a sentence in another.

There is almost always one. Finding it before any code exists is the cheapest thing a project will ever do.