Erstellen von Lösungen mit Blick auf die Kundenanforderungen

„Not macht erfinderisch“: Dieses Sprichwort verdeutlicht die Unvergänglichkeit des menschlichen Schöpfergeistes und unseren natürlichen Erfindungsdrang. Im Oxford English Dictionary lautet es: „Wenn der Bedarf nach etwas zwingend wird, müssen Wege gefunden werden, es zu bekommen oder zu erreichen.“ Nur wenige würden diese universellen Wahrheiten über Erfindungsreichtum leugnen. Wie im Artikel Innovation in der digitalen Wirtschaft erläutert, müssen bei Innovationen in der Cloud jedoch Erfindung und Akzeptanz gegeneinander abgewogen werden.

Wenn wir diese Analogie fortsetzen, stammen Innovationen aus einer erweiterten Familie. Kundenanforderungen sind ein wichtiger treibender Faktor für Innovationen. Grundlage für die Entwicklung einer Lösung mit Kundenempathie, die Innovationen begünstigt, ist ein berechtigter Kundenbedarf, der Kunden motiviert, eine längerfristige Zusammenarbeit zur Lösung kritischer Herausforderungen einzugehen. Diese Lösungen basieren auf dem tatsächlichen Bedarf des Kunden und nicht auf seinen Wünschen oder Launen. Beim Ermitteln des wahren Kundenbedarfs sind zunächst Empathie und ein umfassendes Verständnis der Kundenerfahrung gefragt. Empathie ist eine unterentwickelte soziale Kompetenz bei vielen Engineers, Produktmanagern und sogar Führungskräften. Zum Glück haben die vielfältigen Interaktionen von Cloudarchitekten und das rasante Tempo, in dem sie agieren, zur Entwicklung dieser Fähigkeit beigetragen.

Wie entwickelt man Empathie, und warum ist Kundenempathie so wichtig? Empathie hilft, sich in den Kunden einzufühlen und seine Erfahrungen zu verstehen. Von der ersten Version eines Minimum Viable Product (MVP) bis hin zur allgemeinen Verfügbarkeit einer marktgerechten Lösung hilft uns die Kundenempathie beim Entwickeln besserer Lösungen. Mit Empathie ist ein Team besser in der Lage, akzeptanzfördernde Lösungen zu entwickeln, was vielleicht noch wichtiger ist. In einer digitalen Wirtschaft sind Produktteams, die sich am ehesten in Kundenbedürfnisse einfühlen können, zukunftsfähiger und können bessere Tools entwickeln, die das Marktgeschehen neu definieren und Marktführerschaft übernehmen.

Definieren von Annahmen für die Entwicklung mit Kundenempathie

Das Definieren von Annahmen ist ein wesentlicher Bestandteil der Planung. Je mehr Sie planen, desto deutlicher können Sie erkennen, wie aus Ihren Annahmen die Grundlage einer guten Idee entsteht. Annahmen sind in der Regel das Produkt von Eigenempathie. Anders ausgedrückt: Was würde ich in dieser Lage wollen? Wenn Sie mit der Erstellungsphase beginnen, reduziert sich der Zeitraum, in dem Annahmen in eine Lösung einfließen können, auf ein Minimum. Dieser Ansatz beschleunigt auch die Feedbackschleife durch echte Kunden, löst frühere Lernmöglichkeiten aus und stärkt die Empathie.

Achtung

Die richtige Definition dessen, was erstellt werden soll, kann schwierig sein und erfordert etwas Übung. Wenn Sie bei der Erstellung zu schnell sind, kann es sein, dass die Lösung nicht den Kundenanforderungen entspricht. Wenn Sie zu viel Zeit mit dem Versuch verbringen, die anfänglichen Kundenbedürfnisse und -lösungsanforderungen zu verstehen, kann der Markt den Bedarf decken, bevor Sie überhaupt die Gelegenheit bekommen, eine Lösung zu erstellen. In beiden Szenarien kann die Lernchance deutlich verzögert oder verringert werden. Manchmal können die Daten sogar beschädigt werden.

Die innovativsten Lösungen der Geschichte begannen mit einem intuitiven Glauben. Dieses Bauchgefühl beruht sowohl auf der vorhandenen Expertise als auch auf Beobachtungen aus erster Hand. Beginnen Sie mit der Erstellungsphase, da Sie in dieser Phase Ihre Intuition schnell einem Test unterziehen können. Von diesem Punkt aus können Sie ein tieferes Verständnis und viel mehr Empathie entwickeln. Bei jeder Iteration oder Freigabe einer Lösung kommt das Gleichgewicht durch das Erstellen von MVPs zustande, die die Kundenempathie zeigen.

Um bei diesem Balanceakt für mehr Stabilität zu sorgen, werden in den folgenden beiden Abschnitten die Konzepte für die Entwicklung mit Empathie und das Definieren eines MVP erläutert.

Definieren einer kundenorientierten Hypothese

Die Entwicklung mit Empathie bedeutet, dass Sie eine Lösung anhand von definierten Hypothesen erstellen, die einen bestimmten Kundenbedarf veranschaulichen. In den folgenden Schritten formulieren Sie eine Hypothese, welche die Entwicklung mit Empathie unterstützt.

  1. Wenn Sie eine Lösung mit Empathie erstellen, steht der Kunde immer im Mittelpunkt. Diese Absicht kann viele Formen annehmen. Sie können auf einen Kundenarchetypen, eine bestimmte Person oder sogar auf ein Bild eines Kunden inmitten des Problems verweisen, das Sie lösen möchten. Beachten Sie auch den Unterschied zwischen internen Kunden (Mitarbeiter oder Partner) und externen (Konsumenten oder Geschäftskunden). Diese Definition ist die erste zu testende Hypothese: Können wir diesem speziellen Kunden helfen?
  2. Verstehen der Benutzerfreundlichkeit. Mit Empathie eine Lösung zu erstellen bedeutet, dass Sie die Erfahrung des Kunden nachvollziehen und seine Herausforderungen verstehen. Diese Denkweise führt zur nächsten zu testende Hypothese: Können wir diesem spezifischen Kunden bei dieser zu bewältigenden Herausforderung helfen?
  3. Definieren Sie eine klare Lösung für ein einzelnes Problem. Wenn Sie übergreifend die Expertise von Personen, Prozessen und Fachexperten einbeziehen, kann das zu einer möglichen Lösung führen. Die vollständige, zu testende Hypothese lautet dann: Können wir diesem speziellen Kunden bei diesem überschaubaren Problem mit der vorgeschlagenen Lösung helfen?
  4. Treffen einer Wertaussage. Welchen langfristigen Wert möchten Sie für diese Kunden bereitstellen? Die Antwort ergibt Ihre vollständige Hypothese: Wie wird sich das Leben dieser Kunden verbessern, wenn sie die vorgeschlagene Lösung nutzen, um diese zu bewältigende Herausforderung anzugehen?

Der letzte Schritt ist der Höhepunkt einer durch Kundenempathie gesteuerten Hypothese. Dabei werden die Zielgruppe, das Problem, die Lösung und die Metrik definiert, anhand derer eine Verbesserung vorgenommen werden muss, in deren Zentrum der Kunde steht. Während der Mess- und Lernphasen sollten Sie jede Hypothese testen. Ziehen Sie vorausschauend Änderungen beim Kunden, bei der Problemstellung oder bei der Lösung in Betracht, wenn das Team mehr Empathie für den ansprechbaren Kundenstamm entwickelt.

Achtung

Das Ziel besteht darin, eine Lösung mit Kundenempathie zu erstellen, nicht zu planen. Es ist zu leicht, in endlosen Zyklen der Planung und Optimierung stecken zu bleiben, um die perfekte Aussage zur Kundenempathie zu finden. Bevor Sie versuchen, eine solche Aussage zu entwickeln, lesen Sie die folgenden beiden Abschnitte zum Definieren und Erstellen eines MVP.

Nachdem Sie den Nachweis für die Kernannahmen erbracht haben, konzentrieren sich die späteren Iterationen neben der Überprüfung der Empathie auf Wachstumstests. Nachdem Sie Empathie entwickelt, getestet und überprüft haben, beginnen Sie, den ansprechbaren Markt in seiner ganzen Größenordnung zu verstehen. Sie können ein noch tieferes Verständnis für den ansprechbaren Markt entwickeln, indem Sie die zuvor beschriebene Formel für die Standardhypothese erweitern. Schätzen Sie dann anhand der verfügbaren Daten die Größe des Gesamtmarkts (die Anzahl potenzieller Kunden).

Schätzen Sie aufgrund dieser Ausgangslage den prozentualen Anteil der Kunden am Gesamtmarkt, die ein ähnliches Problem haben und deshalb an dieser Lösung interessiert sein könnten. Auf diese Weise ermitteln Sie Ihren ansprechbaren Markt. Die nächste, zu testende Hypothese lautet: Wie wird sich das Leben von x % Kunden verbessern, wenn sie die vorgeschlagene Lösung zum Bewältigen dieses überschaubaren Problems nutzen? Eine kleine Auswahl von Kunden lässt wichtige Indikatoren erkennen, die einen prozentualen Effekt auf die Gruppe beteiligter Kunden nahelegen.

Definieren einer Lösung zum Testen der Hypothese

Bei jeder Iteration einer Feedbackschleife aus Erstellen, Messen und Lernen wird Ihr Versuch, eine Lösung mit Empathie zu erstellen, durch ein MVP definiert.

Ein MVP ist die kleinste erforderliche Einheit des Aufwands (Erfindung, Engineering, Anwendungsentwicklung oder Datenarchitektur), um genügend Anteile einer Lösung zu schaffen, um mit dem Kunden zu lernen. Das Ziel jedes MVP besteht darin, einige oder alle der vorherigen Hypothesen zu testen und Feedback direkt vom Kunden zu erhalten. Das Ergebnis ist keine elegante Anwendung mit allen Funktionen, die erforderlich sind, um die Branche zu verändern. Das gewünschte Ergebnis jeder Iteration ist eine Lernmöglichkeit: eine Chance, eine Hypothese eingehender zu testen.

Das Festlegen eines Zeitrahmens ist eine Standardmethode, um sicherzustellen, dass ein Produkt schlank bleibt. Stellen Sie beispielsweise sicher, dass Ihr Entwicklungsteam der Meinung ist, die Lösung in einer einzigen Iteration erstellen zu können, um für schnelles Testen zu sorgen. Lesen Sie Planen von Geschwindigkeit, Iterationen, Release und Iterationspfaden, um besser zu verstehen, wie Sie mithilfe von Geschwindigkeit, Iterationen und Releases definieren können, was „minimal“ oder schlank bedeutet.

Reduzieren der Komplexität und Verzögern von technische Spitzen

Erkunden Sie anhand der in Innovative Methodik beschriebenen Erfindungsdisziplinen die Funktionalität, die häufig zum Bereitstellen einer ausgereiften innovativen oder skalierungsfähigen MVP-Lösung benötigt wird. Verwenden Sie diese Disziplinen als langfristigen Leitfaden für die Einbindung von Features. Verwenden Sie sie auch als Vorsichtshinweis bei der frühen Prüfung des Kundennutzens und der -empathie in Ihrer Lösung.

Die Featurebreite und die verschiedenen Erfindungsdisziplinen können nicht alle in einer einzigen Iteration erstellt werden. Es könnten mehrere Releases für eine MVP-Lösung nötig sein, um die Komplexität mehrerer Disziplinen einzubeziehen. Abhängig von der Investition in die Entwicklung könnte es mehrere parallele Teams geben, die in verschiedenen Disziplinen arbeiten, um mehrere Hypothesen zu testen. Auch wenn es ratsam ist, die architektonische Ausrichtung zwischen diesen Teams zu koordinieren, ist es unklug, zu versuchen, komplexe integrierte Lösungen zu erstellen, bevor Sie die Werthypothesen überprüfen konnten.

Komplexität erkennen Sie am besten anhand der Häufigkeit oder Menge von technischen Spikes. Technische Spitzen sind Bemühungen, technische Lösungen zu schaffen, die nicht einfach mit Kunden getestet werden können. Wenn Kundenwert und Kundenempathie nicht getestet werden, stellen technische Spikes ein Risiko für Innovationen dar und sollten auf ein Minimum beschränkt werden. Für die Arten von ausgereiften, getesteten Lösungen, die bei einem Migrationsansatz zu finden sind, können während der gesamten Umsetzung häufig technische Spitzen auftreten. Allerdings verzögern sie das Testen von Hypothesen bei Innovationen und sollten nach Möglichkeit zurückgestellt werden.

Bei jeder MVP-Definition ist ein konsequenter Vereinfachungsansatz hilfreich. Bei diesem Ansatz wird alles entfernt, was nicht zum Überprüfen der Hypothese beiträgt. Um die Komplexität zu minimieren, verringern Sie die Anzahl der Integrationen und Features, die zum Testen der Hypothese nicht erforderlich sind.

Erstellen eines MVP

Bei jeder Iterationen kann eine MVP-Lösung viele verschiedene Formen annehmen. Eine häufige Anforderung besteht lediglich darin, dass das Ergebnis das Messen und Testen der Hypothese ermöglicht. Diese einfache Voraussetzung bringt den wissenschaftlichen Prozess in Gang und ermöglicht dem Team, mit Empathie eine Lösung zu entwickeln. Um diese kundenorientierte Ausrichtung zu erreichen, könnte sich ein anfängliches MVP auf nur eine der Erfindungsdisziplinen stützen.

In manchen Fällen bedeutet der schnellste Weg zur Innovation die vorübergehende vollständige Vermeidung dieser Disziplinen, bis sich das Cloud Adoption-Team von der sorgfältigen Überprüfung der Hypothese überzeugt hat. Eine solche Empfehlung von einem Technologieunternehmen wie Microsoft hört sich nicht unbedingt schlüssig an. Sie bekräftigt jedoch nur, dass bei einer MVP-Lösung der Kundenbedarf und keine bestimmte Technologieentscheidung höchste Priorität genießt.

In der Regel besteht eine MVP-Lösung aus einer Anwendung oder Datenlösung mit minimalen Funktionen und begrenztem Feinschliff. Für Unternehmen, die über professionelle Entwicklungskompetenz verfügen, ist dies oft der schnellste Weg zum Lernen und Iterieren. Die folgende Liste enthält einige andere Ansätze, die ein Team zur Erstellung eines MVP anwenden kann:

  • Ein Vorhersagealgorithmus, der in 99 Prozent der Fälle falsch ist, aber spezifische gewünschte Ergebnisse zeigt.
  • Ein IoT-Gerät, das auf Produktionsebene nicht sicher kommuniziert, aber innerhalb eines Prozesses den Wert von Daten in nahezu Echtzeit aufzeigen kann.
  • Eine Anwendung, die von einem Citizen Developer entwickelt wurde, um eine Hypothese zu testen oder kleinere Anforderungen zu erfüllen.
  • Ein manueller Prozess, der die Vorteile der zu verfolgenden Anwendung erneut erstellt.
  • Ein Drahtmodell oder Video, das detailliert genug ist, um dem Kunden die Interaktion zu ermöglichen.

Die Entwicklung eines MVP sollte keine großen Entwicklungsinvestitionen erfordern. Vorzugsweise sollten Sie Investitionen so weit wie möglich beschränken und die Anzahl der Hypothesen, die gleichzeitig getestet werden, minimieren. Dann verbessern Sie die Lösung mit jeder Iteration und jedem Release bewusst in Richtung einer skalierbaren Lösung, die mehrere Erfindungsdisziplinen darstellt.

Beschleunigen der MVP-Entwicklung

Die Markteinführungszeit ist entscheidend für den Erfolg jeder Innovation. Schnellere Releases führen zu schnellerem Lernen. Schnelleres Lernen führt zu Produkten, die schneller skalierbar sind. Manchmal kann dieser Prozess durch herkömmliche Anwendungsentwicklungszyklen verlangsamt werden. Häufiger jedoch werden Innovationen durch begrenztes verfügbares Fachwissen eingeschränkt. Budgets sowie Mitarbeiteranzahl und -verfügbarkeit können der Anzahl der Innovationen, die ein Team bewältigen kann, Grenzen setzen.

Personalengpässe und der Wunsch, Lösungen mit Empathie zu erstellen, haben einen schnell wachsenden Trend zu Citizen Developers ausgelöst. Diese Entwickler verringern Risiken und bieten Skalierbarkeit innerhalb der professionellen Entwicklungscommunity einer Organisation. Citizen Developer sind Experten im Hinblick auf die Kundenerfahrung, aber nicht als Engineers geschult. Diese Personen verwenden Prototyptools oder einfachere Entwicklungstools, die von professionellen Entwicklern möglicherweise abgelehnt werden. Diese geschäftsorientierten Entwickler erstellen MVP-Lösungen und testen Theorien. Bei guter Abstimmung können aus diesem Prozess Produktionslösungen hervorgehen, die zwar einen Mehrwert bieten, aber die Überprüfung der Hypothese für eine ausreichend effektive Skalierung nicht erfolgreich bestehen. Teams können die Lösungen auch verwenden, um einen Prototyp zu validieren, bevor mit der Skalierung begonnen wird.

Im Rahmen jedes Innovationsplans sollten Cloudeinführungsteams ihre Portfolios diversifizieren, um die Bemühungen von Entwicklern ohne Programmiererfahrung zu berücksichtigen. Durch die Skalierung der Entwicklungsarbeit können Sie mehr Hypothesen bei geringeren Investitionen erstellen und testen. Wenn Sie eine Hypothese validieren und einen ansprechbaren Markt identifizieren, können professionelle Entwickler die Lösung mithilfe moderner Entwicklungstools härten und skalieren.

Letztes Erstellungshindernis für die Lösung: Unbehagen des Kunden

Bei starker Kundenempathie sollte ein eindeutig vorhandenes Problem leicht zu erkennen sein. Das Unbehagen des Kunden sollte offensichtlich sein. Während der Erstellung des Projekts arbeitet das Cloud-Adoption-Team an einer Lösung zum Testen einer Hypothese anhand eines Problemfalls beim Kunden. Wenn nur die Hypothese, nicht aber der Problemfall klar definiert ist, basiert die Lösung nicht wirklich auf Kundenempathie. In diesem Szenario ist das Erstellen der Lösung nicht der richtige Ausgangspunkt. Investieren Sie stattdessen zunächst in den Aufbau von Empathie und das Lernen von echten Kunden. Der beste Ansatz für das Entwickeln von Empathie und das Überprüfen von Problemfällen ist ganz einfach: Hören Sie Ihren Kunden zu. Investieren Sie Zeit, um den Kunden zu treffen und ihn zu beobachten, bis Sie einen häufig auftretenden Problemfall identifizieren können. Sobald Sie den Problemfall des Kunden verstanden haben, können Sie eine hypothetische Lösung zum Beheben dieses Problems testen.

Unter welchen Umständen dieser Ansatz nicht angewendet werden sollte

Es gibt viele gesetzliche, Compliance- und Branchenanforderungen, die einen alternativen Ansatz erfordern könnten. Dieser Ansatz ist möglicherweise nicht geeignet, wenn öffentliche Releases einer entstehenden Lösung

  • ein Risiko für Patentlaufzeiten, Schutz des geistigen Eigentum oder Kundendatenlecks darstellen
  • gegen festgelegte Complianceanforderungen verstoßen

Wenn derartige Risiken bestehen, sollten Sie sich an einen Rechtsbeistand wenden, bevor Sie einen gezielten Ansatz für die Releaseverwaltung verwenden.

References

Einige Konzepte in diesem Artikel basieren auf Themen, die in The Lean Startup von Eric Ries behandelt werden.

Nächste Schritte

Nachdem Sie eine MVP-Lösung erstellt haben, können Sie den Empathie- und Skalierungswert messen. Erfahren Sie, wie Sie die Auswirkungen für Kunden berechnen.