What research commercialisation taught me about product

Before I owned a platform in a bank, I owned backlogs at Viclink, the research commercialisation company of Victoria University of Wellington. It is now called Wellington UniVentures. Its job is to take what researchers discover and turn it into products, services and new businesses that people outside the university will use.

My job sat in the middle. I worked with researchers on one side and the commercial team on the other, turned what they agreed into requirements and user stories, and built and tested the software that took an early idea to a working version.

I did not think of it as product work at the time. Looking back, it was where I learned most of what I now rely on.

A result is not a product

A research result answers the question "does this work?" A product has to answer a different set of questions: who will use it, why they would choose it over what they do today, whether it can be built and supported, and whether anyone can make it pay.

Marty Cagan calls these value, usability, feasibility and viability risk. In a university setting, the research has usually retired a large part of one of them. Something works in a lab or on a dataset. The other three are still wide open, and they are the ones that decide whether the idea ever leaves the building.

That gap is easy to miss, because the research result is real and impressive. It is also only the first of several things that have to be true.

Two rooms, one backlog

Researchers and a commercial team are both right, and they are measuring different things. A researcher cares whether the method is sound and the claim is honest. A commercial lead cares whether a buyer will recognise the problem and pay to have it solved.

Neither of them is wrong, and neither can write the backlog alone. The researcher's version of the product is often the full capability. The commercial version is often a promise that is ahead of what has been built.

The backlog is where those two views meet. Writing a user story forces a choice: which user, which problem, which first version. Each story is a small translation from what the research can do to what someone outside will actually use. I have written about that translation in a separate essay, and this is where I first did it.

A working version is the start of the conversation

Building and testing the early versions myself taught me something I still see in large organisations. A working version changes the conversation more than any document does. People who could not agree on a description of the product can react to a thing on a screen in minutes.

It also creates a trap. Once something works, everyone assumes it is nearly finished. It rarely is. Supporting it, securing it, handing it to people who did not build it and making it part of how an organisation works is most of the remaining effort. I made the same argument later about proofs of concept inside a bank. I learned it first in a university.

Choosing what not to build

A university has far more promising ideas than it can take to market. That makes the most valuable product decision the one about what to stop. An idea can be clever and still have no buyer, no route to support it, or no one outside the lab who needs it badly enough to change what they do.

Saying that clearly, and early, is kinder to the researcher than letting the idea drift. It is also the discipline that separates a product backlog from a wish list.

The same work at a different scale

Today I own the route a machine learning model takes from experiment to a governed production service in a regulated bank. The setting is different. The shape of the work is not.

A data science result is a research result. The control functions, engineering teams and business owners are the commercial team, each measuring something different and each right. The job is still to turn a result that works into something an organisation can adopt, and to be honest early about which ideas will not make it.

The idea is never the product. The product is the idea, plus everything that has to be true for someone else to rely on it.

References

• Wellington UniVentures, "About us". The company's own description of its work: shaping university research into initiatives with impact, and connecting researchers with partners, industry and investors
• Wellington UniVentures, "Introducing Wellington UniVentures". 2020. The announcement of the change of name from Viclink
• Marty Cagan, "The Four Big Risks". SVPG, 2017. Value, usability, feasibility and business viability risk, the frame used above for why a research result is only part of a product