Parallax Advisory blog

What It Actually Takes to Commercialise Research IP

Phil Delaney — Tue, 14 Apr 2026 07:55:33 GMT

Most organisations involved in collaborative research understand, in principle, that their work has commercial potential. Fewer have a clear idea of what it actually takes to realise that potential. And almost none are prepared for how long and how complicated the process is.

I have been through it. The Value Australia project produced a commercialisation outcome that a specialist lawyer who had navigated many similar processes described as a remarkable success. It returned millions to the foundation investors - FrontierSI and UNSW over a four-year period. A new company was established, a strategic partner was secured, and the technology went on to find a home inside one of Australia's most significant property transaction platforms.

It was also a process that stumbled near the finish line, involved hundreds of pages of legal agreements, required navigating a major unexpected tax challenge, and consumed more of my time and energy than I had anticipated when we started.

Here is what that process actually looked like, and what I wish I had known going in.

Start Earlier Than You Think You Need To

The first thing to understand about research commercialisation is that the timeline is longer than any research team expects. If you are working on a three or four year project and you want a commercial outcome at the end of it, you need to start the commercialisation work before the halfway point, but ideally from day 1.

This is uncomfortable, because it requires making commercial decisions before the technology is fully developed. But the alternative is worse: arriving at the end of the project with valuable IP and no clear pathway, which means going back to grants, or watching the team disperse before the commercial process is complete.

Document the IP as you go. This sounds obvious, but under the pressure of delivery it is often deprioritised. Every decision, every model iteration, every innovation that could be relevant to a future claim needs to be recorded at the time. You will not be able to reconstruct it later with the clarity and precision that a formal due diligence process will require.

Understand What You Have Before You Try to Sell It

Before approaching the market, you need to be genuinely clear about three things: what the IP actually is, what problem it solves for a specific market, and whether that market is large enough and willing enough to pay.

For Value Australia, we thought through product-market fit and develop a go-to-market strategy. This was more than just a validation exercise - it changed what we built in the final phase of the project, ensuring that the products were structured in a way that matched how the market would actually evaluate and use them, not just what was technically possible.

There is a natural instinct among technically excellent teams to keep optimising the underlying model, to get the accuracy one step closer to perfect. The commercial question is different: is it good enough, and differentiated enough, to win in a competitive market? That is not the same question as whether it is technically optimal.

The output of this phase should be a clear product strategy, an identified set of first customers, a revenue model, and an understanding of how your technology compares to what already exists. Without this, you do not have a basis for a credible pitch.

The Pitch Is a Filtering Tool

We created a pitch deck and took it to the market. Eight to ten slides. A compelling value proposition. Evidence of product-market fit. A clear team story. Early customer traction. Competitive landscape. Revenue projections. An ask.

The pitch is not primarily a persuasion tool. It is a filtering tool. You are not trying to convince everyone. You are trying to find the organisations where there is genuine strategic alignment with what you have built. Those organisations will respond quickly, engage substantively, and show you through their behaviour that they see value in what you are offering.

Strategic alignment matters more than the size of the initial offer. An organisation that deeply understands why your technology is valuable to their business will be a better long-term partner than one that is offering a higher valuation but struggling to articulate the strategic rationale.

That gap tends to become significant during due diligence and negotiation when difficult questions arise. Expect to have five to seven substantive meetings with a potential partner before anything binding is on the table.

Negotiation Is a Process, Not a Conversation

When you get to the stage of negotiating an offer, there are far more variables in play than just the price. Valuation, upfront payment structure, ongoing ownership, dilution provisions, transition of staff, governance of the new entity, the nature of your ongoing relationship with the business, board representation, and earn-out conditions are all elements that can be configured in many different ways.

We engaged a corporate finance adviser who specialised in exactly these kinds of deals. We also engaged an independent valuations expert to produce an external assessment of the IP value. Both were important. The corporate finance adviser had been through the process many times and understood how to navigate it. The independent valuation gave us a defensible anchor for conversations about price.

The advisers will provide advice. They will not solve your problems. I had to work through more unexpected issues than I had anticipated, and the navigation required judgment that only I could exercise because I understood the context and the relationships. Do not assume that engaging good advisers means the hard decisions will be made by someone else.

Due Diligence Is the Real Test

Receiving an agreed offer is roughly halfway through the process. The due diligence phase is where a partner really examines what they are buying.

In our case this involved workshops, detailed written questions, hundreds of supporting documents, and weeks of follow-up. There were around fifteen people on the other side, representing commercial, technical, legal, financial, and tax perspectives. Everything we had said about the technology, the IP, the team, the market, and the financials was examined in detail.

The deal is not done until it is done. This sounds obvious, but it is genuinely difficult to hold onto in practice when you have been working on something for months and the finish line appears to be within reach. Stay alert to the end.

What the Agreements Actually Cover

The final stage involves creating and negotiating the legal agreements. In our case this included the constitution of the new company, an IP assignment deed, a share purchase agreement, a shareholders' deed, an in-kind letter, and a business plan. More than two hundred pages of documents, across four or five rounds of revisions, with legal teams on both sides scrutinising every clause.

Every clause matters. Not because most of them will ever be triggered, but because the ones that are triggered tend to be the ones involving significant money or decisions, and their meaning at that point needs to be unambiguous. Engage a legal team that has done this before, preferably one that has done it in your specific context.

What I Would Tell Anyone Starting This Process

The technical quality of the work matters, but it is not sufficient. A great model that is poorly positioned, inadequately documented, or taken to the wrong partner will not achieve a great outcome.

The process rewards organisations that have thought carefully about commercial value throughout the project, not just at the end. It rewards teams that engage the market genuinely and early. It rewards advisers who are honest rather than reassuring.

And it rewards persistence. Deals of any significance take longer than expected, surface problems you did not anticipate, and require judgment calls that no amount of preparation fully prepares you for.

The outcome, when it works, is worth it. Not just financially, but in terms of what it means for the technology to have a home, a team, and a future that the research program alone could never have provided.

From Idea to Reality: Lessons from Turning Research Projects Into Enduring Products

Phil Delaney — Tue, 14 Apr 2026 07:43:10 GMT

Over roughly a decade working in research commercialisation and technology, I have taken many different projects through the journey from idea to a working product or company. Each one reached some version of the market. Each one taught me something different. This post covers three of these, and two out of three I would genuinely call successful.

Two out of three is a good hit rate as far as I’m concerned. Research and technology commercialisation is not a process you can run reliably from a template. But there are patterns in what works and what does not, and the most important of them start long before anyone writes a line of code or files for a patent.

Here is what I learned from each.

Project One: Envision

Status: Housing Policy. Funding: Grants. Lesson: Focus on the right problem.

Envision started from a real and genuinely important insight. When middle-ring suburbs of cities are redeveloped, the outcome is almost always worse than it could be. Land gets locked up for another fifty years in a form that does not reflect what the community actually needs. Local governments have limited tools to identify which sites could be better used, or to have productive conversations with developers about what better development might look like.

The problem was real. The people who had the problem were real. State government, local government, developers, community groups. We built an online tool to help councils find sites suited to greyfield development, where ageing housing sits on land whose value and location suggest a better use is possible.

The product worked. It still exists. But I was not deeply satisfied with the outcome. The reason was that we had not been precise enough about which of those stakeholders would actually pay to solve the problem. State government was interested, until they were not. Councils were willing to pay, but their budgets are constrained. Developers had no incentive to use a tool that identified sites they had not chosen themselves. The funding model was grant-dependent, which meant lumpy development cycles, gaps in use, and no strong market signal.

The lesson was not that the problem was wrong, but that we had not been disciplined enough about who would pay to solve it, and we had moved to building the solution before that question was properly answered. In the end, the problem that needed solving was one of policy and community engagement, not one of technology. It is this policy and engagement effort that continues in Swinburne University and Maroondah Council to this day.

Project Two: Value Australia

Status: Operating company within PEXA. Funding: Collaborative Investment Lesson: Timing is as important as planning.

Value Australia is the one I would point to if someone asked for a genuine research commercialisation success story. It is also the one where, if I am honest, the timing of certain decisions and relationships was as important as the quality of the work.

The project was a collaboration between FrontierSI, UNSW, Commonwealth Bank, NSW Government, and several partners. The goal was to build Australia's first highly accurate, transparent, and interactive automated property valuation model, one that could tell you what a property was worth, explain why, and let you model what would happen to the value under different scenarios.

The problem being solved was significant. Property valuation in Australia is expensive, inconsistent, and opaque. Planning decisions, infrastructure investment, lending, insurance, and tax are all affected by valuations, and the existing models were not fit for the decisions being made with them.

After three years of development we had commercially valuable IP and a clear sense that there was a market for it. We worked through the commercialisation path deliberately: engaging the right advisors to validate product-market fit, developing a go-to-market strategy, pitching to strategic partners, surviving a due diligence process that involved fifteen people on the other side and hundreds of pages of agreements, and ultimately establishing a company called Slate Analytics, with PEXA as the strategic partner and majority owner.

The deal returned millions to FrontierSI and UNSW over a four-year period. It was later recognised as a Research Commercialisation Award winner by Cooperative Research Australia, described by a specialist lawyer as a remarkable success rarely seen in collaborative research programs.

But timing was a genuine factor. The right strategic partner appeared at the right time with the right strategic rationale. The deal stumbled multiple times, including a significant tax challenge before signing! COVID delayed everything. The lesson isn’t that planning does not matter. It is that even when you do everything right, you need the environment to cooperate, and you need to be in the market long enough for the right opportunity to find you.

Project Three: MapAI

Status: Operating start-up. Funding: Shareholder Investment Lesson: Get the right support early.

MapAI was the most deliberate of the three. Having been through the previous two experiences, I came to it with a clearer sense of what I wanted to do differently.

The problem was real and well understood: good decision-making is held back by a lack of easy, quick access to insights locked inside geospatial data. Most organisations with rich spatial data sets cannot easily query them, cannot surface patterns without significant analyst time, and certainly cannot let non-technical staff ask questions and get useful answers. Combining conversational generative AI with geospatial analysis in a transparent, explainable way addressed this directly.

This time we spun the company out from the start with a clear intention to build for investment. We raised pre-seed funding, developed the business strategy and product roadmap with board oversight, and raised a further seed investment, reaching a multi-million post-money valuation within six months of launch. We secured foundational customers, built strategic partnerships, and won a core role in a $6.5 million, three-year project to develop an AI urban planning product in partnership with Archistar and PEXA.

The lesson from MapAI was about getting the right support around you from day one: the right investors, the right advisers, the right board, and not waiting until you need them desperately to find them.

The Pattern Across All Three

Looking back across these three experiences, the framework that connects them is not complicated, but it requires discipline to follow in order.

Understand the problem first, specifically, in the language of the person who has it. Find out who has the problem and whether they will pay to solve it. Only then design the solution. Choose your first customers carefully and build with them, not for a general market. And think hard about the sustainability model before you are in crisis about it.

The places where I have seen this process go wrong are always the same. Teams skip the early problem validation and go straight to building. They confuse interest from potential users with willingness to pay. They build for everyone and end up serving no one well. They leave the question of what happens after the project until the project is almost over.

None of this is new advice. But in my experience it is rarely followed consistently, particularly in research and technology environments where the technical work is genuinely exciting and the commercial work feels like a distraction. It is not a distraction. It is the foundation that determines whether the technical work ever has any impact at all.

Stop Selling Tech, Start Solving Their Problem

Phil Delaney — Tue, 14 Apr 2026 07:11:23 GMT

There is a trap that catches almost every organisation working with data, research, or emerging technology at some point. They build something genuinely valuable, launch it, and then wait. And wait.

The product is real, the capability is strong, the team is definitely talented. But adoption is slower than expected, the early users are not the ones who matter most, and the feedback from the market is confusing because the market does not seem to understand what has been built.

This is not a marketing problem, it is a problem with framing and communication. And it starts much earlier than the launch.

The ‘Build It and They Will Come’ Myth

When we talk about technology going to market, there are two fundamentally different strategies at play, and most organisations default to the wrong one.

The first is a push strategy. You create a product, define its features, and then push it along the distribution chain looking for customers. Each step in the chain adapts the message slightly for their own purposes, and by the time it reaches the end user, it may sound like something entirely different from what was built, or may not reach them at all.

The second is a pull strategy. You start with the end user. You understand their problem in their own language, build a product or service that genuinely solves it, and create the conditions for users to actively seek you out. They find you because you are visible where they are searching, and when they find you, they recognise their own problem in what you say.

Most technically strong organisations default to push, not because they are lazy, but because they are good at what they do. They understand the technology better than anyone. The problem is that end users do not search for technology. They search for solutions to problems.

A farmer managing topsoil runoff is not searching for fractional ground cover products. A mining company managing rehabilitation obligations is not searching for LiDAR analytics platforms. If you are only describing your product in the language of what it is, you will be invisible to most of the people who could benefit from it most.

Understanding Where You Sit in the Value Chain

One way to reframe this is to think carefully about where your product sits in a data or technology value chain, and how that determines who your real end user is.

At one end of the chain you might have a data custodian producing raw satellite imagery. At the other end you have a mining company making decisions about rehabilitation compliance. Between them sit processors, integrators, platform builders, and analysts. Each step adds value. But the decision, and the business outcome, sits at the end.

The problem is that communication in most technology sectors flows primarily between adjacent players. The data provider talks to the integrator. The integrator talks to the platform. The platform, maybe, talks to the end user. That message has been filtered, compressed, and reinterpreted at each step. Nobody is talking directly to the person who will actually benefit.

This creates a compounding gap between the potential and actual impact of even very good technology investments. The investment is real. The technical capability is real. But the commercial and social return is substantially below what it should be, because the product was designed for the value chain, not for the person at the end of it.

The Questions Worth Asking First

The organisations I have seen get this right consistently ask three questions before they build anything, and then they go and actually talk to people to find the answers.

Who specifically has the problem? Not a market segment. Not a sector. An actual person with a job title, a set of responsibilities, and a set of headaches. What does success look like for them? What does failure cost them? How are they currently solving the problem, even if badly?

Do they care about this problem enough to pay to solve it? Payment is not always financial. It can be time, political capital, or the ongoing cost of a workaround. But if the answer is no, the product is solving a problem that does not matter enough, regardless of how elegant the solution is.

What language do they use when they talk about the problem? This is the one most technical teams resist. The goal is not to explain what you have built. The goal is to be visible, recognisable, and credible when someone is looking for a solution to a problem they already know they have.

These questions sound straightforward. They are genuinely hard to answer without going outside the building and asking. Most teams skip this step, or run a handful of informal conversations that confirm what they already believe.

Balancing Push and Pull

Push and pull are not competing strategies. The most effective organisations run both simultaneously, but with clear intent about which is doing which job.

The pull strategy builds awareness and demand among the end users who will ultimately determine whether a technology has impact at scale. It requires speaking in the language of problems, not the language of products. It requires patience. And it requires a genuine willingness to let what you learn change what you build.

The push strategy improves the value chain that will actually deliver the product to those users. It ensures that the organisations between you and the end user understand what you have, can communicate it clearly, and can integrate it into their own offerings.

The failure mode is running a push strategy and assuming it is doing the job of a pull strategy. Distributing a product through channels that are not connected to the end user's problem is not the same as creating demand.

What This Means in Practice

For organisations working in research, data, or technology-intensive fields, the practical implication is that industry engagement is not a communications activity that happens after the real work is done. It is core to the work itself.

The insights that come from genuinely understanding end users, in their own language, on their own terms, should directly shape how products are designed, how they are positioned, how they are priced, and how their impact is measured.

Technology that solves a real problem, explained in the language of the person who has that problem, is far easier to sell, faster to adopt, and more likely to create the kind of sustained impact that justifies the investment that built it.

If you cannot describe your product in a single sentence that your target end user would use to search for a solution to their problem, with no technical jargon, that is the place to start.