Als alle Engineers zu Sales-Calls verpflichtet wurden, wurde die Plattform in nur zwei Wochen komplett neu geschrieben

• Ein Startup ließ Engineers direkt an Sales-Calls teilnehmen und veränderte dadurch grundlegend die Art und Weise, wie das Produkt entwickelt wurde
• In den Sales-Calls erfuhren sie, dass Produkte von Wettbewerbern für nichttechnische Nutzer viel zu komplex seien und dass Kunden statt Logs oder Metriken lediglich ein Bestätigungszeichen (grüner Haken) wollten sowie fragten, ob „nicht einfach jemand das für sie übernehmen könnte“
• Dadurch begann das zuvor backendzentrierte Team, die Perspektive der Nutzer zu verstehen, und entwarf auch ohne Eingreifen eines PM eigenständig eine neue Architektur
• In nur zwei Wochen reduzierte das Team die Plattform um 60 % an Funktionen, fügte eine Fortschrittsanzeige hinzu, baute eine Slack-Integration sowie Done-for-you-Workflows auf und erreichte dadurch letztlich eine Reduktion der Support-Tickets um 70 %
• Die Lehre aus dieser Erfahrung war, dass Nutzer nur eine Problemlösung wollen und sich nicht für eleganten Code interessieren und dass Funktionen Kosten verursachen – nicht in Form von Code, sondern als Verwirrung bei den Nutzern

---

Hintergrund und Experiment

• Ein Senior DevOps Engineer war gegen die Teilnahme an Sales-Calls, stimmte aber unter der Bedingung zu, es zumindest mit fünf Calls zu versuchen
• Der Gründer war überzeugt, dass sich das Produktdesign nur dann ändern würde, wenn Engineers die Sprache und Probleme der Kunden direkt hörten

Erkenntnisse aus den Sales-Calls

• Es wurde gesagt, dass Produkte von Wettbewerbern für nichttechnische Nutzer zu komplex seien
• Kunden wollten statt komplexer Metriken eine einfache, intuitive Bestätigung wie einen grünen Haken
• Viele Kunden verlangten einen „Managed Service“ und wollten die Problemlösung selbst eher auslagern als das Produkt nur zu benutzen

Ergebnis der Produkt-Neuschreibung

• Das Team entfernte 60 % der bestehenden Funktionen und konzentrierte sich auf das Wesentliche
• Eine einfache Fortschrittsanzeige verbesserte die User Experience
• Die Slack-Integration vereinfachte den Anfragefluss
• Done-for-you-Workflows spiegelten die Kundenanforderungen direkt wider
• Am Ende sanken die Support-Tickets um 70 %, und Nutzbarkeit sowie Zufriedenheit mit dem Produkt verbesserten sich deutlich

Zentrale Lehren

• Nutzer wollen nicht elegante technische Lösungen, sondern die Problemlösung selbst
• Das Verständnis der Nutzer ist wichtiger als technische Korrektheit
• Jede Funktion verursacht Kosten – nicht als Code, sondern als Verwirrung bei den Nutzern

Veränderung der Teamkultur

• Danach führte das Unternehmen verpflichtend ein, dass alle Engineers pro Quartal an fünf Sales-Calls teilnehmen
• Es wurde Teil der Kultur, dass Engineers direkt die Ermüdung der Kunden hören und Anforderungen wie „es soll einfach funktionieren“ erleben, um mehr Produktgespür zu entwickeln

---

Wichtige Zusammenfassung der Reddit-Kommentare

• Debatte über die Rolle des PM
  • Einige meinten, das eigentliche Problem sei das Fehlen eines guten Product Managers, und es sei ineffizient, wenn Engineers zusätzlich Kundengespräche führen müssten
  • Andere entgegneten, ein PM sei oft nur ein Übersetzer und die besten Ergebnisse entstünden, wenn Engineers die Kundenprobleme direkt selbst verantworteten
• Wert des direkten Kundenkontakts
  • In mehreren Kommentaren wurde betont, dass die Erfahrung, wenn Engineers direkt die Stimme der Nutzer hören, zu besonders starken Erkenntnissen führt
  • Gerade in Startups in einer frühen Phase oder in kleinen Teams übernehmen Engineers oft teilweise die PM-Rolle
• Kritische Sichtweisen
  • Kritik lautete, dies sei schlicht ein Versagen von Führung oder Kultur, das auf Engineers abgewälzt werde
  • Andere fragten, ob das Streichen von Funktionen und Vereinfachen wirklich eine Verbesserung sei, und warnten langfristig davor, Power User und Anforderungen an fortgeschrittene Funktionen zu ignorieren
• Geteilte positive Beispiele
  • Aus Branchen wie Banken oder Medizintechnik berichteten viele von ähnlichen Modellen, bei denen alle Mitarbeitenden Customer Support oder Vertrieb erleben
  • Es bestand breite Zustimmung, dass Dogfooding oder die Erfahrung, direkt vor Kunden zu stehen, Produktqualität und Kultur verbessert
• Übergreifende Implikationen
  • Kundenprobleme direkt erlebbar zu machen, ist ein starkes Lernwerkzeug,
  • zugleich zeigte die Diskussion aber, dass dies langfristig mit professioneller PM-, UX- und Design-Kompetenz kombiniert werden muss, um eine ausgewogene Produktstrategie zu schaffen

[meteorizer]

Letztlich ist es wohl eine Frage der Effizienz.
Direkte Abstimmung mit Kunden hat zwar wirklich viele Vorteile,
aber durch häufige Kommunikation wie Meetings und Anrufe wird die Kontinuität der Arbeit oft unterbrochen, und es bleibt weniger Zeit, die in die Entwicklung investiert werden kann.
Dann müsste das Unternehmen wohl einen Einstellungsplan aufstellen, um auf die gesunkene Produktivität zu reagieren.
Das Problem ist, dass sie das meist nicht vorhaben.
Letztlich steigt wegen des Zeitmangels mit der Zeit wahrscheinlich das Risiko eines Qualitätsverlusts.
Ich denke, man sollte die Vor- und Nachteile sorgfältig abwägen.

[laeyoung]

Ich weiß nicht genau, warum auf Hacker News ein old-reddit-Link stehen geblieben ist, aber der Pfad zur aktuellen Reddit-UI ist hier.

[xguru]

Bei Hacker News scheint man beim Posten von Reddit-URLs meistens old reddit zu verwenden. Vermutlich, weil es schlanker ist.

[cnaa97]

Wenn das Ziel einer Organisation darin besteht, die Untergrenze anzuheben, dann erkenne ich an, dass funktionsorientierte Teams passend sind, etwa ein Team, das nur aus Web-Frontend-Entwicklern besteht, oder ein App-Entwicklerteam.

Aber für Teams oder Organisationen, die auf Spitzenleistung abzielen, hat eine funktionsorientierte Struktur zwangsläufig Grenzen.
Wie auch der Text des Artikels sagt, stellt sich die Frage, ob Planer, Designer, PMs und Ingenieure wirklich jeweils nur ihre eigene Arbeit übernehmen und wie an einem Fließband in einer Fabrik arbeiten müssen. Ideal ist nicht die typische „Zuständigen“-Arbeitsweise, bei der man nur einige wenige zugewiesene Aufgaben übernimmt, sondern ein Modell, in dem Mitglieder mit Spezialisierungen in den einzelnen Bereichen zusammenkommen, gemeinsam ein Ziel setzen und alle Mitglieder sich gegenseitig unterstützen.

In vielen Unternehmen werden Organisationen in Form von Taskforces aufgebaut, etwa durch Ausgründungen oder Teamzusammenstellungen. Doch auch dabei werden letztlich nur Menschen nach Funktionen zusammengebunden, weshalb es zu negativer Verstärkung kommen kann (zum Beispiel nach dem Muster: Ich versuche etwas zu tun, aber das Unternehmen unterstützt mich nicht, also gebe ich einfach auf). Dadurch kann man am Ende nur wichtige Talente wie Schlüsselmitglieder verlieren; deshalb braucht auch eine zielorientierte Organisation unbedingt die aktive Unterstützung durch die funktionsorientierte Organisation.

[GN⁺]

Hacker-News-Kommentare

• Am Ende entwarfen sie ohne mein „PMing“ sogar eine komplett neue Architektur. Der Grund war, dass sie endlich richtig verstanden hatten, wer unser Produkt tatsächlich benutzt. Insgesamt zeigt diese Erfahrung: „Als wir Ingenieure an Sales-Calls gesetzt haben, stellte sich heraus, dass das eigentliche Problem war, dass PMs die Kommunikation zwischen Kunden und Engineering nicht gut vermittelt hatten, während ein DevOps-Ingenieur derjenige war, der Kundenbedürfnisse am schnellsten in eine tatsächlich funktionierende Lösung umsetzen konnte.“
  • Manchmal sind Ingenieure so von sich überzeugt, dass sie denken, die Nutzer würden das Produkt einfach falsch benutzen. Die Logik lautet dann: Das passiert nur, weil „die Nutzer sich dumm anstellen“, nicht weil mein komplexes Design problematisch ist. Allein Leute aus dem Desktop-Linux-Lager könnten ein ganzes Buch darüber schreiben, wie Nutzerbeschwerden ignoriert wurden. Wenn ein sturer Ingenieur sich für klüger hält als PM und Nutzer, kommt gar nichts voran. Setzt man so jemanden aber direkt den Nutzern aus, dann zerreißen nicht mehr die sonst freundlichen PMs, sondern tatsächlich genervte User „dieses großartige Werk“, als wäre es ein problematischer Hamster. So ein Prozess macht Angst, zerstört aber auch das Ego des Ingenieurs. Aus meiner Sicht geht es dabei nicht darum zu zeigen, dass PMs dumm sind, sondern darum, Ingenieure zu demütigen. Mit der Zeit kommt ihre Arroganz ohnehin zurück, also muss man diesen Prozess regelmäßig wiederholen
  • Ich bin in einem mechanischen Entwicklungsteam eines Großunternehmens die einzige Person, die überhaupt Code schreiben kann. Das interne IT-Team entwickelt diverse Software selbst, aber das meiste finden die Teammitglieder eher schlecht. Deshalb baue ich Dinge entweder neu oder erfinde Tools, die „schlechte“ Programme ergänzen, die sich nicht wirklich ersetzen lassen, damit die Arbeit leichter wird. Ich glaube nicht unbedingt, dass ich besser entwickle als das Inhouse-IT-Team, sondern eher, dass ich aus der Perspektive eines echten Nutzers besser verstehe, was ich selbst, also unser Team, wirklich braucht. Und weil ich die Software selbst benutze, ist meine Motivation natürlich auch höher. Deshalb konnte ich mich mit dem Titel des Beitrags gut identifizieren. Ich halte aber auch das, was im eigentlichen Text beschrieben wird, für etwas, das im Berufsalltag durchaus passieren kann. Mit formalen Softwareentwicklungs- oder Projektmanagementprozessen kenne ich mich allerdings nicht aus
  • Ich leite ein kleines Tech-Startup mit 2 Millionen Dollar Jahresumsatz. Wenn uns im Support Personal fehlte, habe ich manchmal selbst ein paar Tage lang den Kundensupport übernommen. Jedes Mal habe ich erstaunlich viele Kundenbeschwerden entdeckt, die normalerweise überhaupt nicht beim Engineering ankamen. Support-Mitarbeiter neigen dazu, Probleme selbst zu „lösen“, statt dafür zu sorgen, dass grundlegende Verbesserungen tatsächlich bis ins Engineering durchgereicht werden
  • Auffällig ist, dass sich niemand fragt, warum die Software ursprünglich so chaotisch war. Ich glaube nicht, dass man die Verantwortung komplett einem PM zuschieben kann. Eigentlich ist das ein Systemproblem: Agile/Scrum und Ähnliches verwässern Verantwortung, und Entwickler arbeiten hastig schlecht ausgearbeitete Tickets in immer kürzeren Zyklen ab, sodass am Ende genau solche halbgar zusammengeschusterten Produkte entstehen. Das ist ein typisches Ergebnis aufgeblähter „moderner“ Softwareorganisationen
  • Mein erster Gedanke beim Lesen war: „So wurde Software früher gebaut, bevor PMs überall dazwischenfunkten.“ Wenn man Ingenieure direkt neben die Leute setzt, die den Betrieb wirklich machen, merkt man oft, dass man eigentlich keine PMs braucht und alle viel glücklicher sind. Natürlich gibt es auch hervorragende PMs, aber meiner Erfahrung nach neigen PMs stark zu Revierkämpfen und wissen erstaunlich oft weder über Engineering noch über die Kundenseite wirklich gut Bescheid
• Ich habe oft erlebt, dass Ingenieure nicht im Takt mit dem Produkt arbeiten. Ein Kollege baut heimlich etwas ein, ohne dass andere davon wissen, und plötzlich ist das UI verwirrend. Oder die Inhalte auf der Website passen nicht zum tatsächlichen Produkt. Dazu kommt der lange Kreislauf [Produkt -> PM -> Bug-Tracking-System -> Ingenieur -> Fix -> QA -> Produkt]: Wichtige Dinge werden zwar behoben, aber kleinere Unannehmlichkeiten bleiben ewig liegen. Wenn nur noch [Produkt <-> Ingenieur] übrig bleibt, kann die Produktivität erstaunlich steigen. Viele Ingenieure haben die gesamte Produkterfahrung in der Praxis nie selbst durchlaufen und wissen oft nicht einmal, was sich im Vergleich zum Vorjahr geändert hat
  • Ich habe Ähnliches erlebt, und interessanterweise kam das in Umgebungen mit vielen PMs häufiger vor. Meine schlimmste Erfahrung war ein Unternehmen, das PMs und „Product Designer“ nach einem festen Verhältnis zur Zahl der Ingenieure zuteilen wollte. Rechnet man Designer, Product-, Project- und Program-Manager zusammen, waren es am Ende mehr als Ingenieure. Das hat die Situation nur noch schlimmer gemacht. Schon das Ausweichen vor PM-Bürokratie und deren Sorge, man könnte in ihr Aufgabengebiet eingreifen, war Arbeit genug. Großartige PMs sind wirklich wertvoll, aber inzwischen wirkt der Titel Product Management auf mich wie ein Magnet für zu viele bürokratische, prozessverliebte Leute. Auch Product-Management-Influencer verschärfen das Problem
  • Ich glaube trotzdem nicht, dass es die richtige Lösung ist, Ingenieure zwangsweise in Sales-Calls zu stecken. Um ein Telefongespräch erfolgreich zu führen, braucht man viele Soft Skills, auf die Ingenieure weder trainiert sind noch nach denen bei der Einstellung gesucht wird. (Mit „Sales-Call“ meine ich frühe Beratungsgespräche vor Demo oder PoC. Bei komplexen Pre-Sales-Demos können Ingenieure gern dabei sein, aber die eigentliche Rolle sollte grundsätzlich beim Produktverantwortlichen liegen)
  • Es gibt unglaublich viele Arten, wie das schiefgehen kann, und ich habe sie alle schon gesehen. Zum Beispiel, wenn ein PM oder PO die gesamte Kundenkommunikation monopolisiert, oder wenn Kunden Gespräche mit Entwicklern komplett vermeiden und nur Anforderungen des User-Managers interpretiert weitergeben, oder wenn Entwickler ausschließlich Code schreiben wollen, oder wenn jede Kommunikation nur über PM und Bug-Tracker laufen darf. Auch bei kommerziellen Softwareplattformen können technische Grenzen Workflows sehr schlecht machen. Irgendwo blockiert immer etwas die Kommunikation, und das kann von Kunden, mittlerem Management oder Entwicklern ausgehen. Nicht selten wird sogar von Anfang an eine falsche Lösung festgelegt, ohne dass Entwickler oder Nutzer die Details überhaupt kennen. Es gibt sehr viele Wege, am Ende kein wirklich gutes System für die Nutzer zu bauen
  • Ich halte es für extrem wichtig, dass Ingenieure das Produkt selbst tief verstehen. Schwieriger als grundlegendes Engineering ist oft, die Produktseite richtig zu treffen. Die meisten Produkte, die ich erlebt habe, sind letztlich aus Produktgründen gescheitert, daher erscheint es mir logisch, die Stärken des Teams stärker darauf auszurichten
• Umgekehrt kann es auch passieren, dass Ingenieure am Ende nur noch den technischen Support machen. Wenn man jede Kundenfirma direkt unterstützt, häufen sich nur Hotfixes und individuelle Sonderlösungen an. Nichts davon wird ordentlich getestet, technische Schulden wachsen, und sobald ein großer, gut finanzierter Wettbewerber ein besseres Produkt baut, ist man schnell abgehängt. Das ist für mich ein klassisches Versagen des Produktmanagements. Entweder vermittelt der PM Kundenbedürfnisse nicht richtig ans Engineering, oder er schafft es in die andere Richtung nicht, ausreichend Druck zu machen. Ingenieure in Sales-Calls einzusetzen ist außerdem kein skalierbarer Ansatz, sobald die Kundengruppe eine gewisse Größe und Reife erreicht. Wenn ein Produktmanager wirklich will, dass ein Ingenieur Sales-Calls übernimmt, dann sollte dieser Ingenieur fairerweise auch einen Teil der Provision pro Account bekommen. Ich würde niemals ohne Provision Sales-Calls übernehmen
• In Umgebungen wie Startups, in denen jedes Teammitglied tiefes Mitgefühl für Kundenbedürfnisse braucht, ist das eine ausgesprochen starke Strategie. Wenn ich tatsächlich an der Definition der Produktanforderungen beteiligt war und die praktische Arbeit wirklich verstanden habe, war die Erfolgsquote von Projekten viel höher. Das Ergebnis war deutlich besser, als wenn ich Anforderungen einfach nur „übergeben“ bekam und dann umsetzte
  • Meinst du damit, dass es leichter war, etwas umzusetzen, weil du die Richtlinien selbst geschrieben hattest, oder dass durch die direkte Beteiligung einfach eine bessere UX entstanden ist?
• „In 2 Wochen Rewrite abgeschlossen, 60 % der Funktionen entfernt, eine einfache Fortschrittsanzeige hinzugefügt, Slack-Integration gebaut, einen ‘done-for-you’-Workflow angeboten -> 70 % weniger Support-Tickets“ — falls das wirklich stimmt, war da vorher irgendetwas ganz massiv kaputt
  • Reddit ist bekannt für eine Flut an erfundenen Geschichten, und auch dieser Text ist voll von typischen Reddit-Schreibeigenheiten und LinkedIn-artigem Business-Storytelling, egal ob er von einer echten Begebenheit inspiriert ist oder komplett erfunden wurde
  • Ich würde sagen, das ist einfach ein B2B-SaaS-Produkt, das mehrfach gepivotet hat und dabei kaum vernünftige Produktdokumentation hatte. Solche verhedderten Situationen sind tatsächlich erstaunlich häufig
  • Schon an diesem LinkedIn-Stil mit kurzen Sätzen und wiederholten dramatischen Wendungen erkennt man leicht, dass das erfunden ist
  • Ist eben Reddit, also natürlich erfunden. Ich verstehe nicht, warum so etwas überhaupt zum Gesprächsthema wird
• Wenn das wirklich das Ergebnis war, sollte man PM, PO und das Marketingteam sofort entlassen. Zwei Dinge sind klar: Erstens haben diese Leute entweder nicht verstanden, was Kunden tatsächlich wollen, oder sie konnten diese Bedürfnisse nicht richtig ans Entwicklungsteam vermitteln, oder beides. Zweitens denken sie viel zu systemisch; vielleicht wäre es besser, einfach alle Zwischenschritte zwischen Kunden und Entwicklungsteam zu entfernen
• In einem früheren Job waren Ingenieure ebenfalls regelmäßig bei Sales-Calls dabei. Es war interessant zu sehen, was einzelne Kunden wollten und wie unser Produkt verkauft wurde, aber revolutionär war das nicht. Die Funktionen, die Kunden wollten, standen ohnehin schon auf der Roadmap, und es gab auch eine verwirrende Funktion, die aber wegen spezieller Anforderungen des größten Kunden genau so gestaltet worden war. Das Entwicklungsteam wollte sie eigentlich einfacher machen, konnte dann aber die Anforderungen dieses großen Kunden nicht mehr erfüllen. Am Ende haben wir separat eine leichter nutzbare „Light“-Version gebaut, die dann alle außer dem Großkunden verwenden konnten. Aber auch diese Änderung kam nicht wegen der Begleitung von Sales-Calls zustande; allen war von Anfang an klar, dass es schwierig war, nur konnte man es erst ändern, als es auf der Roadmap an der Reihe war
• Mit dem Teil „endlich richtig verstanden, wer die tatsächlichen Nutzer sind“ konnte ich mich sehr identifizieren. Man sagt oft: „Das größte Problem der meisten Ingenieure ist Overengineering“, aber in Wirklichkeit entsteht Overengineering oft eher daraus, dass die tatsächlichen Kundenszenarien nicht richtig verstanden werden. Das ist das grundlegendere Problem. Was mich als Ingenieur am häufigsten frustriert, ist, dass andere Ingenieure gar nicht erst verstehen wollen, welches Produkt sich tatsächlich verkauft. Ob das an mangelnder beruflicher Eignung, am Ego oder meist an Organisationskultur und Anreizsystemen liegt, sei dahingestellt
• Ich war früher bei einer Firma, die Robocall-Lösungen für CRM gebaut hat. Bei einem Offsite-Event sollten plötzlich alle selbst Cold Calls machen und sich an ein Skript halten. Es gab keinerlei Verständnis oder Interesse dafür, welche Ängste das bei Nicht-Sales-Leuten auslöst. Danach habe ich angefangen, über einen Jobwechsel nachzudenken
• Ich habe einmal etwas sehr Ähnliches erlebt. Das Monitoring-Team bestand darauf, dass Frontline-Ingenieure „für jeden Alarm selbst ein Ticket eröffnen“ sollten. Das Problem: Es gab mehr als 10.000 Alarme pro Stunde. Wichtige Probleme gingen komplett im „Rauschen“ unter, das Management war erschöpft, und irgendwann wurde dem Monitoring-Team gesagt: „Dann eröffnet und bearbeitet ihr doch selbst einmal alle Tickets.“ Schon am nächsten Tag wurden unwichtige Alarme ausgeschlossen, sodass nur noch ein Dutzend einzigartige Alerts pro Stunde übrig blieb, und der Rest wurde nach und nach ebenfalls geschlossen. Erst da bedeutete „alle Lämpchen auf dem Board grün“ wirklich etwas; vorher war das Grün nur aufgemalt, um Medien und der Gartner Group etwas zu zeigen