Customer Success und Produkt: Ausrichtung

Fast jedes CS-Team hat eine Version von beidem: eine Reihe von Advisory-Board-Gesprächen, bei denen leitende Kunden zur strategischen Richtung beitragen, und eine lose Praxis, Kunden einzubeziehen, wenn etwas Neues entwickelt wird. Das Problem ist, dass sehr wenige Teams eine klare Linie zwischen beiden ziehen. Ein Kunde, der im letzten Quartal im Advisory Board saß, wird in ein Prototypen-Review hineingezogen, weil er engagiert ist. Ein PM, der Design-Input möchte, plant eine „Advisory-Sitzung" mit fünf Accounts und führt sie durch einen Figma-Entwurf. Das Vokabular verschwimmt, die Erwartungen verschwimmen, und die Ergebnisse verschwimmen mit ihnen.

Die Unterscheidung ist operativ, nicht philosophisch. Customer Councils und Advisory Boards drehen sich um strategische Richtung. Sie umfassen eine breitere Gruppe von Kunden, laufen in einem quartalsweisen Rhythmus und liefern Input dazu, wohin das Produkt in den nächsten 12-18 Monaten gehen soll. Co-Design dreht sich um ein spezifisches Feature. Es umfasst 3-6 Accounts, läuft über 4-8 Wochen und liefert direkten Input dazu, wie dieses Feature auf Build-Ebene funktionieren soll. Die Zeitverpflichtung, die Kundenerwartung, das Sitzungsformat und was als Erfolg gilt, sind alle unterschiedlich.

Beide zu verwechseln, erzeugt zwei Fehlermuster. Das Advisory Board wird als Co-Design-Einfluss positioniert, den es tatsächlich nicht hat, und erzeugt Erwartungsschulden, wenn sich die Roadmap in Richtungen bewegt, die die Teilnehmer nicht genehmigt haben. Das Co-Design-Engagement wird in ein strategisches Gespräch aufgebläht, dessen Umfang über das hinausgeht, was ein einzelnes Feature erfüllen kann. Beide Misserfolge kosten Beziehungskapital, und beide sind durch operative Disziplin vermeidbar.

Dieser Artikel erklärt, wie Co-Design durchgeführt wird. Artikel 11 behandelt Advisory Boards. Die Grenzlinie zwischen ihnen ist das, womit dieser Artikel beginnt.

Das Customer-Co-Design-Betriebsmodell, das hier definiert wird, ist ausdrücklich von Customer Advisory Boards (Artikel 11 dieser Sammlung) abzugrenzen, die strategische Richtung für eine breitere Gruppe in einem quartalsweisen Rhythmus ansprechen. Co-Design ist operativ, nicht strategisch: Es gestaltet ein spezifisches Feature in der Build-Pipeline mit 3-6 Accounts über 4-8 Wochen. Das Modell hat vier operative Disziplinen: (1) Umfangsdisziplin: Co-Design umfasst ein Feature, keine Produktrichtung; (2) Cohort-Disziplin: 3-6 Accounts, die die akuteste Version des Problems repräsentieren, nicht die treuesten oder größten; (3) Rollendisziplin: Product leitet die Build-Entscheidung, CS moderiert die Sitzung, Engineering beobachtet; (4) Erwartungsdisziplin: Kunden co-designen das Was, Engineers verantworten das Wie, Product trifft die endgültige Entscheidung. Jeder Co-Design-Misserfolg lässt sich auf den Bruch einer dieser vier Disziplinen zurückführen.

Advisory Board vs. Co-Design: Die notwendige Unterscheidung

McKinseys Forschung zum Aufbau kundenorientierter B2B-Organisationen zeigt, dass Unternehmen, die strategischen Advisory-Input mit spezifischem Feature-Co-Design verwechseln, mit Kundendaten enden, die weder die strategische Frage noch die Build-Frage präzise ansprechen. Die Unterscheidung ist operativ, nicht philosophisch, und die Verwechslung ist häufig genug, um sie präzise zu formulieren.

Customer Advisory Boards bringen eine breitere Gruppe, typischerweise 8-15 leitende Kundenvertreter, zusammen, um Input zur strategischen Richtung zu liefern. Die Fragen lauten: Wohin sollen wir das Produkt im nächsten Jahr führen? Welche Probleme erwarten Sie, die wir noch nicht lösen? Wo haben unsere Wettbewerber Vorteile, die Sie gerne schließen würden? Advisory Boards sind zukunftsorientiert und breit. Sie gestalten keine einzelnen Features. Sie gestalten die Produktvision, die die Roadmap antreibt. Der Rhythmus ist quartalsweise. Das Ergebnis ist strategischer Kontext für das PM-Team.

Co-Design bringt eine kleine Kohorte (3-6 Accounts) zusammen, um operativen Input zu einem spezifischen Feature zu liefern, das sich bereits in der Build-Pipeline befindet. Die Fragen lauten: Entspricht dieser Workflow, wie Sie diese Aufgabe tatsächlich ausführen? Wo in diesem Ablauf stoßen Sie auf ein Problem? Was würde diesen Workflow nützlich genug machen, um die Arbeitsweise Ihres Teams zu ändern? Co-Design ist gegenwartsorientiert und eng. Es gestaltet ein spezifisches Feature, das gerade entwickelt wird. Der Rhythmus ist intensiv über ein kurzes Engagement. Das Ergebnis ist umsetzbares Feedback auf Build-Ebene.

Wann Co-Design und wann Advisory-Input ausreicht. Lautet die Frage „Sollen wir diese Kategorie von Fähigkeiten entwickeln?", reicht Advisory-Input. Lautet die Frage „Ist diese spezifische Implementierung dieser Fähigkeit etwas, das unsere Zielnutzer tatsächlich verwenden können?", brauchen Sie Co-Design. Advisory-Input sagt Ihnen, ob Sie in die richtige Richtung entwickeln. Co-Design sagt Ihnen, ob das, was Sie entwickeln, tatsächlich funktionieren wird.

Die praktische Entscheidung: Co-Design ist gerechtfertigt, wenn bei einem spezifischen Feature genug Designambiguität besteht, sodass ein Fehlstart bedeuten würde, erhebliche Teile nach dem Launch neu zu entwickeln, und wenn Sie Kunden haben, die den spezifischen Anwendungsfall und die Domänenexpertise besitzen, um eine vorgeschlagene Lösung zu bewerten.

Wichtige Fakten: Co-Design-Programmergebnisse

Features, die mit strukturierten Kunden-Co-Design-Sitzungen entwickelt wurden, weisen 90 Tage nach GA eine um 41 % höhere Akzeptanzrate auf, verglichen mit Features, die nur mit Advisory-Input entwickelt wurden (Pendo, 2024).

PM-moderierte Co-Design-Sitzungen produzieren 35 % weniger kritisches Feedback als CS-moderierte Sitzungen, weil Teilnehmer ihre Kritik abschwächen, wenn die Person, die das Bewertete gebaut hat, im Raum ist (UserTesting, 2024).

Co-Design-Engagements, die ohne eine formelle Abschlusssitzung enden, haben 2,1-mal höhere Raten von teilnehmerseitig berichteten Erwartungsenttäuschungen beim GA-Launch, verglichen mit Engagements mit einem strukturierten Debrief-Call (Gainsight, 2024).

Wer zu Co-Design eingeladen wird (und wer nicht)

Die Auswahlkriterien sind spezifischer als für ein Beta-Programm oder ein Advisory Board, und die Kosten eines Fehlers dabei sind höher. Eine schlechte Advisory-Board-Auswahl liefert vagen strategischen Input. Eine schlechte Co-Design-Auswahl führt zu Build-Level-Entscheidungen basierend auf dem falschen Anwendungsfall.

„Features, die mit strukturierten Kunden-Co-Design-Sitzungen entwickelt wurden, weisen 90 Tage nach GA eine um 41 % höhere Akzeptanzrate auf, verglichen mit Features, die nur mit Advisory-Input entwickelt wurden." (Pendo, 2024)

Der Problemakuität-Filter. Das erste Kriterium: Hat dieser Account das spezifische Problem, das das Feature lösen soll, und hat er es akut genug, um aussagekräftiges Feedback zu einer vorgeschlagenen Lösung zu geben? Nicht „begegnen sie der allgemeinen Problemkategorie", sondern „ist dieses Problem für sie derzeit ein echtes operatives Hindernis?" Accounts, die das Problem theoretisch haben („wir könnten dieses Problem haben, wenn unser Team wachsen würde"), können eine Lösung nicht mit derselben Spezifität bewerten wie Accounts, die es operativ haben, jeden Tag.

Das CS-Health-Gate. Nur grüne oder gelbe Health Scores. Co-Design mit roten Accounts ist Extraktion, keine Zusammenarbeit. Ein Kunde, der eine aktive Support-Krise, einen Budgetkonflikt oder eine ins Stocken geratene Implementierung verwaltet, hat nicht die Kapazität für ehrliches Produktfeedback. Er verwaltet seine eigene Situation. Und wenn die Co-Design-Erfahrung frustrierend ist (was bei frühen Feature-Arbeiten oft der Fall ist), verstärkt sie eine bereits belastete Beziehung. Das CS & Product Alignment Glossar definiert Health-Score-Stufen und das gemeinsame Vokabular, das CS und Product benötigen, um dieses Gate konsistent anzuwenden.

Der Fähigkeitsfilter. Hat dieser Kunde die Domänenexpertise, um zu beurteilen, ob eine vorgeschlagene Lösung das Problem tatsächlich löst? Ein Kunde, der das Problem hat, aber nicht die technische oder operative Kompetenz besitzt, „dieser Workflow passt nicht zu unserem Prozess" von „dieser Workflow ist verwirrend" zu unterscheiden, ist ein eingeschränkter Co-Design-Beitragender. Sie benötigen Accounts, bei denen der Praktiker, der an der Sitzung teilnimmt, genau erklären kann, wie er die Aufgabe derzeit ausführt, die das Feature ersetzen soll, denn dieses Verständnis macht sein Feedback auf die vorgeschlagene Lösung präzise statt impressionistisch.

Die Kohorten-Obergrenze. 3-6 Accounts. Das ist keine weiche Richtlinie. Es ist die operative Realität dessen, was ein PM verwalten und womit ein CSM über ein 4-8-wöchiges Engagement sinnvoll arbeiten kann. Sechs ist bereits ehrgeizig. Acht wird zu einem Komitee. Bei zehn führen Sie eine Beta durch, kein Co-Design-Engagement, und haben die Intimität verloren, die Co-Design-Feedback von Umfragedaten unterscheidet.

Die Einladungsformulierung ist genauso wichtig wie die Auswahl. „Helfen Sie uns, das richtig zu entwickeln" ist die richtige Formulierung. „Geben Sie uns Ihre Wunschliste" ist die falsche. Die Einladung sollte spezifisch bezüglich des Feature-Umfangs sein, die Zeitverpflichtung explizit machen (typischerweise 3-5 Sitzungen über 4-8 Wochen, jeweils 60-90 Minuten), klar machen, dass es um Design-Input geht und nicht um Roadmap-Einfluss, und ehrlich darüber sein, dass die endgültige Build-Entscheidung bei Product liegt, nicht bei der Co-Design-Kohorte. Mit der richtigen Kohorte bestimmt die Engagement-Struktur, ob die Sitzungen echte Signale liefern.

Die Co-Design-Engagement-Struktur

Ein Co-Design-Engagement, das länger als 8 Wochen dauert, signalisiert meist Scope Creep. Ein Co-Design-Engagement mit mehr als 5 Sitzungen signalisiert meist, dass das Problem von Anfang an nicht gut genug definiert war. Die folgende Struktur gilt für ein gut abgegrenztes Engagement.

Vorarbeit: Product teilt die Problemstellung und Randbedingungen. Vor der ersten Sitzung erhalten die Teilnehmer ein schriftliches Briefing vom PM: das zu lösende Problem, warum der vorgeschlagene Ansatz gewählt wurde, und welche Randbedingungen nicht verhandelbar sind (technische Einschränkungen, regulatorische Anforderungen, bestehende Architekturentscheidungen). Kunden co-designen nicht im Vakuum. Sie brauchen Kontext darüber, was möglich ist, bevor sie sinnvollen Input dazu geben können, was am besten ist.

Sitzung 1: Problemvalidierung. Der Zweck dieser Sitzung ist nicht, dem Kunden eine Lösung zu zeigen. Es geht darum, zu validieren, dass das Verständnis des Problems durch Product mit der gelebten Erfahrung des Kunden übereinstimmt. Der PM präsentiert die Problemstellung. Der Kunde reagiert: „Beschreibt das genau, womit Sie es zu tun haben?" Diskrepanzen hier (und es gibt fast immer welche) sind der wertvollste Output des gesamten Engagements. Sie tauchen auf, bevor Build-Arbeit festgelegt ist.

Sitzung 2: Prototypen-Feedback. Der PM präsentiert einen frühen Prototypen oder Workflow-Entwurf. Die Aufgabe des Kunden: ihn so durchzugehen, wie er ihn tatsächlich nutzen würde, dabei seine Reaktionen zu verbalisieren. Nicht „Gefällt Ihnen das?", sondern „Zeigen Sie mir, was Sie als nächstes tun würden." Der CSM erfasst Reibungspunkte, Momente der Verwirrung und Workarounds, die der Kunde spontan vorschlägt. Engineering beobachtet und macht Notizen, präsentiert aber nichts, verteidigt nichts und erklärt nichts. Sie sind da, um direkt zuzuhören, nicht um Entscheidungen zu rechtfertigen.

Sitzung 3: Lösungsiteration. Der PM präsentiert den überarbeiteten Prototypen, der das Feedback aus Sitzung 2 berücksichtigt. Zweck: bestätigen, dass die Änderungen die Reibung behoben haben, neue durch die Änderungen eingeführte Probleme zu Tage fördern und auf ein Design hinzuwirken, das funktioniert. Diese Sitzung ist typischerweise kürzer als Sitzung 2. Wenn die Iteration gut war, gibt es weniger zu beanstanden.

Sitzungen 4-5 (falls erforderlich): Abschließende Klärung und Randfälle. Diese Sitzungen sind für Teilnehmer, deren Anwendungsfälle komplex genug sind, dass die Sitzungen 1-3 nicht vollständig geklärt haben, wie das Feature für sie funktioniert. Nicht jede Kohorte benötigt Sitzungen 4-5. Wenn ein dreisitziges Engagement ein klares genug Signal liefert, um das Design zu finalisieren, verschwendet das Hinzufügen von Sitzungen der Struktur zuliebe die Zeit der Teilnehmer und riskiert, den Goodwill zu erodieren, auf dem das Programm basiert.

Anwesenheitsregeln. Die Arbeit des MIT Media Lab zum community-basierten Technologie-Co-Design bestätigt, dass der Wert von Co-Design speziell aus dem „Co" entsteht (der Teilnahmestruktur selbst, nicht nur den Outputs), weshalb das Anwesenheitsmodell des Anbieters hier die Rollen trennt, anstatt sie in einer einzigen Product-Team-Präsenz zu bündeln. Vom Anbieter: PM leitet, CSM moderiert, Engineering beobachtet. Der PM ist da, um den Anwendungsfall zu hören und Echtzeit-Build-Entscheidungen darüber zu treffen, welches Feedback eingearbeitet wird. Der CSM ist da, um die Sitzungsdynamik zu steuern: stille Teilnehmer zu motivieren, Teilnehmer umzuleiten, die das gesamte Produkt statt des spezifischen Features neu entwerfen, und relationale Signale aufzufangen, die dem PM entgehen könnten. Engineering ist da, um den Anwendungsfall in der Sprache des Kunden zu hören, nicht um technische Einschränkungen zu präsentieren oder Implementierungsentscheidungen zu verteidigen.

Vom Kunden: der Praktiker, der das Problem täglich erlebt, nicht der Executive Sponsor. Ein Führungskraft, der das Problem von seinem Team hört, ist ein nützlicher strategischer Befürworter. Er ist ein schlechter Co-Design-Teilnehmer, weil ihm die operative Spezifität fehlt, um zu beurteilen, ob eine vorgeschlagene Lösung auf Workflow-Ebene funktioniert. Der richtige Teilnehmer kann sagen: „Wenn ich diese Aufgabe erledige, gehe ich so vor, und der vorgeschlagene Ablauf scheitert bei Schritt drei wegen X."

Die CS-Rolle in Co-Design-Sitzungen

„PM-moderierte Co-Design-Sitzungen produzieren 35 % weniger kritisches Feedback als CS-moderierte Sitzungen, weil Teilnehmer ihre Kritik abschwächen, wenn die Person, die das Bewertete gebaut hat, im Raum ist." (UserTesting, 2024)

CS moderiert; CS plädiert nicht. Das ist die schwierigste Linie zu halten. Die Aufgabe des CSM in einer Co-Design-Sitzung ist nicht, den Kunden ein gutes Gefühl gegenüber dem Produkt zu geben oder die Beziehung vor kritischem Feedback zu schützen. Es geht darum, ehrliche Signale zu gewinnen: Nachfragen, wenn das Feedback des Kunden vage ist, Unzufriedenheit aufzudecken, die der Kunde höflich statt direkt ausdrückt, und das Protokoll nicht abzumildern.

Den dominanten Teilnehmer managen. Fast jede Co-Design-Kohorte hat einen: den Kunden, der engagiert, artikuliert und laut ist und dessen Meinungen die anderen Teilnehmer übertönen. Die Moderationsaufgabe des CSM besteht darin, die Redezeit aktiv zu verteilen: „Wir haben viel von [Account A] dazu gehört. [Account B], wie kommt das für den Workflow Ihres Teams an?" Die lauteste Stimme in einer Co-Design-Sitzung ist selten die repräsentativste.

Feedback in strukturiertem Output-Format erfassen. Das Ergebnis jeder Sitzung ist weder ein Transkript noch eine Zusammenfassung. Es ist ein strukturierter Feedback-Datensatz, auf den Product direkt verweisen kann, wenn Build-Entscheidungen getroffen werden. Format: Reibungspunkt (spezifisch, workflow-kontextualisiert) / welcher Account ihn aufgebracht hat / Schweregrad (Blocker / signifikant / geringfügig) / vorgeschlagene Lösung des Kunden (wenn angeboten) / erste Einschätzung des PM (einarbeiten / ablehnen / weiter untersuchen). Dieses Format wird vor Beginn des Engagements vereinbart. CSMs improvisieren es nicht von Sitzung zu Sitzung. Das Playbook zur systematischen Feedback-Erfassung bietet die vollständige Taxonomie zur Übersetzung von Sitzungsnotizen in Backlog-fähige Datensätze.

Scope Creep in Echtzeit erkennen. Wenn ein Teilnehmer beginnt, das gesamte Produkt statt des spezifischen Features neu zu entwerfen („Da wir schon darüber sprechen, was wäre, wenn Sie auch die gesamte Funktionsweise des Dashboards überarbeiten würden?"), leitet der CSM um: „Das ist ein toller breiterer Input, und wir werden ihn separat erfassen. Für die heutige Sitzung möchten wir uns auf [spezifischen Feature-Umfang] konzentrieren, damit wir tief genug gehen können, um nützlich zu sein." Diese Umleitung ist eine CSM-Verantwortung, keine PM-Verantwortung. Die Anwesenheit des PM im Raum macht es für ihn schwieriger umzuleiten, ohne defensiv zu wirken.

Die nicht verhandelbaren Punkte von Product im Co-Design

Die Build-Entscheidung gehört Product. Immer. Co-Design ist Input dazu, wie ein Feature entwickelt wird, keine Delegation der Build-Entscheidung an ein Kundenkomitee. Das muss bei der Einladungsformulierung gesagt und zu Beginn jeder Sitzung bekräftigt werden. „Wir möchten Ihre Perspektive darauf, ob dieser Ansatz für Ihren Workflow funktioniert. Die endgültige Entscheidung darüber, was wir entwickeln, liegt bei uns, und wir werden transparent mit Ihnen sein, welche Inputs wir einarbeiten und warum."

Technische Randbedingungen sind nicht verhandelbar und müssen vorab kommuniziert werden. Co-Design-Sitzungen, bei denen Teilnehmer ihre ideale Lösung entwerfen und der PM dann erklären muss, warum davon technisch nichts möglich ist, verschwenden die Zeit aller und erzeugen Erwartungsschulden. Vor Sitzung 1 sollte das schriftliche Briefing klar formulieren: „Das ist technisch in diesem Design festgelegt. Hier liegt Ihr echter Einflussbereich." Kunden, die den Raum der Randbedingungen verstehen, entwerfen darin. Kunden, die ihn nicht verstehen, entwerfen daran vorbei und liefern nicht umsetzbares Feedback.

Kunden co-designen das Was; Engineers und PMs verantworten das Wie. Ein Teilnehmer kann sagen: „Ich muss in der Lage sein, die Eigentümerschaft einer Aufgabe in großen Mengen zu übertragen, ohne den Prüfpfad zu verlieren." Das ist ein Was. Wie das technisch implementiert wird (welches Datenmodell, welches API-Muster, welche UI-Komponente), ist eine Engineering-Entscheidung. Die Grenzlinie zwischen Was und Wie ist der Ort, an dem die Umfangsdisziplin liegt.

Wenn Co-Design-Teilnehmer untereinander nicht einig sind. Es passiert in fast jedem Multi-Account-Engagement, weil Accounts unterschiedliche Workflows, unterschiedliche Randbedingungen und unterschiedliche Definitionen von „offensichtlich" haben. Product schlichtet. Nicht indem es den Meinungsunterschied mittelt („wir machen eine Version, die beide teilweise zufriedenstellt"), sondern durch eine explizite Entscheidung: „Wir haben hier zwei unterschiedliche Workflow-Modelle gehört. Wir werden für das Modell von [Account A] entwickeln, weil es enger an unser primäres ICP angelehnt ist. Für [Account B] würden wir folgendes vorschlagen, um Ihren Workflow an das Feature anzupassen." Transparente Schlichtung ist besser als so zu tun, als ob der Meinungsunterschied nicht existiert.

Erwartungsmanagement während des gesamten Engagements

Das Erwartungsrisiko beim Co-Design unterscheidet sich von dem bei einem Advisory Board. Advisory-Board-Teilnehmer erwarten strategischen Einfluss. Co-Design-Teilnehmer erwarten, dass ihr spezifischer Workflow in dem widergespiegelt wird, was ausgeliefert wird. Wenn das fertige Feature nicht genau so aussieht wie das, was sie entworfen haben, empfinden Teilnehmer das Co-Design als Inszenierung statt echte Zusammenarbeit.

Kommunizieren Sie in Sitzung 1 das Modell explizit. „Sie sind hier, weil Sie die akuteste Version des Problems, das wir lösen, haben und die Domänenexpertise, um uns zu sagen, ob unsere vorgeschlagene Lösung tatsächlich funktioniert. Ihr Input wird direkt beeinflussen, was wir entwickeln. Aber Sie sind nicht der einzige Input. Wir arbeiten auch innerhalb technischer Randbedingungen, balancieren mehrere Anwendungsfälle aus und treffen Produktentscheidungen, die möglicherweise nicht vollständig die Präferenz eines einzelnen Accounts widerspiegeln. Wir werden transparent mit Ihnen sein, was wir einarbeiten und was nicht, und warum."

Wie mit Teilnehmern umzugehen ist, deren Ideen nicht eingearbeitet wurden. Der CSM nimmt proaktiv Kontakt auf, bevor das Feature ausgeliefert wird. „Wir haben [spezifischen Input] in Sitzung 3 besprochen. Wir haben letztendlich entschieden, ihn in diesem Release nicht zu implementieren, weil [spezifischer Grund]. Ich möchte, dass Sie das direkt von mir erfahren, bevor Sie das Feature bei der GA sehen." Dieses Gespräch, geführt bevor der Teilnehmer die Lücke selbst entdeckt, ist eine beziehungserhaltende Handlung. Danach geführt wirkt es wie Schadensmanagement.

Der Debrief-Call ist nicht optional. HBRs Forschung zum Einholen ehrlichen Kundenfeedbacks zeigt, dass der Abschluss eines Feedback-Engagements der Moment ist, an dem Vertrauen entweder bestätigt oder gebrochen wird. Kunden müssen sehen, dass ihr Input ernst genommen wurde, nicht nur verarbeitet. Jedes Co-Design-Engagement endet mit einem 30-minütigen Debrief-Call, bei dem der PM die Co-Design-Teilnehmer durch folgendes führt: was in den Build aufgenommen wurde, was nicht, und warum. Das ist der formale Abschluss des Engagements. Teilnehmer, die keinen Debrief erhalten (die das Engagement als „Wir haben unsere Zeit gegeben und dann wurde das Feature einfach ausgeliefert" erleben), sind die Quelle des Co-Design-Reputationsproblems, das künftige Rekrutierung schwieriger macht.

Wenn Co-Design schief läuft

Drei Fehlermuster decken das meiste ab, was schief läuft, und jedes hat einen spezifischen Fix.

Scope Creep: Kunden entwerfen das gesamte Produkt. Die Sitzung ist vom spezifischen Feature zu einem Gespräch über die gesamte Produkterfahrung abgedriftet. Ursache: Die Einladungsformulierung war zu breit („helfen Sie uns, das Produkt zu verbessern"), der CSM hat nicht früh genug umgeleitet, oder der PM begann Fragen zu stellen, die einen breiteren Umfang öffneten („und was sonst würde diese Arbeitskategorie für Sie besser machen?"). Fix: Umfang zu Beginn jeder Sitzung neu formulieren, den CSM darauf schulen, sichtbar und ohne Entschuldigung umzuleiten, und PM-Fragen eng an das co-designte Feature zu binden.

Beziehungskapitulation: PM stimmt allem zu. Der PM ist so sehr auf die Aufrechterhaltung einer positiven Teilnehmerbeziehung fokussiert, dass er Inputs signalisiert zuzustimmen, die er nicht umzusetzen beabsichtigt, um Konflikte im Raum zu vermeiden. Das erzeugt zwei Probleme: Teilnehmer, die sich während der Sitzungen bestätigt fühlen und bei der GA verraten fühlen, und einen Feedback-Datensatz, der Verpflichtungen überrepräsentiert, die nicht existieren. Fix: Der CSM (nicht der PM) steuert den Sitzungston. Die Aufgabe des PM ist es, zuzuhören und aufzuzeichnen, nicht auf jeden Vorschlag zustimmend zu reagieren. Das strukturierte Output-Format (einarbeiten / ablehnen / weiter untersuchen) erzwingt eine explizite Anerkennung, welche Inputs berücksichtigt werden und welche nicht.

Kohorten-Bias: Teilnehmer repräsentieren nicht das breitere ICP. Die Co-Design-Kohorte wurde ausgewählt, weil sie verfügbar und engagiert war, nicht weil sie den Zielanwendungsfall repräsentiert. Feedback spiegelt ihren spezifischen Workflow wider, der ein Randfall ist, kein Kernanwendungsfall. Features, die nach dieser Spezifikation gebaut wurden, funktionieren gut für Co-Design-Teilnehmer und schlecht für die allgemeine Kundenbasis. Fix: Den Problemakuität-Filter bei der Auswahl strikt anwenden. Wenn die Accounts, die das Problem am akutesten haben, nicht gesund oder verfügbar genug sind, um teilzunehmen, verzögern Sie das Co-Design, bis bessere Kandidaten identifizierbar sind. Ersetzen Sie sie nicht durch Teilnehmer, die die Beziehungskriterien besser erfüllen als die Anwendungsfall-Kriterien.

Nach dem Co-Design: Das Engagement abschließen

Anerkennung der Teilnehmer ohne Überschuldung zukünftiger Zugänge. Co-Design-Teilnehmer haben Zeit und Vertrauen investiert. Der Abschluss des Engagements sollte das spezifisch anerkennen: „Sie haben uns [N Sitzungen / N Stunden] über [N Wochen] gegeben. Die [spezifischen Features des Ausgelieferten] spiegeln direkt wider, was Sie uns gesagt haben. Danke." Das ist das richtige Maß an Anerkennung. Zu viel zu versprechen („Wir werden sicherstellen, dass Sie der erste Account sind, an den wir uns für das nächste Feature in diesem Bereich wenden") erzeugt Einladungsschulden im nächsten Co-Design-Programm, bevor es überhaupt beginnt.

Co-Design-Teilnehmer sehen das finale Feature vor der GA. Das ist nicht optional. Teilnehmer, die an vier Sitzungen teilgenommen haben und dann die GA-Ankündigung zur gleichen Zeit wie jeder andere Kunde sehen, empfinden, dass ihr Input absorbiert, nicht gewürdigt wurde. Die Reihenfolge: PM teilt das finale Feature mit Co-Design-Teilnehmern 1-2 Wochen vor der GA. Teilnehmer haben die Möglichkeit, etwas Kritisches zu markieren, das übersehen wurde. Dann wird es an alle ausgeliefert. Die Debrief-Call-Struktur, die schriftliche Zusammenfassung und die 48-Stunden-Rückmeldung sind alle im Artikel Schließen der Feedback-Schleife beschrieben. Dieser Rhythmus gilt hier genauso wie für Beta- und Advisory-Programme.

Retrospektive vor dem nächsten Co-Design. Das Engagement-Debrief ist nicht nur für Teilnehmer. Es ist für das interne Team. Was hat das Sitzungsformat produziert, das nützlich war? Welches Feedback-Format hat funktioniert? Wurden die richtigen Accounts ausgewählt? Was würden wir an der Einladungsformulierung ändern? Eine 60-minütige interne Retrospektive nach jedem Co-Design-Engagement verbessert die Qualität des nächsten und reduziert mit der Zeit die Fehlerrate.

Überlegungen für den Mittelstand

Co-Design ist ressourcenintensiv. Ein mittelgroßes Unternehmen ohne eine dedizierte UX-Forschungsfunktion kann es dennoch durchführen, muss aber die Erwartungen entsprechend anpassen. Die Minimalversion: ein PM, ein CSM, drei Accounts, drei Sitzungen, kein Figma-Prototyp erforderlich. Ein früher Workflow-Entwurf in einfacher Sprache funktioniert. Der PM liest den strukturierten Output, der CSM moderiert, und der Output ist spezifisch genug, um den Build zu informieren.

„Co-Design-Engagements, die ohne eine formelle Abschlusssitzung enden, haben 2,1-mal höhere Raten von teilnehmerseitig berichteten Erwartungsenttäuschungen beim GA-Launch, verglichen mit Engagements mit einem strukturierten Debrief-Call." (Gainsight, 2024)

Was sich nicht verkleinern lässt: der Debrief-Call, die Problemakuität-Auswahlkriterien und die explizite Erwartungsformulierung in Sitzung 1. Das sind die tragenden Elemente. Alles andere kann für kleinere Teams vereinfacht werden. Die Verfolgung, welche Co-Design-Teilnehmer nach der GA aktivierungsbereit sind, ist der Punkt, an dem die Identifizierung von Akzeptanzhindernissen ansetzt. Das Co-Design-Team kennt bereits die Reibungspunkte; das Post-Sale-Team benötigt dieses Wissen, um die Aktivierung für die breitere Basis zu beschleunigen.

Rework-Analyse: Co-Design-Programme sind operativ schlank (3-6 Accounts, 3-5 Sitzungen, 4-8 Wochen), erfordern jedoch eine rigorose Verfolgung von Sitzungsergebnissen, Teilnehmer-Health-Scores und Feedback-Bearbeitungsstatus über mehrere gleichzeitige Gespräche. CS-Teams im Mittelstand, die Co-Design in Rework durchführen, können Projekt-Task-Tracking verwenden, um die Sitzungsstruktur zu verwalten, Feedback-Datensätze mit Account-Gesundheit zu verknüpfen und den Problemakuität-Filter neben ICP-Daten bereitzustellen, ohne ein separates Forschungsmanagementsystem aufzubauen. Das strukturierte Feedback-Format (Reibungspunkt / Schweregrad / PM-Bearbeitungsstatus) entspricht direkt Reworks Task- und Kommentarmodell.

Häufig gestellte Fragen

Was ist das Customer-Co-Design-Betriebsmodell?

Das Customer-Co-Design-Betriebsmodell ist die operative Struktur für die Durchführung von Feature-Co-Design mit 3-6 ausgewählten Kunden über 4-8 Wochen. Es ist ausdrücklich von Customer Advisory Boards abzugrenzen, die strategische Richtung für eine breitere Gruppe quartalsweise ansprechen. Co-Design gestaltet ein spezifisches Feature in der Build-Pipeline. Das Modell läuft auf vier Disziplinen: Umfang (ein Feature, keine Produktrichtung), Kohorte (Problemakuität-Auswahl, keine Loyalitätsauswahl), Rolle (CS moderiert, Product leitet die Build-Entscheidung, Engineering beobachtet) und Erwartung (Kunden co-designen das Was, Engineers verantworten das Wie).

Wie unterscheidet sich Co-Design von einem Customer Advisory Board?

Advisory Boards bringen 8-15 leitende Kunden quartalsweise zusammen, um zur strategischen Richtung beizutragen: Wohin soll das Produkt in den nächsten 12-18 Monaten gehen? Co-Design bringt 3-6 Accounts über 4-8 Wochen zusammen, um Build-Level-Feedback zu einem spezifischen Feature bereitzustellen, das sich bereits in der Pipeline befindet. Advisory-Input beantwortet „Sollen wir diese Kategorie von Fähigkeiten entwickeln?" Co-Design beantwortet „Wird diese spezifische Implementierung tatsächlich für unsere Zielnutzer funktionieren?" Beide zu verwechseln führt zu Advisory-Ermüdung und Co-Design-Scope-Creep.

Wer sollte zu Co-Design-Sitzungen eingeladen werden?

Die Auswahlkriterien haben drei Filter: (1) Problemakuität: Der Account hat das spezifische Problem, das das Feature lösen soll, operativ und akut, nicht theoretisch; (2) Health Score: nur grün oder gelb; rote Accounts verwalten ihre eigene Situation und können ein neues Feature nicht objektiv bewerten; (3) Fähigkeit: Der Praktiker, der teilnimmt, kann genau beschreiben, wie er die Aufgabe, die das Feature ersetzen wird, derzeit ausführt, weil diese operative Spezifität sein Feedback präzise statt impressionistisch macht. Kohorten-Obergrenze sind 6 Accounts. Darüber hinaus führen Sie eine Beta durch, kein Co-Design-Engagement.

Warum sollte CS Co-Design-Sitzungen moderieren, nicht Product?

PM-moderierte Co-Design-Sitzungen produzieren 35 % weniger kritisches Feedback als CS-moderierte Sitzungen, weil Teilnehmer ihre Kritik abschwächen, wenn die Person, die das Bewertete gebaut hat, im Raum ist (UserTesting, 2024). CS-Moderatoren schaffen eine Trennung zwischen der Beziehungsebene und der Bewertungsebene. Die Aufgabe des CSM ist es, Unzufriedenheit aufzudecken, die Teilnehmer höflich statt direkt ausdrücken, Scope Creep in Echtzeit umzuleiten und den strukturierten Feedback-Datensatz zu erfassen, ohne das Protokoll abzumildern. Der PM beobachtet und trifft Echtzeit-Build-Entscheidungen; Engineering beobachtet und hört den Anwendungsfall in der Sprache des Kunden.

Was passiert, wenn Co-Design-Teilnehmer untereinander nicht einig sind?

Product schlichtet. Nicht indem es den Meinungsunterschied mittelt oder so tut, als ob er nicht existiert, sondern durch eine explizite Entscheidung: „Wir haben hier zwei unterschiedliche Workflow-Modelle gehört. Wir werden für das Modell von Account A entwickeln, weil es enger an unser primäres ICP angelehnt ist. Für Account B würden wir folgendes vorschlagen, um Ihren Workflow an das Feature anzupassen." Transparente Schlichtung ist besser für die Beziehung als vager Kompromiss. Teilnehmer, die verstehen, warum ihr Modell nicht gewählt wurde, respektieren die Entscheidung. Teilnehmer, die eine halbe Lösung erhalten und später feststellen, dass sie für keinen der Workflows passt, fühlen sich getäuscht.

Was sollte der Co-Design-Debrief-Call beinhalten?

Der Debrief-Call ist eine 30-minütige Sitzung mit PM und CSM, die mit Co-Design-Teilnehmern vor der GA abgehalten wird. Er umfasst: was in den Build aufgenommen wurde, was nicht, und warum. Co-Design-Engagements, die ohne eine formelle Abschlusssitzung enden, haben 2,1-mal höhere Raten von teilnehmerseitig berichteten Erwartungsenttäuschungen beim GA-Launch (Gainsight, 2024). Eine schriftliche Zusammenfassung folgt innerhalb von 48 Stunden. Teilnehmer, die vier Sitzungen beigetragen haben und einen Debrief erhalten, fühlen sich wirklich konsultiert. Teilnehmer, die die GA-Ankündigung zur gleichen Zeit wie jeder andere Kunde sehen, fühlen sich ausgenutzt.

Wie lange sollte ein Co-Design-Engagement dauern?

Ein gut abgegrenztes Co-Design-Engagement läuft 3-5 Sitzungen über 4-8 Wochen. Engagements, die über 8 Wochen hinausgehen, signalisieren typischerweise, dass das Problem von Anfang an nicht gut genug definiert war, oder dass der Umfang in Territorium hineingekrochen ist, das kein einzelnes Feature befriedigen kann. Programme mit mehr als 5 Sitzungen zeigen in 73 % der mittelständischen Fälle eine abnehmende Sitzungsqualität aufgrund von Teilnehmererschöpfung (ProductLed, 2024). Der Debrief-Call ist nicht optional. Alles andere kann für kleinere Teams vereinfacht werden. Aber der Debrief und die Problemakuität-Auswahlkriterien sind die tragenden Elemente des Modells.

Mehr erfahren

Tara Minh

Senior Operations & Growth Strategist