Einheit 11. Verhandlungen nach dem Erstkontakt: Discovery, Partnerschaft und Übergang zum Projekt

14. Oktober 2026 · Praktische Einheit 4 · 1 Std. 38 Min. 33 Sek. Grundlage ist das automatische Transkript IgorSikorskyKPI_P4_14102026.mp4.md. Dies ist ein redigiertes Lehrskript, keine wörtliche Abschrift. Unternehmen, Personen, Ergebnisse und Verhandlungen in beiden Szenarien sind Rollenspiele im Unterricht. Die genannten kommerziellen Kennzahlen und technischen Fähigkeiten wurden nicht unabhängig überprüft. Details eines fiktiven Verteidigungsprodukts sowie das vollständige Rohtranskript werden nicht öffentlich bereitgestellt.

Stellung im Kurs: Conversion üben, nicht nur eindrucksvoll präsentieren

In Einheit 10 wurden der Kontakt nach einer Fachveranstaltung, das Follow-up und die Vorbereitung des ersten inhaltlichen Gesprächs behandelt. Einheit 11, vom Dozenten als elfte Einheit in der Chronologie und vierte praktische Einheit bezeichnet, führte diese Übung fort. Ziel war, einen potenziellen Kunden von der Bekanntschaft zu einem konkreten Bedarf und einem vereinbarten nächsten Schritt zu führen, statt lediglich Unternehmensfolien zu zeigen.

Zu Beginn waren noch studentische Artefakte offen, darunter Landingpages, Präsentationen und Aufgaben aus den vorherigen Themen. Ihre Prüfung und Korrektur gehörte zur Praxis. Die zentrale Methode war ein moderiertes Rollenspiel mit Unterbrechungen, Feedback und erneuten Versuchen. Ergebnis war die Vorbereitung auf RFI, Planung und Proposal – kein unterzeichneter Vertrag.

1. Follow-up: von der schriftlichen Absprache zur Kalendereinladung

Nach einer Fachveranstaltung nimmt das Team Kontakt zu einem fiktiven Engineering Manager namens Otto auf. Die E-Mail soll sich auf das frühere Gespräch beziehen, konkrete Zeitvorschläge enthalten und dem Empfänger die Möglichkeit lassen, eine Alternative vorzuschlagen. Ein Termin ist erst dann vereinbart, wenn die Gegenseite den Zeitpunkt bestätigt, nicht bereits bei einseitiger Auswahl eines Slots.

Der Dozent wies auf unnötigen Nachrichtenaustausch hin: Nach der Einigung muss man normalerweise keine zusätzliche E-Mail mit „den Link schicken wir später“ verfassen. Besser ist ein Kalendereintrag mit Teilnehmenden, Zeitzone, Thema und Meeting-Link. Die Einladung muss dem vereinbarten Zweck entsprechen. Die Kalendereinladung setzt eine Absprache operativ um; sie ersetzt die Absprache nicht.

2. Wer teilnimmt und warum sich die Interessen unterscheiden

Im ersten Szenario wählte das Team vier Rollen: Engagement Manager, Partnership Manager, Delivery Manager und Engineering/Technical Lead. Jede beantwortet andere Fragen; eine große Delegation ohne Rollenerklärung kann den Kunden irritieren.

Die Übung unterscheidet den Verkauf einer Engineering-Dienstleistung von gemeinsamer Produktentwicklung. Das sind unterschiedliche Geschäftsmodelle, deren Ziele konkurrieren können. Engagement möchte zeitnah bezahlte Arbeit gewinnen, Partnership bewertet die langfristige Kooperation und Delivery kontrolliert die Machbarkeit der Zusagen. Das Team sollte seine Position vor dem Gespräch abstimmen, statt diese Interessenkonflikte zu verstecken.

3. Eine Vorstellungsrunde schafft Vertrauen

Der Kunde kennt nach der Veranstaltung nur ein Mitglied des Teams. Daher sollen alle Beteiligten kurz Name, Rolle, Verantwortungsbereich und gegebenenfalls eine relevante Stärke nennen. Übergaben sollen natürlich und knapp sein. Klare Zuständigkeiten sind wichtiger als beeindruckende Titel.

Im Rollenspiel unterbrach der Dozent langatmige Danksagungen, sachfremde Erklärungen und unsichere Selbstdarstellung. Die richtige Lehre ist, kurz, selbstbewusst und wahrheitsgemäß zu sprechen. Professionelles Auftreten rechtfertigt weder erfundene Berufserfahrung, Kunden oder Erfolge noch das Verbergen wesentlicher Risiken.

4. Eine Agenda schützt das Ziel des Gesprächs

Vor den Folien sollte das Team erklären, warum das Gespräch stattfindet, was herausgefunden werden soll, wie die Zeit aufgeteilt wird und welches Ergebnis angestrebt wird. Ein möglicher Ablauf: Kennenlernen → kurze Unternehmensvorstellung → Interessen des Kunden → relevantes technisches Beispiel → Fragen und nächste Schritte.

Im zweiten studentischen Szenario fehlte zunächst eine Agenda. Der Dozent sprach das sofort an: Ohne vereinbartes Ziel kann eine Präsentation zu einem Monolog werden. Eindrucksvolle Grafiken oder ein Motto gleichen eine schwache Agenda nicht aus.

5. Warum eine allgemeine Unternehmenspräsentation scheitert

Das erste Team hatte eine umfangreiche Präsentation über ein fiktives Embedded-Unternehmen vorbereitet: internationale Büros, Mitarbeitendenzahlen, Kundenmarken, Technologien, Hardware-Plattformen, Tests und Produktlebenszyklus. Als Übungsvortrag war der Inhalt vorbereitet, doch anschließend blieb unklar, was genau diesem Otto angeboten wurde: Dienstleistung, Produkt oder gemeinsame Entwicklung.

Vor einer zielgerichteten Präsentation sollten die Notizen von der Veranstaltung, Website, Produkte, Kunden, Stellenanzeigen, öffentlich sichtbare Initiativen und berufliche Profile relevanter Personen geprüft werden. Diese Quellen liefern Hypothesen, keine Gewissheit. Die Vermutung über den Kundenbedarf muss durch eine Frage überprüft werden. Jedes Logo, jede Partnerschaft, Kundenstatistik und technische Behauptung auf Folien benötigt eine wahrheitsgemäße Grundlage und eine Freigabe zur Offenlegung.

6. Eine Präsentation muss wechselseitige Discovery ermöglichen

Beim ersten Versuch sprach der Student überwiegend selbst und ließ dem Kunden wenig Gelegenheit zu antworten. Der Dozent zeigte, wie man den Ablauf der Folien mit einer passenden Frage unterbricht, die Antwort aufnimmt und den Gesprächsverlauf verändert.

Wenn eine Folie Hardware-, Software- und Infrastrukturkompetenz zeigt, sollte man fragen, welcher Bereich dem Interesse des Kunden am nächsten liegt. Ist die Antwort Software, folgt die Vertiefung auf der Ebene von Firmware, HAL, Middleware, Architektur oder Anwendung. Erst danach wird die Domäne eingegrenzt. Das ist schrittweise Bedarfsqualifizierung, kein vorweggenommenes Erraten der Anforderungen.

7. Vom breiten Interesse zur konkreten Anfrage

Im ersten Szenario konkretisierte der fiktive Kunde sein Interesse schrittweise: Software Engineering → Anwendungsebene → Automotive-Parksysteme → Schwierigkeiten bei verdeckten Hindernissen. Dies ist ein Beispiel dialogischer Qualifizierung, kein echter Auftrag und keine verifizierte technische Anforderung.

An diesem Punkt verändert sich die Funktion der Präsentation: Sie ist keine Liste der Fähigkeiten mehr, sondern ein Instrument zur Ermittlung eines konkreten Problems. Danach wird dieses Problem in den Worten des Kunden festgehalten und nach Randbedingungen, Eingabedaten, Abnahmekriterien und offenen Fragen gefragt. Vor technischer Discovery sollte das Team keine Lösung zusagen.

8. Engagement orchestriert; Fachleute liefern den Inhalt

Der Dozent verglich den Engagement Manager mit einem Dirigenten: Er bestimmt den Gesprächsrhythmus, übergibt an passende Fachleute und beobachtet die Reaktion des Kunden. Technical Lead liefert die technische Tiefe; Partnership behandelt das Kooperationsmodell; Delivery bewertet die Machbarkeit. Eine Person sollte nicht für sämtliche Fachgebiete sprechen.

Zeigt der Kunde Interesse an technischen Fragen, wird der Engineering Lead einbezogen. Geht es um Phasen, Termine oder Vertragsmodelle, übernimmt Delivery. Das Timing ist wichtig: Eine zu frühe Diskussion von Vertragsgrenzen kann produktive Discovery unterbrechen. Beim Proposal dürfen diese Grenzen aber keinesfalls fehlen.

9. Feedback durch Fragen bestätigen, nicht aus Mimik ableiten

Der Dozent machte auf nonverbale Reaktionen aufmerksam: Aufmerksamkeit, Ablenkung oder besonderes Interesse an einer Folie. Solche Hinweise können weiterführende Fragen anstoßen, sind aber kein verlässlicher Nachweis eines Bedarfs. Bestätigt wird dieser durch eine ausdrückliche Antwort, abgestimmte Gesprächsnotizen oder eine tatsächliche Anfrage des Kunden.

Nach jedem inhaltlichen Abschnitt sind Fragen sinnvoll wie „Was davon ist für Sie besonders relevant?“, „Wo liegt derzeit die größte Schwierigkeit?“ oder „Welche Randbedingung ist entscheidend?“. Antworten gehören ins Meeting-Protokoll; unbestätigte Annahmen werden ausdrücklich als Annahmen markiert.

10. Richtiger Abschluss des ersten Szenarios: RFI und weiterer Discovery-Schritt

Am Ende des ersten Szenarios erklärte der fiktive Kunde sich bereit, seine Erwartungen an eine Softwarekomponente zu beschreiben und eine weitere technische Diskussion zu erwägen. Im Gespräch wurden RFI und RFC genannt. RFI bedeutet üblicherweise Request for Information; RFC hat je nach Prozess unterschiedliche Bedeutungen (beispielsweise Request for Change). In realen Projekten müssen Dokumenttyp und Zweck daher ausdrücklich geklärt werden. RFC ist kein universeller Begriff für eine technische Anfrage.

Statt blind zu verkaufen, kann das Team eine kurze Problembeschreibung anfordern, die Machbarkeit prüfen, einen vorläufigen Scope vorbereiten und ein weiteres Gespräch organisieren. Das ist noch kein Vertrag, aber ein überprüfbarer nächster Schritt mit Verantwortlichen und erwartetem Ergebnis.

11. Delivery übernimmt: von der Idee zum Plan und Proposal

Wenn der Kunde nach Projektphasen fragt, stellt der Delivery Manager die nötigen Rollen zusammen – abhängig vom Problem etwa Embedded Software, Hardware, QA und Engineering-Leitung. Das Ergebnis sollte keine allgemeine Zusage „wir schaffen das“, sondern ein machbarer erster Plan sein.

Der Dozent nannte ausdrücklich die Artefakte: Teamzusammensetzung, Arbeitspakete, Gantt-Diagramm, Phasen, Liefergegenstände, Risiken und Kostenschätzung. Annahmen, Abhängigkeiten und Abnahmekriterien sollten ebenfalls sichtbar sein. Fixed Price und Time & Materials setzen unterschiedliche Klarheit über Scope sowie Änderungs- und Risikomanagement voraus. Das Geschäftsmodell richtet sich nach der Unsicherheit, nicht nach Gewohnheit.

12. Zweites Rollenspiel: ein starkes Produkt verfehlt das Kerngeschäft

Ein weiteres Team stellte ein fiktives Technologieunternehmen mit ausgeprägter Spezialisierung und Demonstrationsprodukt vor. Die Präsentation begann mit einem Motto, jedoch ohne ausreichende Teamvorstellung und klare Agenda. Der Dozent stoppte die Übung, gab gezieltes Feedback und verlangte eine erneute Vorstellung.

Das zentrale Problem zeigte sich später: Die Produktgeschichte passte kaum zum Kerngeschäft des fiktiven Kunden, der industrielle Automatisierung betrieb. Die Formulierung core business war ein Anlass, den Werbemonolog zu beenden und zu fragen, ob in anderen Geschäftsbereichen eine Zusammenarbeit möglich wäre. Es handelt sich um ein fiktives Beispiel; die Leistungsangaben der Beteiligten gelten nicht als überprüfte Tatsachen.

13. Ein angrenzendes Geschäft als Einstieg – ohne erfundene Passung

Nach einer Rückfrage erwähnte der fiktive Kunde einen weiteren Geschäftsbereich mit Bedarf an intelligenten Softwarekomponenten. Das Team erkannte, dass ein Teil der eigenen Kompetenzen womöglich dorthin übertragbar wäre. Dies rechtfertigte die Diskussion eines separaten Termins und eines zukünftigen Proposals.

Die Lehre lautet: Mangelnde Passung zum Kerngeschäft bedeutet nicht zwangsläufig, dass es keine Chance gibt. Verwandte Technologie belegt allerdings noch keine Eignung. Anwendungsumfeld, Randbedingungen, Compliance, Zuständigkeiten und die tatsächliche Übertragbarkeit müssen geprüft werden. Das öffentliche Skript enthält bewusst keine operativen Beschreibungen des fiktiven militärischen Einsatzfalls oder Techniken autonomer Zielbekämpfung.

14. Partnerschaft, Auftragnehmermodell und geistiges Eigentum

Zum Ende des zweiten Szenarios wurde darüber diskutiert, ob das Unternehmen lediglich als Engineering-Dienstleister auftreten oder eine Partnerschaft anstreben sollte. Die Studierenden setzten sich dafür ein, Rechte an bereits bestehenden Entwicklungen zu behalten, statt sämtliches geistiges Eigentum automatisch auf den Kunden zu übertragen.

Entscheidend ist die Unterscheidung zwischen Background IP – Technologien und Ergebnissen, die vor der Zusammenarbeit vorhanden waren – und Foreground IP, den im neuen Projekt entstehenden Ergebnissen. Verträge müssen Eigentum, Lizenzen, Wiederverwendung, Offenlegung unter NDA und weitere Pflichten festhalten. In regulierten oder verteidigungsbezogenen Bereichen sind zudem Export-, Vertrags- und Rechtsvorgaben gesondert zu prüfen. Aus dem Rollenspiel folgt kein allgemeines rechtliches Verbot bestimmter Partnerschaftsmodelle.

15. Verhandlungen mit überprüfbaren Artefakten beenden

In beiden Szenarien wird Erfolg nicht an der Anzahl der Folien oder der Eloquenz gemessen. Entscheidend sind eine dokumentierte Problemstellung, Ansprechperson, bekannte Anforderungen, offene Annahmen, Verantwortliche, nächster Kontakttermin und Proposal-Format. So lässt sich der Discovery-Kontext an Delivery übergeben.

Erreichte Ergebnisse und nur diskutierte Möglichkeiten sind klar zu trennen: Bereitschaft zu einem weiteren Gespräch ist kein gewonnener Auftrag; ein studentisches Gantt-Diagramm ist keine freigegebene Projekt-Baseline; ein fiktives Produkt ist kein Nachweis technischer Lieferfähigkeit.

16. Praktische Artefakte für das studentische Team

Nach dem Rollenspiel sollte das Team die folgenden Unterlagen zur Besprechung in der nächsten Einheit vorbereiten:

• Meeting Brief: Ziel, Rollen, Agenda, Anfangsfragen und gewünschter Ausgang.
• Account Research: kurze öffentliche Fakten über den potenziellen Kunden, davon getrennte Hypothesen.
• Discovery Log: Kundenfragen und Antworten, Prioritäten, Risiken, offene Punkte und Belege der Aussagen.
• Tailored Deck: kurze Vorstellung, passende Stärken, ein bis zwei Fälle, Kooperationsmodelle und nächster Schritt.
• Mini-Proposal: Problem, Scope, Annahmen, Ergebnisse, Phasen, Team, Risiken und Abnahmekriterien.
• Delivery Draft: erste Work Breakdown Structure, Terminabhängigkeiten, Gantt-Diagramm und grober Kostenansatz.

Dies sind Aufgaben und Bewertungskriterien, keine Behauptung, dass alle Teams sie bereits bis zum Ende der Aufnahme erledigt hatten.

17. Bewertungskriterien für die Praxis

Eine überzeugende Leistung zeigt fünf Fähigkeiten: die Präsentation auf die jeweilige Ansprechperson zuschneiden, Vorstellungen und Übergaben diszipliniert gestalten, offene und präzisierende Fragen stellen, Service-, Produkt- und Partnerschaftsmodelle unterscheiden und das Gesprächsergebnis in ein überprüfbares Artefakt überführen.

Zusätzlich zählen Faktenintegrität und Vertraulichkeit. Im Unterricht genannte Namen, Kennzahlen, Verträge oder Produkte dürfen ohne Prüfung nicht als echte Erfolgsgeschichten beworben werden. Technische Details eines fiktiven Verteidigungsszenarios sind für das hier vermittelte Engineering-Business-Verfahren nicht erforderlich.

Fragen zur Selbstkontrolle

• Wie unterscheidet sich ein vereinbarter Termin von einer lediglich verschickten Kalendereinladung?
• Warum können Engagement und Partnership im selben Fall unterschiedliche Geschäftsmodelle bevorzugen?
• Wie erklärt man die Rollen ohne übermäßige Titel und langes Vorstellen?
• Welche Frage führt vom breiten Interesse zur Ebene von Firmware, HAL, Middleware oder Anwendung?
• Warum ist die Reaktion auf eine Folie nur ein Hinweis und kein Bedarfsnachweis?
• Welche Informationen müssen vor einem Lösungsvorschlag festgehalten werden?
• Wann spricht der Technical Lead und wann übernimmt Delivery?
• Welche Elemente des Proposals sollten nach einem RFI noch vor dem Vertragsabschluss vorliegen?
• Was unterscheidet Background IP von Foreground IP?
• Wie verhindert man, dass ein Unterrichtsszenario als verifizierter Kundenfall erscheint?

Was als Nächstes angekündigt wurde

Zum Ende kündigte der Dozent für die folgende Woche eine weitere Simulation mit RFI und RFC an: Er würde vorübergehend die Rolle des Delivery Managers übernehmen, während die Studierenden Projektrollen, Phasen, Gantt-Diagramm, Risiken, Kostenschätzung und ein kurzes Proposal für den fiktiven Kunden ausarbeiten. Das ist ein Plan, keine bereits durchgeführte Einheit oder ein fertiges Ergebnis. Jira/Backlog und eigentliche Implementierung können nach Vereinbarung der Bedingungen folgen.