The best researchers we have led wanted their work in customers' hands. Curiosity and rigor were never in tension with shipping for them; shipping was how they found out whether they were right. The organizations that get the most from advanced research are the ones that give it room to explore and a clear, respected path to product — with a customer name attached as early as possible.
The failure mode is not too little research
It is research with no forcing function, which produces publications, prototypes, and eventually a reorg. The pattern is familiar to anyone who has run an advanced-development group inside a product company. A team is set up to "look ahead." It is protected from the roadmap, which is the point. It produces interesting results and a steady stream of demos for the executive staff. Three years later a new CFO asks what shipped, the honest answer is nothing, and the group is dissolved — taking with it people who could have built the company's next product if anyone had asked them to.
The researchers were not the problem. The absence of a customer was.
Fund bold ideas; hold them to a customer
The alternative is not to shrink research into next quarter's feature list. That kills the thing you were trying to buy. The alternative is to give every research effort a customer — a real one, with a name, a problem, and an engineer who will try the result — as early as it can be found, and to make the researchers responsible for that relationship.
This does two things. It gives the work a forcing function: a date by which something must run in someone else's environment, which is the moment most ideas find out what they were missing. And it gives the researchers the feedback they actually want. Nobody with real curiosity is satisfied by a demo for the executive staff. They want to know whether it works in the wild.
A customer name attached to a research project is not a constraint on the idea. It is the fastest way to learn whether the idea is true.
How to run it
A few mechanics make the difference. Set a productization path before the work starts: which product, which release, which team receives it, and what "received" means. Put a product engineer in the research team from the beginning — not to manage it, but to be the person who will carry the result across, and who will tell the researchers early which shortcuts will not survive contact with the codebase. Review research against customer evidence, not against publication count. And be willing to kill work that cannot find a customer after a reasonable search; that is not a punishment, it is how the budget gets recycled into the ideas that can.
In organizations that run this way, the interesting thing happens: the researchers become the best product people in the company. They have seen the problem from further ahead than anyone else, and they have the discipline to carry a result through to a customer. The distinction between research and product stops being an organizational boundary and becomes a phase in the life of a good idea.
The test
Ask any research effort in your company two questions. Who is the customer? When will they try it? If the answers are "we'll find one" and "when it's ready," you are funding a hobby. Hobbies are fine; they are just not a strategy, and they should not be on the balance sheet as one.
Red Tomatoes Enterprises · Published · Updated