Tools, research and taste

Three things that are not the same

There is a version of this year-end note that lists everything we tried, everything we shipped and everything we learned. That version would be tidier. It would also be wrong, in the sense that it would present the year as a sequence when it was actually more like a set of pressures operating simultaneously.

The three pressures: tools, research and taste.

They are not the same thing. They are not interchangeable. And one of the quieter lessons from 2018 is that conflating them, treating good tools as a substitute for taste, or treating research as a substitute for direction, produces work that is technically accomplished and intellectually hollow.

So instead of a list, this note tries to work through what each one actually is, and what the relationship between them should be.

---

What tools actually do

A tool does not make you more intelligent. It changes the cost of a task.

This sounds like a small distinction, but it is not. When the cost of writing a first draft drops, you do not necessarily produce better writing. You produce more writing, faster. Whether that surplus is useful depends on what you do with it, which depends on something the tool cannot supply.

The same is true for every category of tool that became more prominent in 2018. Faster search does not produce better research questions. Better prototyping tools do not produce better product intuition. Code generation does not produce better architecture. In each case the tool accelerates the output of a process; it does not improve the quality of the judgement directing that process.

This is not a criticism of tools. Tools are genuinely important. A group that operates with inferior tools against a group with better ones will lose over time, not because the tools themselves are decisive, but because the friction compounds. Bad tools waste attention. Attention is finite. A person spending thirty minutes on a task that should take three is a person spending thirty minutes not thinking about something more important.

So tools matter. But they matter instrumentally, not intrinsically. The question is always: in service of what?

There is a particular failure mode worth naming. As the quality and variety of tools improves, it becomes tempting to treat tool-acquisition as a form of progress. Adding a new tool to the workflow feels productive. It has the texture of improvement. But a team that collects tools without the capacity to direct them is simply a team with a more elaborate way of producing the same mediocre output faster. The tool did not help. It helped them fail more efficiently.

The right relationship to a tool is provisional and specific. You adopt it when it reduces friction on something you are already trying to do well. You retire it when the task changes or a better option emerges. You do not let the tool define what you are trying to do.

---

What research is actually for

Research is not a source of answers. It is a method for building better questions.

This sounds like a platitude but it is not, because a large amount of activity that gets called research is actually answer-seeking dressed in the language of inquiry. Someone has a position; they survey the literature until they find confirmation; they cite the confirmation. That is not research. That is rhetoric with citations.

Real research changes what you think is worth asking. You go in with a question, encounter something unexpected, and come out with a different question. The new question is usually more useful than the old one. That productive disorientation is how research actually works.

For a group like MSG, operating across multiple product surfaces, research has a specific practical value: it surfaces constraints and possibilities that the team would not find by working inside the product alone. You cannot reason your way to what you have not yet encountered. External input, technical literature, adjacent industries, cultural patterns, behavioural data, gives you the raw material that internal reasoning cannot.

But research without taste produces novelty. You find interesting things. You accumulate interesting things. You develop strong opinions about interesting things. None of this is the same as knowing what to do next.

Novelty is not inherently useful. Most things are interesting if you look at them long enough. The ability to find things interesting is not a competitive advantage. The ability to identify which interesting things are actionable, and in what order, and for which audience: that is a competitive advantage. That ability is taste.

There is also a timing dimension to this that is easy to underestimate. Research that arrives too early becomes background noise: you are not yet equipped to use it. Research that arrives too late is merely confirmatory: you have already committed. The value of a research function is not only in what it finds but in its alignment with when the organisation is actually in a position to act on what it finds. Getting that timing right requires knowing the product deeply, not just the literature.

---

What taste is, and why it is uncomfortable

Taste is harder to talk about than tools or research because it feels subjective in a way that makes people uncomfortable. It sounds like aesthetics. It sounds like preference. It sounds like something you either have or don't have, which makes it seem both unearnable and unjustifiable.

That characterisation is wrong.

Taste is a trained capacity for discrimination. It is built from a sustained combination of broad exposure and specific practice: seeing a lot of things, making a lot of things, noticing what works and what doesn't, and developing a reliable internal signal about quality that accumulates over time. It is not inherited. It is not fixed. It degrades without exercise.

What taste actually does, practically, is allow you to make decisions faster and better in the absence of complete information. Which is to say: always. Every product decision, every research direction, every investment of attention happens under uncertainty. Data helps. Research helps. But data and research rarely converge neatly on a single answer. The decision is made by someone who has to weigh partial evidence. Taste is the capacity for weighing it well.

Style without research produces something aesthetically consistent but blind to the world. It loops on itself. The vocabulary is refined but the meaning is thin. You can tell when you are looking at it: there is surface clarity with no depth underneath. Things look right but feel arbitrary.

Research without taste produces the opposite problem: depth without direction. You know a great deal about many things. You can outline the complexity accurately. You cannot tell what to do with it.

The combination, taste informed by research, is what makes leverage possible. You know enough to see the constraints. You have enough discrimination to identify what matters inside those constraints. You can act with the clarity of someone who has earned the right to their position.

The discomfort with the word taste is, in part, a cultural reflex. Technical teams in particular tend to treat it with suspicion: it is not measurable, not transferable, not derivable from a process. But the things that cannot be process-ised are usually the things that actually differentiate. If a judgement can be fully automated it will eventually be automated by someone. The non-automatable thing, the accumulated capacity for discrimination, is precisely what holds its value.

---

How MSG tries to hold all three

The honest version of this is that we do not always hold all three at once. Sometimes the tools are pulling ahead of the taste. Sometimes the research is accumulating faster than the direction can absorb it. Sometimes we make good aesthetic calls on surfaces we have not thought through carefully enough.

The structure of the group is designed to make these misalignments visible rather than invisible.

Benediction Lab is the research function. Its job is to push the frontier inward: to understand what is actually possible before the product teams commit to what they think is possible. Good research at that level prevents the mistake of building confidently toward a ceiling that has already moved.

TUXX is the proving function. Custom systems work, deployed in real conditions, forces a confrontation with the difference between what sounds right and what works. Taste that has never been pressure-tested is not really taste yet. TUXX applies the pressure.

Orbit is where the tool question becomes concrete. Building a coherent operating surface for commercial work means making thousands of small decisions about what goes where and why. The quality of those decisions over time is a direct expression of the taste underlying the product. You can see it, or you can see the absence of it.

The common thread is that all three depend on the feedback loop being real. Research that never reaches the product is inert. Tools that never get used under real conditions don't develop the team's capacity. Taste that never gets tested against outcomes calcifies into preference.

That last distinction matters. Preference is taste that has gone unchallenged long enough to mistake itself for truth. It defends itself. It resists input. Real taste, by contrast, is constitutively open: it is always provisional, always asking whether the current call is actually the best one or simply the familiar one.

---

The year-end position

Ending 2018, the honest assessment is this: the tools are better than they were. The research posture is sharper: more systematic about what questions we are actually trying to answer. The taste question is the live one, because taste is always the live one. It is the thing you cannot automate, cannot outsource and cannot fake for long.

The tools will keep improving. The research base will keep expanding. But the capacity to decide what matters, in what order, for whom, and why: that one has to be built continuously. There is no version of it that is finished.

That is the work going into next year.