Product ideas as research outputs

The gap nobody names

There is a standard complaint about research: that it sits on a shelf. Papers are published, reports circulate within institutions, findings get cited in grant applications. Very little of it reaches anything a person actually uses. The critique is fair but it misidentifies the problem. The issue is not that research is inert. The issue is that most people who read it do not know how to read it as a source of product imagination.

This is a different skill from reading it for factual content. And it is a skill worth developing deliberately, because the public research literature in artificial intelligence and human cognition is, right now, one of the most underused product development resources available.

What research actually contains

A research paper contains at least three things, not all of them obvious.

The first is the stated finding: the result the authors set out to prove. This is usually the part everyone reads and the part that travels furthest. A model achieves a new benchmark score. A cognitive study shows that humans rely on a particular heuristic. A systems paper demonstrates that a specific architectural choice improves latency. These findings are useful, but they are the surface.

The second thing a paper contains is the framing of the problem. Researchers choose what to measure because they believe that measurement reveals something important about the world. The choice of measurement is itself a theory of what matters. When a research team decides to study how people update beliefs in the presence of conflicting information, they have already made a product-relevant argument: that belief updating under conflict is an important and tractable problem. The choice of problem is sometimes more useful than the finding.

The third thing, and the one most relevant here, is the implicit picture of a human struggling with something. Most research in AI and cognition involves people doing tasks in conditions that reveal the shape of difficulty. Where do they slow down? Where do they make errors? Where does their attention drift? Those moments of difficulty are exactly where a product should be doing work. The research has mapped the terrain of struggle. The question is whether you can read that map and build something that changes the experience of traversing it.

The translation problem

Reading research as a product person is a translation exercise, and the error most people make is translating too literally.

A paper demonstrates that a neural network can summarise documents with reasonable accuracy. The literal translation is: build a summarisation tool. Add a text box. Add a button. Return a summary. Ship it.

This is almost always wrong. Not because summarisation is not useful, but because the research finding is an existence proof, showing that something is possible, not a specification for how it should be experienced. The gap between "this can be done" and "this is valuable in use" is where most product work actually lives.

The better translation asks a different question: given that summarisation is now tractable, which human struggle does it resolve, and what does that resolution make possible next? The answer to that question is rarely a summary box. It is more often a change in pacing, or scope, or confidence: something that allows a person to do something they could not justify doing before, because the cost of a particular cognitive step has dropped.

This is not a subtle distinction. It is the difference between copying the interface of research and reading research for its implications.

August 2017 and the state of the field

The public research environment in mid-2017 is producing findings at a rate that was not the norm five years ago. The previous twelve months alone have introduced substantial work on sequence-to-sequence learning, reinforcement learning from human feedback, and multi-task transfer across language domains. The Transformer architecture, introduced in a paper published this summer, is still settling into the community's understanding. The full weight of what it makes possible will become apparent slowly.

For a product organisation, this rate of publication creates both an opportunity and a noise problem. The opportunity is genuine: architectural advances that reduce the cost of language tasks, retrieval, and planning have direct product implications. The noise problem is that not every advance translates into something a real person would use differently tomorrow. Knowing which findings to take seriously, and how to take them seriously, requires a reading practice, not just an alertness to new results.

What that reading practice looks like, practically:

The first step is to read the introduction and the related work sections rather than jumping to the results. These sections reveal what the research community thinks the hard problems are, and why the authors believed this particular approach was worth pursuing. That context is often more useful than the experimental outcome.

The second step is to read the failure modes. Limitations sections in research papers are frequently honest in ways that discussion sections are not. They tell you where the approach breaks, which is exactly where a product designer needs to pay attention.

The third step, and the most productive, is to sit with the research for a day and ask what a person would have to believe about the world for this finding to matter to them. That belief is often the key to a product frame.

Benediction Lab

This kind of reading practice is something we want to institutionalise rather than leave to individual inclination.

Benediction Lab is the research layer of MSG, not a pure academic function and not a product team, but the space that sits between them. Its job is precisely this translation work: reading research carefully, understanding what the field is actually building toward, and converting that understanding into product imagination that can be handed to the teams building Orbit, Orion, and the All Purpose ecosystem.

The Lab is not trying to replicate what academic research institutions do. Those institutions are excellent at what they do. What they are not optimised for is the specific translation task: reading the field's findings as a map of human difficulty and then asking what a real product, used by real people in real conditions, would do with that map.

That translation task is almost always unoccupied. Research teams do not have time for it. Product teams do not have the training for it. Benediction Lab is an attempt to make that gap into a function with a home.

At this stage, the Lab's work is primarily reading and thinking rather than publishing or building. The building will come. But the discipline of reading the research field carefully, without the pressure to immediately ship and without the temptation to copy the surface of findings, is the foundation on which everything else sits.

The paper-to-product distance

There is a natural length to the journey from a research result to a product expression of it.

The distance is not as long as pure researchers tend to assume, nor as short as people in technology marketing tend to claim. A finding published this summer does not become a feature next month. But it can become a frame for understanding a user problem this quarter, and that frame can inform a design decision in six months, and that design decision can become something someone relies on by the end of next year.

The implication is that reading research is not a reactive activity, reading a paper to see whether it unlocks something you are already building. It is a forward-looking one. You are reading to understand what kinds of problems will become tractable, so that you can be oriented correctly when tractability arrives.

This also means that the value of the reading practice compounds. A team that has been reading AI research seriously for two years understands the problem space with a texture that a team that just started cannot quickly acquire. The understanding of what has been tried, what has failed, what assumptions the field is currently making and where those assumptions are weak. That understanding is itself a form of capability.

We want MSG to have that capability. Not as a competitive advantage in a narrow sense, but as a condition for building things that are genuinely worth building.

What this changes about product thinking

If research is genuinely a source of product ideas, not in the cheap sense of "AI paper suggests feature" but in the deeper sense of "research maps human difficulty and we can read that map", then product thinking changes in a specific way.

It becomes more patient. The question shifts from "what can we build this quarter" to "what is the shape of the problem we are trying to solve, and how is our understanding of it changing as the field produces new results."

It becomes more interested in mechanism than interface. What a product does matters more than how it looks, because what it does is grounded in an understanding of where and how people struggle. The interface can follow from that understanding rather than preceding it.

And it becomes more honest about what is actually hard. Research papers are, among other things, records of difficulty: of things that did not work before a particular insight, of limitations that still hold. Reading them carefully produces a kind of intellectual humility about product claims that is genuinely useful. It is much harder to over-promise a capability when you have read the failure modes in detail.

This is the orientation we are trying to cultivate, inside Benediction Lab as a function and across MSG as a practice.