Product surfaces for repeatable delivery

The useful product question right now

The useful product question in March 2021 is not "what can we build?" It is "where is the friction repeating?"

Repeated friction is a signal. It tells us where teams lose momentum, where people abandon standards, and where a better system would change the outcome. One-off friction is noise. Recurring friction is a specification.

This distinction matters more than it sounds. Most teams solve recurring problems the same way they solve one-off problems: by handling the instance, not the pattern. A client needs a proposal, so someone writes a proposal. A project needs a status update, so someone writes a status update. A handoff goes wrong, so someone patches the handoff. Each fix is local. Each fix disappears from memory before it can be institutionalised. The next cycle starts from the same place the previous one started.

This is ad hoc delivery. It works, roughly, until scale or speed exposes it.

Why ad hoc delivery is the default

Ad hoc delivery is not laziness. It is the rational response to how most service and product work is structured.

When every client engagement is treated as novel, and there is genuine pride in treating it that way, the incentive is to demonstrate custom thinking rather than to build reusable systems. Custom thinking is visible. It signals craft, attention, care. Reusable systems look like shortcuts, even when they produce better outcomes. The optics work against the right answer.

The result is that expertise accumulates in people rather than in systems. Senior people carry the patterns in their heads. Junior people learn by proximity. When senior people are busy, output quality drops. When senior people leave, the patterns leave with them. The business has not actually built anything durable: it has built a dependency on a small number of capable individuals performing the same work repeatedly from memory.

This is a systemic fragility dressed up as a quality standard.

What a product surface does differently

A product surface changes what the person sees when they are doing the work.

This is the most direct way to think about it. In ad hoc delivery, the person looks at a blank document and decides what to do. In system-led delivery, the person looks at a structured surface, a view, a form, a guided workflow, and the system has already decided what is relevant. The options are constrained to the ones that matter. The defaults reflect accumulated knowledge. The prompts are specific rather than open-ended.

The shift is not from human to machine. The person is still doing the thinking. The shift is from the person carrying the entire operating model in their head to the system carrying the structural knowledge so the person can focus on judgement.

This is what separates a product from a document template. A template provides structure at the start, then recedes. A product surface stays present throughout the work. It holds state. It enforces sequencing when sequencing matters. It makes certain failures harder to make, not by blocking the user, but by making the right path the most obvious path.

The question TUXX is testing

This is where TUXX sits in the MSG portfolio. The services arm exists precisely because services keep the work grounded in real operating constraints. You cannot theorise your way to a good product surface. You have to watch where people actually lose time, where they substitute their own judgement for a standard that should already exist, and where work has to be undone because the wrong thing was built first.

TUXX work in early 2021 is testing a specific set of questions around delivery. What does the person need to see at each stage of a project? What information should already be present versus what should be prompted for? When should the system enforce a sequence and when should it get out of the way?

These questions sound operational. They are actually product questions. The answers feed into what Orbit is being built to do: turning commercial execution into an operating surface rather than a set of individual transactions.

The difference between patterns and products

Recognising a pattern is not the same as productising it. This distinction is worth sitting with because it is where most systems fail to close the loop.

A pattern is the observation that the same steps work repeatedly across different projects. A product surface is the mechanism that makes those steps available to someone who did not discover them. The gap between pattern and product is the gap between knowledge that lives in one person's experience and knowledge that the system can serve to anyone who needs it.

Most organisations stop at the pattern stage. They document it: a process document, a playbook, a knowledge base article. Documentation is better than nothing, but documentation requires the person to find it, read it, interpret it, and then apply it under pressure. The failure rate of documentation-led standards is high precisely because it asks people to do all of that while they are already in the middle of the work.

A product surface collapses those steps. The person is already in the system. The relevant standard is already visible. The pattern has been embedded into the interface rather than filed somewhere nearby.

What the operating surface question actually asks

The most honest version of the surface design question is this: when a person sits down to deliver a project, what should they see?

Not "what information should be available to them?" That is a data question. Not "what steps should they follow?" That is a process question. The surface design question is about what is present and what is absent at the moment of doing the work.

Getting this right requires understanding both the work and the worker. It requires knowing which decisions genuinely require fresh judgement versus which decisions are already known and just need to be surfaced. It requires understanding where people slow down because they are thinking carefully versus where they slow down because they are uncertain about what is expected. These feel similar from the outside. They require completely different responses from a product.

The tendency in early system design is to surface everything, to give people maximum information and let them make sense of it. This is usually wrong. More information at the wrong moment adds cognitive load without adding capability. The product's job is to filter. The surface should show what is relevant now, not what might be relevant eventually.

The portfolio logic

The more capable tools become, and the trajectory in early 2021 is pointing clearly in one direction, the more important the surrounding product becomes. A capable model can generate output. A well-designed product surface decides what output is needed, when, and in what form. The intelligence of the tool does not reduce the importance of the surface; it raises the stakes for getting the surface right.

This is a consistent thread across MSG's portfolio logic. Orbit is building the operating surface for commercial execution: not a better CRM, not a project tracker, but the place where the full workflow from lead to launched product becomes navigable. Orion is the intelligence layer that makes that surface more responsive to what is actually happening in the work. TUXX tests the real constraints so the surface reflects real delivery patterns rather than idealised ones.

The services arm is not a revenue line that funds product development. It is an epistemological requirement. You cannot design a surface for delivery work without having done enough delivery work to know where the surface fails. That knowledge cannot be acquired second-hand. It has to be earned in real projects with real constraints.

The repeating signal

Build the product where the pain repeats. Use AI where it genuinely improves the operating loop. Keep the system understandable enough for people to trust it.

Three constraints. None of them complicated. All of them easy to violate.

The first constraint keeps scope honest. Not every friction point is a product opportunity. The threshold for building a surface is that the same problem is occurring regularly enough that the cost of building the surface is less than the cumulative cost of handling each instance individually. If you are solving a problem that occurs once a year, you do not need a product. You need a good document.

The second constraint keeps the AI application grounded. The question is not "where can AI help?" The question is "where does AI improve the operating loop in a way that is measurable and reliable enough to depend on?" Capability is not the same as fit. The most impressive model doing the wrong job in the wrong part of the workflow makes the system worse, not better.

The third constraint is the hardest to honour, because it pulls against the natural tendency of systems to accumulate complexity. A surface people cannot understand is a surface people will not use. Trust is not a feature. It is the condition under which all the other features become useful. A system that is technically sophisticated but operationally opaque will be abandoned in favour of whatever people were doing before, even if what they were doing before was worse.

The useful product question is not "what can we build?" It is "where is the friction repeating, and what is the minimum surface that makes the repeating pattern available to anyone who needs it?"

That question does not have a final answer. It has a series of answers, each one a little closer to the right surface, accumulated over time by people who stayed close enough to the work to know when the current surface is failing.

That is the work. That is the whole work.