Das Lean-UX-Canvas am Beispiel eines Nicht-Softwareprodukts erklärt

Das Lean-UX-Canvas am Beispiel eines Nicht-Softwareprodukts erklärt

Was haben eine Agile Transformation, die Dienstleistung einer Personalabteilung und ein Softwareprodukt gemeinsam?

Alles sind Produkte.

Es gibt einen Produzenten, einen Konsumenten und eine Problemstellung, welche, wenn sie gelöst wird, beiden Vorteile verspricht. Ich bin überzeugt davon, dass jede Person im Unternehmen ein Produkt herstellt. Dieses Produkt können wir vielleicht nicht anfassen, es wird nicht vom Kunden des Unternehmens verwendet, aber es ist sicherlich etwas, das das Leben seiner „Nutzer“ beeinflusst. Jeder Prozess, jede Richtlinie, Initiative oder Kampagne ist der Versuch von jemandem im Unternehmen, das Verhalten von jemand anderem im Unternehmen zu ändern. Das macht für mich den wahren Kern eines Produkts aus. Und Outcomes, also Verhaltensänderungen der „Nutzer“, die sich positiv auf das Unternehmen auswirken, bestimmen den Erfolg dieses Produkts.

In dem Moment, in dem wir diese Tatsache akzeptieren, können wir alle Vorzüge, die uns ein Agiles Produkt-Mindset bietet, in allen Bereichen unseres Unternehmens gewinnbringend einsetzen. 

Kontinuierliche Verbesserung, stetiges Lernen und Kundenorientierung beschränken sich nicht auf kundenorientierte Initiativen, sondern auf das ganze Unternehmen. Genauso wie die Einführung eines neuen Softwareprodukts, ohne es zu testen, höchst riskant ist, birgt die Einführung einer neuen Arbeitsweise, eines internen Prozesses oder eines Incentive-Programms die gleichen Risiken. Was ist, wenn die Mitarbeiter es nicht annehmen? Was ist, wenn sie sich nicht so verhalten, wie wir es erwarten? Was ist, wenn wir das Programm für alle einführen und es sich dann negativ auf die Mitarbeiterbindung auswirkt?

Wenn bei der Entwicklung von Softwareprodukten solche Fragen nicht vorab beantwortet werden können, dann treffen wir Annahmen, formulieren diese als Hypothesen und testen sie. Um dies in einer strukturierten Art und Weise zu tun, verwenden wir in Produktentwicklungsteams das Lean-UX-Canvas. Wenn wir einsehen, dass auch die Personalabteilung ein Produkt bereitstellt, steht uns dieses Werkzeug auch hier zur Verfügung. 

Wie kann das konkret aussehen? 

Im Folgenden findest du ein Beispiel, wie das Lean-UX-Canvas verwendet wird, um eine Hypothese zu formulieren, welche einer Personalabteilung helfen soll, ihren Service, den sie den Fachabteilungen im Unternehmen bietet, zu verbessern. Wenn wir mit dem Lean-UX-Canvas arbeiten, beginnen wir beim Problem, welches das Unternehmen sieht.

Box 1: Geschäftsproblem

Eine gute Formulierung eines Geschäftsproblems beschreibt das aktuelle Ziel des Produkts, warum dieses Ziel nicht erreicht wird und eine ausdrückliche Aufforderung zur Verbesserung mit Erfolgskriterien, die keine bestimmte Lösung vorschreiben.

Verwenden wir folgendes Template:

[Unser Produkt] wurde für [diese Zielsetzung] entwickelt. 

Wir haben [auf diese Weise] festgestellt, dass das Produkt dieses Ziel nicht erfüllt, was [diese negative Auswirkung/dieses Geschäftsproblem] für unser Unternehmen verursacht. 

Wie können wir [unser Produkt] dahingehend verbessern, dass unsere Kunden aufgrund [dieser messbaren Kriterien] unser Produkt erfolgreicher nutzen können?

Dann lautet das Geschäftsproblem, welchem sich das Unternehmen gegenübersieht:

Die Personalabteilung soll eine nahtlose Einstellung von qualifizierten Kandidaten für alle Fachabteilungen ermöglichen.

Mittels Umfragen haben wir festgestellt, dass Einstellungen sehr lange dauern und die Fachabteilungen mit der Zusammenarbeit unzufrieden sind. Somit erreicht die Personalabteilung ihr Ziel nicht. Dies führt zu mangelndem Vertrauen in die Personalabteilung, zu der Wahrnehmung, dass die Personalabteilung den Fortschritt und die Innovation behindere und das Unternehmenswachstum hemme.

Wie können wir die Personalabteilung verbessern, sodass unsere Kunden zufriedener, die Einstellungen für die Fachabteilungen weniger zeitaufwendig und Fachbereiche mit der Zusammenarbeit zufriedener sind?

Nachdem die Problemstellung formuliert wurde, beschreiben wir in Box 2, woran wir erkennen, dass das Problem gelöst wurde.

Box 2: Geschäftsergebnisse

Dabei lassen wir uns von der folgenden Frage leiten: „Was werden die Nutzer, Kunden oder die Zielgruppe anders machen, wenn wir das Geschäftsproblem auf eine Weise lösen, die für sie einen Mehrwert darstellt?“

  • Die Fachabteilungen verstehen den Mehrwert, den ihnen die Personalabteilung liefert
  • Die Fachabteilung ist zufriedener mit der Zusammenarbeit mit der Personalabteilung
  • Die Fachabteilungen benötigen weniger Zeit für Einstellungen, wenn die Personalabteilung sie dabei unterstützt

Box 3: Nutzer

Im nächsten Schritt müssen wir Annahmen treffen, wer unsere Nutzer sind. Dazu bieten Proto-Personas einen leichtgewichtigen Ansatz, da sie sich nicht, wie herkömmliche Personas, auf langwierige demografische Forschung stützen. Es handelt sich lediglich um leicht umsetzbare Annahmen, welche jederzeit aktualisiert werden können.

  • Name: Tom IT-Manager 
  • Verhalten: Sehr von sich und seinem IT-Wissen überzeugt
  • Bedürfnis: Möchte mehr Leute einstellen, um die Fähigkeiten seiner Abteilung im Bereich Machine Learning (ML) und Künstliche Intelligenz (KI) auszubauen 
  • Hindernis: Er denkt, er müsse die Stellenausschreibung, die Vorstellungsgespräche und die Einstellung von Mitarbeitern selbst erledigen. Einstellen bedeutet für ihn einen zeitlichen Mehraufwand, weshalb er häufig davor zurückschreckt oder zögert.

Box 4: Ergebnisse und Vorteile für die Nutzer

Um eine nützliche Lösung für unsere Nutzer zu entwickeln, müssen wir verstehen, was die Nutzer letztlich versuchen zu erreichen. Also das Ergebnis und die Vorteile, die sie dadurch erhalten. 

  • Ergebnis: Weniger Zeit mit Vorstellungsgesprächen für offene ML- und KI-Stellen verbringen
  • Vorteil: Mehr Zeit für das Management wichtiger Projekte der Fachabteilung haben

Box 5: Lösungen

Die Annahmen für die Nutzer und deren Ziele helfen uns jetzt, mögliche Lösungsvorschläge oder Produktfeatures zu designen: 

  • Mitarbeiter der Personalabteilung besuchen einen zweitägigen Einführungskurs in ML und KI 
  • Mitarbeiter der Personalabteilung lernen im Selbststudium die Grundlagen in ML und KI 

Das Ziel beider Lösungen ist, dass die Mitarbeiter der Personalabteilung genug Wissen erlangen, damit sie bewerten können, ob das Profil eines Bewerbers zur Stellenbeschreibung passt, und eigenständig ein erstes Vorstellungsgespräch mit Bewerbern durchführen können.

Box 6: Hypothesen

Die Nutzer, die wünschenswerten Ergebnisse und Vorteile für die Nutzer sowie die Lösung sind erst mal nur Annahmen. Diese müssen wir überprüfen, indem wir eine Hypothese dieser Form bilden:

Wir glauben, dass [das Geschäftsergebnis] erreicht wird, wenn [der Nutzer] erfolgreich [Vorteile oder Ergebnisse] mit [Lösung] erzielt.

In unserem Beispiel würde dies nun so lauten:

Wir glauben, dass die IT-Fachabteilung zufriedener mit der Personalabteilung ist, wenn Tom weniger Zeit mit der Einstellung neuer ML- und KI-Fachkräfte verbringt. Dies wird möglich, wenn die Mitarbeiter der Personalabteilung einen zweitägigen Einführungskurs in ML und KI besucht haben.

Hypothesen helfen uns zu entscheiden, ob der Aufwand für eine Funktion, ein Feature oder eine Lösung gerechtfertigt ist, und sie liefern uns einen ersten Test: 

Wenn wir den Abschnitt über die Ergebnisse, die Nutzer und den Nutzen einer Lösung nicht überzeugend ausfüllen können, ist diese Funktion oder Lösung dann wertvoll? 

Box 7: Risiken

Nachdem Hypothesen formuliert wurden, wie das Geschäftsproblem gelöst werden könnte, geht es darum, die Hypothesen mit Experimenten zu bestätigen oder zu widerlegen. Dazu müssen wir uns die Frage stellen: 

  • Was ist das Wichtigste, das wir zuerst überprüfen sollten?
  • Was ist die riskanteste Annahme, oder welche falschen Annahmen würden zu einem totalen Misserfolg führen?

Für die Hypothese aus Box 6 könnte folgendes Risiko bestehen:

Reicht das Wissen, welches der Besuch eines zweitägigen Einführungskurses in ML und KI liefert, wirklich aus, um in einem so komplexen Feld zuverlässig fähige Bewerber zu finden?

Box 8: Experimente

Nachdem identifiziert wurde, was das Wichtigste ist, dass wir zuerst herausfinden sollten, sollten wir uns die Frage stellen, welche Umsetzung den geringsten Aufwand bedeuten würde:

Werden die Mitarbeiter aus der Personalabteilung nach dem zweitägigen Einführungskurs in ML und KI die gleichen Bewerber auswählen, wie es auch die Fachabteilung bei Bewerbungen aus der Vergangenheit getan hat?

Der Personalabteilung steht nun nichts mehr im Wege, um diese Hypothese zu testen, und dadurch zu einem nutzerorientierten und agilen Ansatz bei ihrer Arbeit zu finden. Das wurde durch die Einsicht ermöglicht, dass auch die Personalabteilung letztlich ein Produkt entwickelt.

Aus meiner Erfahrung kommen wir schneller zu der Frage „Wozu tun wir das?“, wenn wir die Arbeit von Teams, die normalerweise keine Produktteams sind, so als Hypothesen formulieren, als ob diese Teams ebenso greifbare Produkte produzieren würden. Es hilft dem jeweiligen Team auch zu verstehen, dass sie ebenso Kunden haben und dass sich der Erfolg ihres Teams am Erfolg dieser Kunden bemisst. Überdies hilft es diesen Teams zu verstehen, dass die Arbeit nicht darin liegt, die breite Umsetzung von Maßnahmen und Richtlinien voranzutreiben, sondern das Risiko zu minimieren, dass die Maßnahmen von den Mitarbeitern nicht angenommen werden. 

Schlussendlich denke ich, dass darin der Weg zu einer erfolgreichen agilen Transformation des ganzen Unternehmens liegt. 

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert