5 September 2026
Why we should build research around the problem, not the solution
There's a sequence a lot of academic research defaults to: build a solution based on what's scientifically interesting, publish it, and only then go looking for a company that might need it. It's solution-first: build something, then search for a problem it fits. I think that order should be flipped. The real challenges in multi-energy microgrids only surface once you start from a problem a company actually has, not from a solution you're hoping applies to one.
So the version worth building toward starts in the opposite place. Not a lab result looking for a home, but a real problem, brought by a company, that researchers and students then build toward. Every new cohort of students inherits a real, unsolved problem instead of an already-built solution to test.
The common approach
ends here, one thesis at a time
The alternative
↻ repeats with the next cohort, on the next real problem
To be clear, this isn't an argument against curiosity-driven research. Only ever starting from a company's problem loses the freedom to pursue questions with no immediate application, and that freedom is where a lot of foundational breakthroughs come from. The point is narrower: applied, problem-first work deserves its own pipeline running in parallel, not a role as an afterthought once a paper is already written.
What that actually looks like
In practice it's four stages, and the point is that none of them are one-off events. Each one is built into a course or a thesis structure, so it runs again automatically with the next group of students instead of depending on someone organizing it fresh every year.
1. Identify
Companies, industries, researchers and students
2. Develop
Student teams, company mentors, researchers
3. Validate
University laboratories, hardware-in-the-loop testing
4. Demonstrate
Real-world pilots and demos with utility & industrial partners
Innovation support throughout
Entrepreneurship, business development, intellectual property, incubators and summer schools
Stage
What it produces
Identify — companies and industries bring real problems to joint workshops and open calls
A catalogue of challenges feeding course projects, theses and PhD topics
Develop — project-based courses and hackathons, each team followed by a company mentor
Prototypes, work-integrated theses, ideas assessed for their potential
Validate — testing on real hardware, checked against measured behaviour, not simulation alone
Reproducible experiments and open datasets reusable by later cohorts
Demonstrate — pilots on operational infrastructure, with an agreed next step for every result
Deployment, licensing, an open-source release, or a new patent application
Entrepreneurship support, business development, IP guidance and incubator access run alongside all four stages rather than showing up only at the end, once something is already built.
Why the order matters
When students only see a project after the researchers have already scoped it, they learn how to execute a plan. When they're in the room while the problem is still being defined, alongside the company that actually has it, they learn something closer to what the job will actually demand of them: how to ask what's needed, not just how to answer it.
It also changes what companies get out of staying involved. A one-off guest lecture or a single sponsored thesis ends when the semester does. A pipeline that keeps producing prototypes, datasets and pilots year after year gives a company a reason to keep showing up, because the relationship keeps paying off, not just the one project.
What universities should facilitate
A pipeline like this doesn't run on good intentions alone. It needs to be something a university actively facilitates, not something a few motivated people pull off despite the system. A few things need to be in place structurally, or it quietly reverts to the old sequence.
- Structural, not event-based: build the Identify and Develop stages into existing courses and thesis slots so they happen every semester by default, not because someone organizes a special event.
- Funding that spans stages: bridge funding that covers the gap between a promising student prototype and a fundable research project.
- Standing agreements with companies: a lightweight recurring mechanism, an annual sponsorship, a mentor commitment, a data-sharing agreement, instead of renegotiating a new contract per project.
- Shared infrastructure access: lab and hardware-in-the-loop time bookable by student teams, not only by funded projects, so validation doesn't bottleneck on budgets.
- Entrepreneurship encouragement: actively support students who want to spin their project into a company, not just publish it, with access to incubators and founders who've done it before.
- Business-model training: courses that teach students to evaluate their own ideas, who would use it, what it would take to build, whether it's worth pursuing, before they sink a thesis into it.
- A visible handoff to the next cohort: open datasets, repositories and a short handover note, so the next group doesn't start from zero.
That, more than any single demonstration or publication, is what I think a university is for: not delivering a finished result to industry, but building a pathway good enough that the next generation doesn't have to start from zero.
Want to talk about this?
Open to conversations on research careers, project leadership and the path from postdoc to industry.
Start a conversation →