Most product teams have never asked this question. My goodness, it’s an important one.

I've sat in a lot of product kickoffs over the years, and there's a pattern I've noticed that I find quietly fascinating and occasionally terrifying. At some point in the first few meetings, usually after the vision has been presented and the roadmap has been sketched out and everyone is nodding along with that particular energy that comes from being at the beginning of something, somebody will ask what the product actually does. And the answer will be some version of "it helps people do X more easily" or "it automates Y" or "it connects people who need Z." All of which sounds perfectly reasonable. 

But it's not really the question I'm interested in. The question I'm interested in is what kind of value is this thing creating, and for whom, and how, and whether the team has ever actually stopped to think about that before they started building.

Most product teams, if you pressed them, would say they're in the Transformation business. They take a problem, they build a solution, they turn something difficult or manual or slow into something easier and faster and better. That's what software feels like from the inside. You're making something. You're building. And that framing is so intuitive and so universal that it tends to go completely unexamined, which is where I think a lot of products quietly go wrong.

Because Transformation is just one type of value. And the teams that don't realise they're actually in the Trust business, or the Timing business, or the Translation business, tend to make decisions that make perfect sense for a Transformation product and are quietly catastrophic for the kind of product they're actually building.

I've been developing a framework over the past few years that I use to think about this, and the idea behind it is simple enough. All value, not just in digital products but anywhere, in any market, in any human exchange, comes from one of six places. I call them the six T's, and once you start seeing them it becomes quite difficult to look at a product, or a business, or a market without immediately asking which ones it's actually doing.

Transformation is the one everyone reaches for first, and for good reason. It's the most visible and intuitive kind of value creation. You take something raw and you rearrange it into something more useful. Wheat becomes bread. Iron becomes a knife. Code becomes software. A spreadsheet full of data becomes a dashboard that tells you something meaningful. Transformation is what most product teams picture when they picture themselves, and it's genuinely important, but it's also the one that gets used as a catch-all when teams haven't thought carefully enough about what they're actually doing.

Transportation is about moving something from where it has low value to where it has high value, and while it sounds like a logistics concept it's one of the most powerful forces in digital products. A fish on a boat is worth considerably less than that same fish on a dinner plate somewhere wonderful. Information locked inside one person's head or one company's database is worth considerably less than that same information in the hands of the person who needs it to make a decision. A lot of what we describe as "connecting people" or "democratising access" is really Transportation, and naming it as such changes how you think about what success looks like and where the friction lives.

Timing is delivering something when it's needed rather than when it isn't, and it's one of the most underestimated sources of value in digital product work. A warm coat in winter, a hospital bed in a crisis, an umbrella when it's raining. The object hasn't changed. The value has changed completely. I've seen products that were genuinely well-built and solving real problems fail not because of what they were but because of when they arrived in someone's workflow or life, either so early that the infrastructure to support them didn't exist yet, or so poorly timed in the context of a user's actual day that the friction of using them at the right moment was just too high. Timing failures are particularly painful because they're often invisible from inside the building. The product works. Nobody comes. And the team spends months iterating on the wrong things trying to figure out why.

Translation is identifying a use for something that wasn't previously recognised, or connecting buyers and sellers, or people with problems and people with solutions, who didn't know the other existed. Markets, search engines, matchmakers, and most platforms are doing Translation work. The value isn't in the thing itself, it's in making the previously hidden legible, in reducing the ignorance that was stopping two parties from finding each other. A lot of marketplace products fail because they're described and built as Transformation products when they're actually Translation products, and those two things need fundamentally different thinking about where the value lives and how it gets destroyed if you get the model wrong.

Trust is the one I find most interesting, and the one I think is most consistently undervalued in digital product conversations. Trust is the invisible infrastructure that makes cooperation possible at scale, the contracts and institutions and shared norms and expectations that mean you don't have to renegotiate everything from scratch every time you interact with someone or something. It's why you hand your credit card to a waiter without following them to the machine. It's why money works. It's why society, in a very real and underappreciated sense, works.

In digital products, Trust as a value type tends to be invisible until it breaks, which is exactly what makes it so dangerous to underestimate. You build it slowly, across many small interactions that all go exactly as expected, a button that does what it says, a form that behaves predictably, a system that handles your data with obvious care, and you can lose it completely in a single moment that makes someone wonder, even briefly, whether the thing they're trusting is actually trustworthy. A clunky Transformation product is irritating but a clunky Trust product is finished. The teams that understand which one they're building make completely different decisions about quality, about error states, about what "good enough to ship" actually means. The teams that don't tend to treat it like a Transformation product with a privacy policy attached, and then find themselves genuinely puzzled about why people aren't converting.

Transmission of Meaning is the last one, and in some ways the most profound. It's what artists and teachers and storytellers and philosophers do, changing how someone understands or experiences the world without changing a single physical thing in it. A great book doesn't move anything and a superb teacher doesn't build anything. But both can change what a person values, fears, notices, or believes for the rest of their life, and that is an extraordinary thing when you think about it. In digital products, Transmission of Meaning shows up in education platforms, in tools that help people make sense of complex information, in products whose real job is to change how someone thinks about something rather than to automate a task.

The reason I find the framework useful, and the reason I keep coming back to it at the beginning of projects, is not that every product fits neatly into one category, because they don't. Most interesting products are doing several of these things at once. It's that most teams have never had the conversation about which ones they're responsible for, and that gap tends to fill itself with assumptions that go unexamined until they become problems.

Before the wireframes, before the roadmap, before the first line of code, it's worth spending twenty minutes in a room asking a genuinely simple question. What kind of value are we actually creating here? The answer changes everything that comes after it, and the conversation is almost always worth having before you're far enough in that changing course feels expensive.

Most teams skip it. Most teams shouldn't.