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.