A startup has developed software that analyses production data and predicts potential equipment downtime. For a mid-sized mechanical engineering company, the solution is appealing: unplanned downtime is expensive, but at the same time the company doesn't want to invest in a large new system right away.

"We can start a pilot project in four weeks," the founding team proposes. They talk about a "lean proof of concept", and what they mean by that is: connect a few data sources, generate initial alerts, review the results together. The company's head of production finds the approach interesting and agrees to provide the necessary information.

What happens next will be familiar to many from first-hand experience. The startup waits for access to the machine data and expects a quick start. Inside the company, however, a number of questions have to be settled first: which data may be shared at all, who approves access, whether IT security needs to review it, and whether the equipment can be adapted for the test at short notice. Three weeks later the startup still has no access and reads this as a lack of priority. The head of production, meanwhile, wonders why the startup is already asking for a firm start date when important questions are still open.



Two perspectives, one goal

Nobody did anything wrong here. The two sides simply understood "lean" and "fast" differently. The startup wanted to limit the technical effort; the mid-sized company wanted to keep its organisational processes manageable. This is where it is decided whether a partnership will hold — not by the technology alone, but by a shared understanding of the goal, the approach and the responsibilities.

Both sides bring valuable but different strengths to the table. Startups develop new solutions, test assumptions and want to learn quickly. Mid-sized companies know their markets, customers and processes, and they know what a solution has to prove in day-to-day operations. The combination creates considerable potential — provided the differences are addressed openly and translated into concrete agreements.ents.



From product description to relevant benefit

The common language doesn't begin once the project is under way; it begins with positioning and with the very first approach. Tech startups in particular tend to put their product centre stage and to argue with facts and features. For the mid-sized company in our example, though, the term "AI-based predictive maintenance platform" is probably less relevant than the question: what specific problem does this technology solve in my operation?

If the startup communicates the benefit it creates instead, the message sounds rather different: "Using existing production data, we identify patterns early on that point to possible equipment downtime." The technical capability is the same. But it is described from the target group's perspective — understandable, concrete and with a direct link to the business. The other side doesn't feel confronted with jargon, but recognised in its own situation.



Communication determines the next step

This translation work matters most with tech topics that need explaining. Product information and technical detail have to become a message that is understood outside the development team as well. It should answer what changes as a result of the solution, who it is relevant for, and under what conditions using it makes sense.

Only once this benefit has been clearly described can a concrete project framework be developed from it. In the first conversation, therefore, both sides should clarify what is to be tested in the proof of concept, which data is needed for it, and when they will jointly decide whether the next step makes sense. A short project profile setting out the goal, scope, responsibilities, prerequisites and timeline can create certainty here. It translates the message into concrete collaboration.

In day-to-day project work, what's needed is not more meetings or more jargon, but more clarity. Four questions help turn differing expectations into a shared approach.

1. What problem are we trying to solve?

The mid-sized company describes where the pressure to act lies within the organisation — because speed, quality or customer satisfaction is suffering, for example. The startup can then show what its solution can contribute. This turns a general interest in innovation into a concrete use case that both sides can discuss and decide on.

2. What shared goal are we pursuing?

Whether it's processing times, the number of manual steps or adoption rates: goals should be defined as concretely as possible. With technical solutions, both sides should also clarify early on which conditions apply to the specific use case. These include IT security, data protection, interfaces, operations and support. What matters is that the opportunities and the requirements of the project can be assessed realistically — and that both sides know how they will measure success later on.

3. Who makes the decisions?

Startups shouldn't automatically assume that a slow decision means a lack of interest. Mid-sized companies, in turn, should be open about which internal steps are necessary and how much time they realistically take. Depending on the project, that may include procurement, data protection, IT security, legal review or budget approvals. These are readily dismissed as bureaucratic hurdles, yet they can be important prerequisites for safe and reliable deployment. A joint timeline helps both sides. "Fast" then stops being a feeling and becomes an agreement about deadlines and responsibilities.

4. What can we improve?

Feedback is particularly important in the early phases. Startups need responses in order to develop their product further. Mid-sized companies need to be able to say which requirements are met and where improvements are still needed. A "this doesn't work for us yet" becomes constructive when it is immediately followed by what has to change and who takes the next step. Equally, a startup should be transparent when a feature isn't available yet or a request can't be implemented at short notice. That is how commitment is built — even when the solution isn't perfect yet.



A common language from the outset



For our example, this means the startup and the mechanical engineering company have not only developed a shared understanding of what is to be tested. They also know how they will measure success, who contributes what, and when the decision about the next step will be made. A technical solution has become a comprehensible use case. A non-committal conversation has become a clearly defined project. And the project can — if the results are convincing — become a solid reference case.

For that to happen, the common language has to hold at every touchpoint. It should be recognisable in the first contact, on the website, in the pitch, in follow-up content such as expert articles, whitepapers or customer success stories, and in everyday communication during the project. Because ultimately, every one of these measures answers the same question: why is this solution relevant for precisely this target group?

Startups — and, for that matter, all companies — that want to make complex technology understandable should therefore not wait until the product is finished. The decisive translation begins with positioning, with the value proposition, and with the question of which story is relevant for which audience. Particularly with tech topics that require explanation, this is a demanding translation task, and one that calls for specific expertise.