From agency execution to product thinking

The question behind the question

There is a question every agency team asks at the start of every engagement: what does this client need?

It is the right question for the job. It keeps you focused. It stops you from building things nobody asked for. It makes you useful.

But it is also the question that, if you only ever ask it, will keep you executing for ever. Because what the client needs and what the pattern reveals are two different things. And the difference between them is, roughly, the difference between a services business and a product company.

In June 2021, TUXX is working through that distinction carefully. Not because client work is somehow lesser: client work is what keeps you honest about real constraints. But the question you ask shapes everything downstream: what you notice, what you build, what you write down, and what you do with it next time.

What agencies notice and what they miss

An agency working well notices a lot. You see how organisations actually make decisions, which is rarely how they describe making decisions. You see where a brief masks a deeper problem. You see the gap between what a stakeholder says they want and what their team is capable of absorbing. You see the tools that nobody uses and the workarounds that everyone relies on.

But agencies, by design, are oriented toward resolution. The goal is to deliver. The engagement ends, the handover happens, the relationship becomes ongoing retainer or concludes entirely. And the pattern, the observation that this is the third client in eighteen months with the same fractured workflow between sales and delivery, the same failure to operationalise their standards, the same collapse of momentum at handoff, gets filed away, noted perhaps in a retrospective, and then dissipates.

This is not negligence. It is the natural consequence of a model built around the client's success as the unit of measure. The agency's output is the deliverable. The deliverable is, by definition, specific.

The shift in question

A product company doing services work asks something slightly different. Not just "what does this client need?" but also: "what does this client's need reveal about the problem at a category level, and how do we make that pattern reusable?"

This is a harder question to hold whilst you are deep in an engagement. It requires a discipline of abstraction that sits alongside the concrete delivery work, not instead of it. You cannot ask it if you are under-resourced or overcommitted. You cannot ask it if your team lacks the mandate to act on what they find. And you cannot ask it honestly if the answers will never be used.

But when the question is genuinely held, when there is a product direction that the services work is meant to inform, the nature of what you are doing changes. You are no longer just solving the client's problem. You are solving the client's problem as a specimen of a broader class of problem. The solution is still delivered; the insight is banked.

This is the relationship between TUXX and Orbit. Client engagements surface friction. The friction reveals patterns. The patterns inform what Orbit should handle natively: what should be built once, properly, and made repeatable rather than re-solved project by project.

What a product company does with service work

The operational discipline here is specific. It is not about extracting client IP or treating engagements as raw material for your own roadmap in some exploitative sense. It is about maintaining a consistent research posture throughout client work.

The research posture looks like this: after every engagement, and at significant points during one, someone asks which parts of what we just did were genuinely bespoke to this client's situation, and which parts were actually the same problem we have seen before in a different coat. The bespoke parts stay bespoke: they are what the client paid for and what is rightfully theirs. The underlying pattern is abstracted, anonymised, and examined.

Over time, these patterns accumulate into a genuine thesis about the problem space. Not a slide deck about the problem space, but an actual, tested, empirically-grounded understanding of where friction lives and why. This is what makes product companies, eventually, capable of building things that people did not know they needed until they used them. The product company has been watching the friction for years before it wrote a single line of the product.

The different kinds of knowing

There is a kind of knowledge that client work gives you that no amount of desk research replicates. You know what it actually feels like to be mid-delivery when the process breaks down. You know the specific emotional quality of a handoff that nobody is confident about. You know the difference between a system that looks clean and a system that people trust.

This is embodied knowledge. It lives in the team. It is not easily written down, and it does not transfer well in a brief. It is why companies that have done serious services work for long enough often end up building better internal tools than companies that started from the product side: they have spent years understanding the operational texture of the problem, not just its surface features.

For Mustard Seed Group, this is not accidental. The portfolio is structured so that TUXX's services work is adjacent to Orbit's product development. The adjacency is the point. Not so that the two are indistinguishable, as they are clearly distinct in their commercial structure and their accountability, but so that the learning flows in both directions. Orbit informs what TUXX can offer clients; TUXX informs what Orbit needs to become.

The institutional question

There is a larger question lurking underneath all of this, which is about what kind of institution Mustard Seed Group is trying to become.

It is not a services business that happens to have some internal tools. It is not a venture fund that acquires and exits. It is not a startup studio churning out products and hoping something catches. It is, or is working toward being, something more like an institution that builds capability: in its own systems, in its products, and in the environments those products serve.

The transition from agency execution to product thinking is one step in that direction. It is not a clean step. The agency instinct, the drive toward the client's specific problem, the satisfaction of the clean delivery, the discipline of the brief, is genuinely valuable and does not disappear simply because you have added a product perspective alongside it. The two orientations have to coexist, which is uncomfortable, because they pull in different directions at the margin.

But the institutional bet is that the coexistence is productive. That doing real services work whilst building real products creates an organisation that is neither purely reactive nor purely speculative. One that is grounded in actual problems, moving toward systemic solutions.

The friction is the map

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

Repeated friction is a signal. It marks the places where teams lose momentum, where people abandon standards, where a better system would change the outcome in ways that the team themselves cannot fully articulate because they are too close to the daily experience of it.

If you notice that signal, extract it carefully, and build toward it rather than around it, the product you end up with has an honest foundation. It does not describe a problem it imagines people have. It addresses a problem it has watched people navigate, unsuccessfully, many times.

That is the shift. From executing what the client needs to understanding what the pattern demands. The client engagement remains the point of contact with reality. The product is what you build from what reality keeps showing you.

Both have to be true at once. That is the work.