Thank you for getting in touch, we'll get back to you soon!

Do you have some insights to share with the product community?

GET IN TOUCH.

Academia rewards novelty. Industry rewards process. The best work needs both.

Written by
Samuel Munday Samuel Munday
Co Founder at Data Revival
Published
Share

We beat the state of the art by twenty-five points. The question was then posed; is this the finish line or have we just started?

The result was >90% accuracy on automatically extracting chemical knowledge from research papers. Expert human curators with PhDs managed less than 70% on the same documents. In the academic world I'd come up in, that's the kind of number that ends a piece of work. Peer-reviewed, defensible, clean.

However, the first user I showed it to didn't see a finish line. She was a chemist at a pharma company. She nodded politely and asked me about the remaining 10%? What are the failure modes? How will she spot them? What does she do when that happens? She wasn't being difficult. She was running the same number through a completely different filter.

“Academia rewards novelty. Industry rewards process. The best work needs both.”

Samuel Munday, Co-Founder @ Data Revival

That filter is the gap I think about most as I run Data Revival, our University of Southampton spin-out building tools to extract and make digital chemical knowledge from the worlds vast repositories of scientific information. It's also, I've come to believe, the gap the most consequential companies operating right now are quietly bridging.

Two sets of metrics. Two ways of thinking.

Academia and industry both run on outputs.

In academia, what's measured is novelty. The strength of an argument. The contribution to a field. The proof that something new can be said. The process behind the result matters less than the result itself; a messy experiment producing a clean, defensible paper is still a clean, defensible paper. The output is what gets cited.

In industry, the metrics flip. The output gets you in the room. The process is what keeps you there. Customers don't pay for results that hold under clean conditions and a fair wind. They pay for results they can trust on their data, inside their workflow, under the awkward operational constraints they live with every day. Reliability, reproducibility, security, integration. None of these mattered for the paper. All of them matter for the product.

Neither set of metrics is wrong. They do however indicate two different ways of thinking. In academia, what you're assessed on is how novel your approach is. In industry, you're assessed on how much value you've actually added. The skill that wins a peer reviewer isn't the skill that wins a contract renewal, something founders coming out of the research environment need to learn fast.

What happens when a lab result meets production

You see the gap most clearly the first time a lab-validated result is measured against the needs of a production environment.

There are many drugs that can kill cancer cells in the lab. The question is, what other harmful effects will they have in the body? A model that hits >90% accuracy on a clean benchmark might collapse in the messy reality of the production environement. Or maybe it doesn’t but then are we sure it’s fast at the volume a customer needs, or that it doesn’t violate the n data-handling rules the customer must comply with and so on. The science is, by its own metrics, correct. The product may fail anyway.

This isn't a failure of the underlying work. It's a reminder that the evaluation set changes. User experience matters now, and academic software has, historically, been almost aggressively user-hostile. Security matters. Integration matters. Trust matters. So do the questions nobody had to answer for the paper to be accepted: what happens at a hundred times the volume, what your recourse is when the model is wrong, who picks up the support call.

The mistake I am most wary of us committing is to treat this as a sequencing problem. The science is done, now we do the engineering. It isn't a sequencing problem. The science answered one question well. The product answers a different question, and answering it well is a body of work of its own scale, with its own instincts and its own metrics. Treating one as the easy follow-on to the other is how you ship something that only works inside the conditions you built it for.

The companies doing the most consequential work haven't picked a side

This is what the best companies operating right now seem to understand better than the rest.

The frontier AI labs look, from the outside, like research institutions wearing startup hats. They publish papers. They send people to conferences. They hire off academic faculty. They run reading groups on Friday afternoons. They also ship at extraordinary commercial scale. The pace is enormous, the revenue is enormous, the pressure to convert intelligence into product is enormous. None of it has dislodged the academic methodology underneath. If anything, the methodology is what makes the commercial pace sustainable. You cannot move that fast on genuinely novel work without rigorous practice for telling yourself the truth about what you've actually built.

Drug discovery is the older version of the same pattern. Pharma's standards of evidence are absurd by general software-industry norms, and they aren't a brake on the commercial work, they're the precondition for it. The discipline of asking "but how do you know?" is what lets a drug company sell anything at all. Without it, no regulator approves and no doctor prescribes. The commercial outcome and the academic rigour aren't in tension. They're the same thing approached from two sides.

The pattern is the opposite of the conventional narrative I set upon when I first started. Academia is slow and detached, industry is fast and real, and growing up means moving from one to the other. The companies actually doing the most consequential commercial work of our generation didn't make that move. They learned to hold both at once.

Clever for clever's sake, and the strategic version of cleverness

Inside a commercial enterprise, this balance is harder to hold than it sounds, because money is finite and curiosity is infinite. You can't fund people to follow every interesting thread that opens up in front of them. At our stage in particular, every hour spent on something that doesn't get us closer to a product customers will pay for is an hour we don't have. There has to be discipline about what the cleverness is for.

But the easy version of that argument badly undersells what curiosity-driven research actually produces. Quantum mechanics had no obvious commercial application when it was being worked out. Public-key cryptography, the basis of every secure transaction on the internet, came out of mathematicians being interested in factoring problems for their own sake. If you'd asked the people doing that foundational work what their product roadmap was, they'd have looked at you as though you had just visited from Mars. The economic value came later, and it could only come later, because the underlying work needed to exist first.

I am beginning to learn that the skill is holding both pressures at once. We try to make room for the team to read the state of the art, to think, and to follow the part of a problem they're genuinely curious about. We also need to be relentlessly clear about why we're doing what we're doing, who pays for it, and what would have to be true for the work to compound into a product.

It's partly why I'm so suspicious of the 996 instinct that periodically sweeps through tech. Twelve-hour days, six days a week, all execution. I would rather my engineers worked an hour a day and solved a problem that genuinely moved the field than worked twelve hours a day producing code an AI could have written for free. Output without thought is increasingly cheap. Thought is what we're paid for. Science is the asset. Turning it into a product is our challenge.

How we hire

This then shapes how we hire.

Most of the team we've built at Data Revival have PhDs. One of the most curious people on the team doesn't; he's an engineer who's taught himself chemistry as a domain, which is a sentence I never get tired of saying. The CV that signals what we're looking for is varied. The trait underneath isn't.

In order, we hire on intellectual curiosity, technical skill, and commercial nous. Curiosity first. Commercial instinct second. We have not, in my experience, been able to teach curiosity, however, we can bring in help for the commercials. People either have the habit of sitting with a messy, ill-defined problem until they genuinely understand it, or they don't. A good PhD trains that habit. So does the kind of engineering background that involves making physical things work in the real world. What those backgrounds have in common is a refusal of easy answers.

The bet is that the commercial muscle can be built afterward, and the deep technical thinking can't. In practice that means hiring people who can read a paper or formulate a novel idea, then deliberately and constantly working on that to turn it into something a customer will use. The mistake would be to assume the academic instinct alone is enough. It isn't. You have to point it at the problems the business actually needs solved.

There's a related point worth making about the UK specifically. We are running, in academic terms, against the US and China with orders of magnitude less population and capital, and we are punching above our weight in ways that aren't talked about widely enough. There is a remarkable density of intellectual capacity sitting in British universities right now, much of it inside people who've never been told their skills are commercially valuable, never mentored on what an industrial role looks like, and who, with the right retuning, become some of the highest-leverage hires a small deep-tech team can make.

For PMs reading this, particularly those building or hiring on technical teams: don't only filter on whether someone has shipped product before. Filter on whether they can hold a problem in their head, follow it where it goes, and tell you honestly what they don't yet know. The product instinct can be hired in or trained in. The thinking, in my experience, cannot.

You don't have to pick a side

The version of this story I hear most often from other founders is the binary one. Academia or industry. Theory or shipping. Pick a side.

That isn't the story I've ended up in. The companies I admire most, in our space and adjacent to it, didn't abandon the academic mindset on the way to becoming commercial. They learned to hold it alongside a commercial one, and let each constrain the other. Novelty drives the innovation. Process turns the innovation into something a customer can use. Curiosity finds the problem worth solving. Discipline makes the solution something anyone can rely on. Neither half does the whole job. Together they do.

That's the balance we're trying to strike at Data Revival. It's harder than picking a side. I'm increasingly convinced it's the only thing worth trying to do.

Share

ABOUT THE AUTHOR

Samuel Munday

Samuel Munday
Co Founder at Data Revival

Sam Munday is the founder and chief executive of Data Revival, a University of Southampton spin-out building the AI infrastructure that converts the world's unstructured chemical knowledge into machine-readable form. The company's technology is used by major organisations across drug discovery, polymers, and semiconductors.


Alongside this, Sam is a Senior Research Assistant and doctoral researcher at the University of Southampton, working at the intersection of computer vision, chemically aware deep learning, and the ethics of AI in the scientific industries. He has published across a range of peer-reviewed journals and is a contributor to the international IUPAC FAIR Chemistry Cookbook.


Over the past five years he has lectured on software for chemists at the Universities of Oxford and Southampton. He is a regular speaker on AI in the scientific industries, with recent engagements ranging from UK Parliament to international conferences, and is a vocal advocate for chemistry-aware AI systems that domain experts can trust.

Related articles

Insights and thoughts from leading product people.

Looking to build your product team or find the perfect role? Let’s chat