Großartige Produkte: Discovery vs. Delivery

Die meisten von uns arbeiten an ziemlich schwierigen Problemen und normalerweise benötigt man recht komplexe Systeme, um diese Probleme zu lösen.

Viele Teams stehen zwei großen Herausforderungen gegenüber:

Erst einmal müssen sie herausfinden, wie die Lösung für den Kunden aussehen soll (Discovery). Das bedeutet sowohl, erst einmal herauszufinden, ob es überhaupt Kunden gibt, die diese Lösung brauchen (Nachfrage), als auch eine Lösung zu finden, die für die Kunden und das eigene Unternehmen funktioniert. Noch schwieriger ist es, eine einzige Lösung zu finden, die für viele Kunden funktioniert und nicht nur für einige spezifische Kunden. Um das zu schaffen, müssen wir schnell dazulernen.

Zweitens muss man dafür sorgen, eine robuste und skalierbare Implementierung zu liefern, auf dessen Wert sich unsere Kunden verlassen können (Delivery). Das Team sollte Vertrauen in das Release haben. Auch wenn man wohl nie 100 % Vertrauen in etwas setzen kann, sollte man jedoch auch nicht dafür beten müssen, dass alles gut geht, wenn man etwas released.

Man muss also sowohl schnell dazulernen als auch Vertrauen in seine Releases haben.

Kann das funktionieren?

Es ist verständlich, dass viele Leute denken, dass diese beiden unterschiedlichen Ziele widersprüchlich sind. Wir müssen versuchen, schnell etwas zu releasen, damit wir herausfinden können, was funktioniert und was nicht. Allerdings wollen wir auch nichts releasen, was noch nicht ausgereift ist, und damit riskieren, unseren Kunden und unserer Marke zu schaden.

Ich habe mich mit vielen Produktteams unterhalten und bin häufig zur Rede gestellt worden, weil ich in einem Moment ein Team dazu auffordere, aggressiver zu releasen und Feedback von den Kunden einzuholen, und gleichzeitig von ihnen verlange, keine Kompromisse im Hinblick auf verlässliche, leistungsstarke und sichere Software einzugehen.

Das Minimum Viable Product

Für viele Teams ist das Konzept eines Minimum Viable Products (MVP) nicht einfach, denn einerseits ist man zwar motiviert, dem Kunden schnell etwas zu bieten und Feedback dazu zu bekommen, aber andererseits hat man schnell das Gefühl, dass das sogenannte „Produkt” eine Blamage werden könnte – und wie könnte man so etwas nur jemals an die Öffentlichkeit bringen?

Schnelles Lernen und solide Releases

Ich möchte hier erläutern, wie gute Teams es schaffen können, die beiden Ziele – schnelles Lernen und solide Releases – zu vereinen.

Grundsätzlich glaube ich, dass den meisten Teams das zweite Ziel – nämlich vernünftige Software zu liefern – einfacher fällt, als schnell Dinge auszuprobieren und neue Erkenntnisse zu gewinnen. Continuous Delivery, also das kontinuierliche Ausliefern, ist eine gute Methode, die ich bei den Teams beobachten konnte, die die Bedeutung von vielen kleinen und inkrementellen Veränderungen eines komplexen Systems verstanden haben.

Was ist überhaupt ein Produkt?

Grund für diese Verwirrung ist unter anderem die Tatsache, dass man oft einfach nicht genau weiß, was es bedeutet, wenn man von „Produkt”, „Produktqualität”, „live in production” usw. spricht. Ich versuche immer, den Begriff „Produkt” für ein Produkt zu nutzen, das in einem Zustand ist, in dem es tatsächlich vermarktbar ist. Es ist skalierbar und bietet eine gewisse Performance. Es gibt eine starke Regressionstest-Suite. Es ist so ausgelegt, dass man die benötigten Analytiken sammeln kann. Je nach Bedarf wurde es entweder internationalisiert oder örtlich eingegrenzt. Es lässt sich gut pflegen. Es entspricht dem Markenversprechen. Und am wichtigsten ist die Tatsache, dass das Team das Produkt guten Gewissens releasen kann.

Das ist nicht einfach und es beansprucht die meiste Zeit bei der Entwicklung. Aus diesem Grund strengen wir uns an, all diese Bemühungen nicht zu verschwenden.

Diese Arbeiten zu erledigen, obwohl der Produktmanager selbst nicht einmal sicher ist, ob die Kunden die Lösung überhaupt wollen oder brauchen, ist ein absolut sicheres Rezept für Verschwendung.

Die Product Discovery

Der Sinn der Product Discovery ist also, Beweise dafür zu sammeln, dass all die Bemühungen der Entwickler für eine qualitativ hochwertige Software nicht umsonst sein werden.

Darum gibt es für die Product Discovery so viele verschiedene Techniken. Wir haben Techniken, um unsere Nutzer und Kunden besser zu verstehen und um Produktideen qualitativ und quantitativ zu validieren. Und die meisten dieser Techniken nehmen noch nicht einmal die Zeit der Entwickler in Anspruch (das ist wichtig, da wir nämlich wissen, wie viel Zeit und Aufwand es kostet, gute Qualität zu produzieren).

Effektive Product Discovery hat viel damit zu tun, Zugang zum Kunden zu bekommen, und nicht einfach nur schnellstmöglich unsere Experimente für neue Produkte umzusetzen.

Wenn Sie noch ein ganz junges Startup sind und keine Kunden haben, dann ist das natürlich nicht wirklich ein Thema (und es ist vielleicht sogar zu früh für Software in Produktionsqualität).

Die meisten von uns haben aber echte Kunden und echte Umsätze und daher müssen wir uns auch Gedanken darüber machen. Ich habe bereits über die wichtigsten Techniken für schnelles und verantwortungsvolles Experimentieren mit der Product Discovery in etablierten Unternehmen geschrieben.

Viele dieser Techniken haben damit zu tun, einige unserer Kunden oder potenziellen Kunden davon zu überzeugen, unsere neuen Ideen für Produkte zu testen (auf welche Weise auch immer). Ein Kundenentwicklungsprogramm ist dafür besonders gut geeignet, denn diese Personen haben sich freiwillig gemeldet, um das Versuchskaninchen zu spielen. Wir können mit ihnen sprechen oder sie einfach nur dabei beobachten, wie sie unsere Produktideen ausprobieren, oder aber wir lassen sie eine Weile unsere Prototypen testen und schauen, was dabei heraus kommt.

Fazit: Discovery vs. Delivery

Wenn Sie wirklich großartige Produkte entdecken wollen, ist es extrem wichtig, Ihre Ideen früh und oft an echten Nutzern und Kunden zu testen. Wenn Sie großartige Produkte liefern wollen, sollten Sie die besten Entwicklungsmethoden nutzen und versuchen, die Bedenken der Ingenieure nicht zu übergehen.

Wenn wir schnell voran kommen und neue Ideen entdecken möchten, nutzen wir Discovery-Methoden und beziehen die Kunden mit ein. Sobald wir herausgefunden haben, welche Lösung wir entwickeln sollten, lassen wir die Entwickler eine Software in Produktionsqualität entwickeln, da sie diese dann auch mit voller Überzeugung liefern können.

Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.