Ein Startup hat eine Software entwickelt, die Produktionsdaten auswertet und mögliche Anlagenstillstände vorhersagt. Für einen mittelständischen Maschinenbauer ist die Lösung interessant: Ungeplante Stillstände verursachen Kosten, gleichzeitig möchte das Unternehmen nicht sofort in ein großes neues System investieren.

„Wir können in vier Wochen mit einem Pilotprojekt starten“, schlägt das Gründerteam vor. Es spricht von einem „schlanken Proof of Concept“ und meint damit: wenige Datenquellen anbinden, erste Warnmeldungen erzeugen, Ergebnisse gemeinsam auswerten. Der Produktionsleiter des Maschinenbauunternehmens findet den Ansatz interessant und sagt zu, die nötigen Informationen bereitzustellen.

Was danach passiert, kennen viele aus erster Hand: Das Startup wartet auf Zugang zu den Maschinendaten und rechnet mit einem schnellen Start. Im Unternehmen muss jedoch zunächst geklärt werden, welche Daten überhaupt weitergegeben werden dürfen, wer den Zugriff freigibt, ob die IT-Sicherheit geprüft werden muss und ob die Anlage für den Test kurzfristig angepasst werden kann. Drei Wochen später hat das Startup immer noch keinen Zugang und interpretiert das als fehlende Priorität. Der Produktionsleiter wiederum wundert sich, warum das Startup schon nach einem verbindlichen Starttermin fragt, obwohl wichtige Fragen noch offen sind.



Zwei Perspektiven, ein Ziel

Niemand hat hier falsch gehandelt. Beide Seiten haben unter „schlank“ und „schnell“ nur etwas anderes verstanden. Das Startup wollte den technischen Aufwand begrenzen, der Mittelständler die organisatorischen Prozesse beherrschbar halten. Hier entscheidet sich, ob eine Kooperation tragfähig wird: nicht an der Technologie allein, sondern am gemeinsamen Verständnis von Ziel, Vorgehen und Zuständigkeiten.

Beide Seiten bringen dafür wertvolle, aber unterschiedliche Stärken mit. Startups entwickeln neue Lösungen, testen Annahmen und wollen schnell lernen. Der Mittelstand kennt seine Märkte, Kunden und Prozesse und weiß, woran sich eine Lösung im Alltag bewähren muss. Die Kombination schafft großes Potenzial – wenn die Unterschiede offen angesprochen und in konkrete Vereinbarungen übersetzt werden.



Von der Produktbeschreibung zum relevanten Nutzen

Die gemeinsame Sprache beginnt nicht erst im Projekt, sondern bereits bei der Positionierung und der ersten Ansprache. Gerade Tech-Startups neigen dazu, ihr Produkt in den Mittelpunkt zu stellen und mit Fakten und Features zu argumentieren. Für den Mittelständler aus unserem Beispiel ist der Begriff „KI-basierte Predictive-Maintenance-Plattform“ jedoch vermutlich weniger relevant als die Frage: Welches konkrete Problem löst diese Technologie in meinem Betrieb?

Kommuniziert das Startup stattdessen den entstehenden Nutzen, klingt die Botschaft schon anders: „Wir erkennen anhand vorhandener Produktionsdaten frühzeitig Muster, die auf einen möglichen Anlagenstillstand hinweisen.“ Die technische Leistung bleibt dieselbe. Aber sie wird aus der Perspektive der Zielgruppe beschrieben – verständlich, konkret und mit einem direkten Bezug zum Business. Das Gegenüber fühlt sich nicht mit Fachbegriffen konfrontiert, sondern in seiner Situation abgeholt.



Kommunikation entscheidet über den nächsten Schritt

Diese Übersetzung ist gerade bei erklärungsbedürftigen Tech-Themen entscheidend. Aus Produktinformationen und technischen Details muss eine Botschaft werden, die auch außerhalb des Entwicklungsteams verstanden wird. Sie sollte beantworten, was sich durch die Lösung verändert, für wen sie relevant ist und unter welchen Voraussetzungen ihr Einsatz sinnvoll ist.

Erst wenn dieser Nutzen klar beschrieben ist, lässt sich daraus ein konkreter Projektrahmen entwickeln. Im ersten Gespräch sollten beide Seiten deshalb klären, was im Proof of Concept getestet werden soll, welche Daten dafür benötigt werden und wann gemeinsam entschieden wird, ob der nächste Schritt sinnvoll ist. Ein Projektsteckbrief mit Ziel, Umfang, Verantwortlichkeiten, Voraussetzungen und Zeitplan kann dabei Sicherheit schaffen. Er übersetzt die Botschaft in konkrete Zusammenarbeit.

Im Projektalltag braucht es dafür nicht mehr Meetings oder mehr Fachbegriffe, sondern mehr Klarheit. Vier Fragen helfen dabei, aus unterschiedlichen Erwartungen ein gemeinsames Vorgehen zu machen.

1. Welches Problem soll gelöst werden?

Der Mittelständler beschreibt, wo im Unternehmen der Handlungsdruck liegt – etwa, weil Tempo, Qualität oder Kundenzufriedenheit darunter leiden. Das Startup kann anschließend zeigen, welchen Beitrag seine Lösung dazu leisten kann. So wird aus allgemeinem Innovationsinteresse ein konkreter Use Case, über den beide Seiten sprechen und entscheiden können.

2. Welches gemeinsame Ziel verfolgen wir?

Ob Bearbeitungszeiten, die Anzahl der manuellen Arbeitsschritte oder Nutzungsquoten: Ziele sollten so konkret wie möglich formuliert werden. Bei technischen Lösungen sollten beide Seiten außerdem früh klären, welche Rahmenbedingungen für den konkreten Anwendungsfall gelten. Dazu gehören beispielsweise IT-Sicherheit, Datenschutz, Schnittstellen, Betrieb und Support. Wichtig ist, dass Chancen und Anforderungen des Projekts realistisch eingeschätzt werden können – und dass beide Seiten wissen, woran sie später den Erfolg messen.

3. Wer trifft Entscheidungen?

Startups sollten nicht automatisch davon ausgehen, dass eine langsame Entscheidung fehlendes Interesse bedeutet. Mittelständler wiederum sollten offenlegen, welche internen Schritte notwendig sind und wie viel Zeit sie realistisch beanspruchen. Dazu gehören je nach Projekt beispielsweise Einkauf, Datenschutz, IT-Sicherheit, rechtliche Prüfung oder Budgetfreigaben. Sie werden gerne als bürokratische Hürden abgestempelt, können aber wichtige Voraussetzungen für einen sicheren und verlässlichen Einsatz sein. Ein gemeinsamer Zeitplan hilft beiden Seiten. „Schnell“ wird dann nicht zum Gefühl, sondern zu einer Vereinbarung über Deadlines und Zuständigkeiten.

4. Was können wir optimieren?

Gerade in frühen Phasen ist Feedback wichtig. Startups brauchen Rückmeldungen, um ihr Produkt weiterzuentwickeln. Mittelständler müssen benennen können, welche Anforderungen erfüllt sind und wo noch nachgebessert werden muss. Ein „Das passt für uns noch nicht“ wird konstruktiv, wenn direkt folgt, was sich ändern muss und wer den nächsten Schritt übernimmt. Genauso sollte ein Startup transparent machen, wenn eine Funktion noch nicht verfügbar ist oder ein Wunsch nicht kurzfristig umgesetzt werden kann. So entsteht Verbindlichkeit – auch dann, wenn die Lösung noch nicht perfekt ist.



Von Beginn an eine gemeinsame Sprache

Für unser Beispiel bedeutet das: Das Startup und der Maschinenbauer haben nicht nur ein gemeinsames Verständnis davon entwickelt, was getestet werden soll. Sie wissen auch, woran sie den Erfolg messen, wer welchen Beitrag leistet und wann über den nächsten Schritt entschieden wird. Aus einer technischen Lösung ist ein nachvollziehbarer Anwendungsfall geworden. Aus einem unverbindlichen Gespräch ein klar umrissenes Projekt. Und aus dem Projekt kann – wenn die Ergebnisse überzeugen – eine belastbare Referenz entstehen.

Damit diese Entwicklung möglich wird, muss die gemeinsame Sprache an jedem Touchpoint bestehen bleiben. Sie sollte sich beim Erstkontakt, auf der Website, im Pitch, in weiterführenden Inhalten wie Fachartikeln, Whitepapern oder Customer Success Stories, aber auch in der täglichen Kommunikation während des Projekts wiederfinden. Denn jede dieser Maßnahmen beantwortet letztlich dieselbe Frage: Warum ist diese Lösung für genau diese Zielgruppe relevant?

Startups – und übrigens alle Unternehmen –, die komplexe Technologie verständlich machen wollen, sollten deshalb nicht erst beim fertigen Produkt ansetzen. Die entscheidende Übersetzung beginnt bereits bei der Positionierung, beim Nutzenversprechen und bei der Frage, welche Geschichte für welche Zielgruppe relevant ist. Gerade bei erklärungsbedürftigen Tech-Themen ist das eine anspruchsvolle Übersetzungsaufgabe, die spezielle Expertise erfordert.