Bei DevBoost arbeiten wir seit vielen Jahren eng mit Software-Produktherstellern unterschiedlichster Branchen zusammen. Unsere Teams unterstützen Firmen dabei komplexe Refactorings durchzuführen (um Monolithen aufzuspalten), neue Technologien einzuführen (um zu Cloud-native Architekturen zu migrieren) oder auch „einfach“ neue Features umzusetzen. Solche Projekte dauern mehrere Monate, manchmal sogar Jahre. Die Komplexität der betroffenen Softwareprodukte und die anspruchsvollen Aufgaben erfordern dabei eine enge Zusammenarbeit unserer Teams mit den Entwicklungsteams unserer Kunden.

Durch diese starke Interaktion mit den Teams unserer Kunden und die langen Projektlaufzeiten, bekommen wir einen sehr tiefen Einblick in die Prozesse und Abläufe der Produktentwicklung bei unseren Kunden. Wir sehen dabei was gut funktioniert, womit Kunden erfolgreich sind, aber auch welche Muster Probleme bereiten.

Über die letzten Jahre kam dabei immer öfter die Frage auf warum bestimmte Softwareprodukte bzw. die Unternehmen dahinter erfolgreicher sind als andere. Diese Frage haben wir uns selbst oft gestellt, aber sie wird auch von potenziellen und aktuellen Kunden an uns herangetragen. Immer wieder stehen bestimmte zentrale Fragen im Mittelpunkt: „Was macht eine erfolgreiche Produktentwicklung aus?“, „Was machen andere Firmen oder Startups besser als wir?“ oder auch „Warum haben wir hunderte Entwickler, aber unser Produkt kommt nicht wirklich von der Stelle?“.

Die Antworten auf diese Fragen sind vielschichtig und generelle Ratschläge sind nicht einfach. Dennoch möchten wir in diesem Beitrag einmal beleuchten, welche Best Practices wir bei unseren Kunden über die letzten Jahre gesehen haben und was deren konkrete Umsetzung an anderer Stelle manchmal schwierig macht. Jeder, der an der Entwicklung von Softwareprodukten beteiligt ist, weiß, dass das nicht einfach ist. Wir wollen also versuchen die Fehler, die andere bereits gemacht haben, selbst zu vermeiden.

Alle Hersteller von Softwareprodukten befassen sich zu einem gewissen Grad mit drei zentralen Aufgabenbereichen:

• Product Discovery

• Product Delivery

• Product Design

Product Discovery umfasst alle Aktivitäten, die dazu dienen den inhaltlichen Fokus des Produkts zu bestimmen. Für welche Kunden wird das Produkt entwickelt? Welche Probleme löst es für den Nutzer? Welche neuen Möglichkeiten erlaubt das Produkt dem Nutzer? Welche Nutzergruppen existieren? Wie unterscheiden sich die Bedürfnisse der verschiedenen Nutzergruppen? Welche anderen Produkte nutzen die Kunden bisher? Welche Faktoren würden Kunden zu einem Produktwechsel motivieren? Und letztlich auch: Welche Features muss das Produkt bieten, um Kunden anzusprechen?

Product Delivery umfasst alle Aufgaben, die notwendig sind, um die in der Discovery „entdeckten“ Features technisch umzusetzen und Nutzern zur Verfügung zu stellen. Dazu zählt das Schreiben des eigentlichen Codes, aber auch Qualitätssicherung (z. B. Testautomatisierung), Dokumentation, Performance-Optimierung, Releases und Deployments, Betrieb und Wartung.

Die beiden Bereiche Discovery und Delivery greifen also Hand in Hand ineinander. Ohne gute Discovery-Arbeit fehlt die Grundlage die richtigen und wichtigen Features in der Delivery zu liefern. Ohne eine geölte Delivery-Maschine kommen die entdeckten Features nie bei einem Kunden an. Discovery und Delivery bedingen sich also gegenseitig. Sie bedingen sich aber nicht nur, sie können sich auch gegenseitig unterstützen und verstärken. Beispielsweise kann es eine gut funktionierende Delivery erlauben, neue Features schnell an realen Kunden zu testen (z. B. mit Hilfe von A/B-Tests) um herauszufinden, was Kunden wirklich benötigen.

Neben den beiden großen Aktivitäten Product Discovery und Product Delivery haben wir die Erfahrung gemacht, dass das Product Design (sowohl technisch als auch organisatorisch) eine große Rolle spielt. Auch hier muss Zeit und Aufwand investiert werden, um das Unternehmen (und die Software) so zu gestalten, dass die Wertschöpfung vom Kundenwunsch bis hin zum Release reibungslos funktioniert. Autarke, cross-funktionale Teams, die unabhängige Services entwickeln, seien hier nur als ein Beispiel genannt, um diese Aufgabe zu adressieren.

In der Theorie sollten Product Discovery Aufgaben primär von Produktmanagern oder Product Ownern übernommen werden. „Nach dem Lehrbuch“ sollten Sales und Entwickler dabei unterstützen. Sie sollen zusammensitzen und darüber brüten, welche Probleme Kunden wirklich haben, welche Ziele die Kunden eigentlich erreichen wollen und wie man ihnen dabei hilft (ohne lediglich die Features der Konkurrenten zu kopieren). Sie sollen mit Kunden sprechen und Workshops durchführen, um den Kunden besser zu verstehen als er das selbst tut.

Für die Product Delivery sind Product Owner, Scrum Master, UI/UX Designer und Entwicklungsteams zuständig. Sie sollen dafür sorgen, dass die Feature-Fabrik effektiv läuft und in hoher Frequenz neue Features stabil und in hoher Qualität produziert. Sie sollen der Ort sein, an dem die Ideen aus der Product Discovery zu echtem Leben erweckt werden und aufblühen - schöner als der Kunde es sich jemals vorstellen könnte.

Die Hoheit über die Architektur bzw. das Design der Team-Struktur und der Software liegt in den Händen von Managern, Abteilungsleitern und Softwarearchitekten. Sie erdenken eine Teamstruktur, in der das gesamte Unternehmen optimal Wert für die Kunden schaffen kann. Sie beseitigen die Hindernisse, die einzelne Teams daran hindern Kunden glücklich zu machen. Sie gleichen die Organisation mit dem Aufbau der Software ab, so dass jedes Team klare Zuständigkeiten hat und ungehindert neue Features wachsen lassen kann.

So einfach ist das in der Realität leider nicht. Selbst in sehr erfolgreichen und gut laufenden Unternehmen sieht die Welt nicht so rosig aus. Die Umstände und Widrigkeiten der realen Welt stören den schönen theoretischen Ablauf. Aber wie genau sieht das aus und was lässt sich dagegen tun?

Ein Muster, das wir bei vielen Softwareproduktherstellern beobachten, ist ein starker Fokus auf die Product Delivery. Der Großteil der Mitarbeitenden ist damit beschäftigt Code zu schreiben oder zu ändern, Technologien zu evaluieren oder auszutauschen, neue Testkonzepte einzuführen, komplexe Infrastrukturprojekte anzukurbeln oder zu versuchen herauszufinden, warum das Liefern neuer Features noch immer langsamer geht als man das gerne möchte.

Überraschend ist das nicht unbedingt, wenn man sich vor Augen führt, dass die Mehrzahl der Mitarbeitenden in Softwareunternehmen und Startups technisch orientierte Menschen sind. Sie begeistern sich für neue Frameworks oder Programmiersprachen, aber sie sind selten dafür ausgebildet mit Kunden zu arbeiten oder deren Bedürfnisse zu erfassen. Sie sind darauf getrimmt sich auf das „Wie“ und nicht auf das „Was“ (und erst recht nicht auf das „Warum“) zu konzentrieren. Das heißt nicht, dass diese Menschen nicht in der Lage sind sich mit Kunden zu befassen und gute Lösungen zu erarbeiten. Sie sind nur einfach oft nicht darauf trainiert. Kurioserweise sind aber auch die Tekkies diejenigen, die stark darunter leiden, wenn ein Produkt nicht erfolgreich ist, weil die falschen Features entwickelt wurden.

Neben dem starken Fokus auf Delivery wird Discovery oft sehr sporadisch, unsystematisch und wenig integriert durchgeführt. Zwar haben die meisten Unternehmen ein Sales-Team, welches Kundenwünsche einsammelt. Doch das ist noch lange nicht genug für gute Discovery Ergebnisse. Um zu „erforschen“, welche Ziele Kunden wirklich erreichen wollen, sind systematische Gespräche und Workshops notwendig. Diese haben nicht nur eine andere Struktur als ein Verkaufsgespräch, sondern erfordern auch Erfahrungen, die nicht alle Sales-Mitarbeiter haben. Hier sollten Produktmanager und Product Owner in Spiel kommen. Erstere werden aber oft nicht mit den notwendigen Befugnissen ausgestattet. Sales oder Management überstimmen nicht selten Produktmanager, so dass fundierte Produktentscheidungen unmöglich werden. Letztere sind oft so tief in die tägliche Organisation der Delivery eingebunden (z. B. in die Steuerung von Teams), dass keine Zeit für Discovery-Arbeit am Kunden bleibt.

Wenn man sich vor Augen führt, dass die Product Discovery entscheidend für den Produkterfolg ist, muss man feststellen, dass der starke Fokus auf Delivery und die fehlende Zeit/Befähigung für Discovery ein Punkt ist, an dem viele Softwareprodukthersteller arbeiten müssen. In diesem Zusammenhang hört man auch oft, dass dies ein deutsches Phänomen ist und in anderen Ländern wie in den USA oder Großbritannien andere Schwerpunkte gesetzt werden.

Aus unserer Erfahrung ist es notwendig, dass definitiv mehr Fokus auf Discovery-Arbeit gelegt werden sollte. Die Zusammenarbeit zwischen Produktmanagement, Sales und den Entwicklungsteams muss in diesem Zusammenhang sehr viel enger gestaltet werden. Die Menschen, die Schlüsselrollen besetzen, müssen entsprechend ausgebildet werden. Insbesondere für Product Owner gibt es hier viele nicht-technische Fähigkeiten zu erlernen (siehe auch „Product Owner – Superheld aber oft ohne Cape“).

Da Product Discovery sehr anspruchsvoll ist und oft experimentiert werden muss, um herauszufinden welches Problem für Kunden wirklich wichtig ist und welche Lösung am besten dazu passt, muss es iteratives Vorgehen zum Testen von Ideen geben (siehe auch „Was Softwareprodukthersteller von der Evolutionsbiologie lernen können“). Nur so kann sich ein Produkt Schritt für Schritt den Kundenbedürfnissen nähern.

Zuletzt können wir noch den Tipp geben die Optimierungen an den Delivery Aktivitäten systematischer zu gestalten. Obwohl hier viel Zeit investiert wird, sehen wir selten datengetriebene Optimierungsinitiativen. Für die Optimierung der Delivery-Arbeit fehlt es selten an Ideen – die Entwickler haben täglich Neue – aber ob Veränderungen wirklich die Lieferung von Features beschleunigen, wird kaum gemessen (siehe auch „Inventar in der Softwareentwicklung“).

Beachtet man diese Gesichtspunkte in der Produktentwicklung, verschiebt sich der Fokus auf den Kunden bzw. Nutzer des Produkts. Und genau diese Fokussierung ist aus unserer Erfahrung eine erhebliche Voraussetzung für langfristigen Produkteerfolg. Mit anderen Worten: Mehr Discovery und weniger Delivery kann das entscheidende Zünglein an der Waage sein und letztlich Dein Softwareprodukt erfolgreicher machen.

Zum Thema Product Discovery und Delivery gibt es einige gute Bücher. Um nur einige zu nennen:

• "Continuous Discovery Habits" von Teresa Torres

• "Running Lean" von Ash Maurya

• “Agile Management for Software Engineering” von David J. Anderson

Es bleibt also viel Spaß beim Lesen und viel Erfolg beim Umsetzen zu wünschen!

Wenn Du Fragen zum Thema hast oder mit uns in deiner Produktentwicklung durchstarten willst, dann sprich uns an.