p1010396

Agile Sturheit

Ob es darum geht, die Kapitalgeber zum eigenen StartUp oder die Entscheider im Unternehmen von der Schaffung des Produktes zu überzeugen, die Situation ist zumeist dieselbe: Die Zeit, sich mit dem Thema „ausführlich“ zu beschäftigen wird oft erst dann gewährt, wenn die Entscheidung pro/contra gefallen ist.

Die Folgekosten in den meisten Unternehmen sind beachtlich – Die erwarteten Kosten zur Umsetzung entsprechen nicht dem Plan, Termine können nicht gehalten werden und/oder der Markterfolg wird um ein vielfaches verfehlt. Im heutigen Blogbeitrag wollen wir kurz skizzieren, welche planerische Abgrenzung hilft, diese Problematik im Vorfeld weitestgehend aufzulösen und – falls das Umfeld nicht beweglich ist – wie Euch „agile Sturheit“ in der Umsetzung helfen kann.

Gehen wir zunächst in die ideale Welt (Gründer, CEOs, Inhaber – das ist für Euch): Wenn es Euch möglich ist, definiert das Wort „Business Case“ um! Eine Vielzahl der Business Cases von denen wir hören, nutzen ein wesentliches Fundament nicht: Die Einbeziehung der (möglichen) Kunden durch High-Fidelity Prototyping.

Warum spielt Prototyping eine so große Rolle? Schließlich sieht man doch, was der Wettbewerb tut, man kennt den „eigenen Markt“ schon lange, Umfragen haben zudem klare Bedürfnisse ermittelt, auch alle „Experten im Netzwerk“ haben schon zugestimmt, was soll das mit dem High-Fidelity Prototype und der Innovationskraft?

High-Fidelity

Nun, wenn wir vor drei Jahren den „Markt“ und die „Netzwerke“ befragt hätten, ob es Bedarf für ein Mobiltelefon mit integriertem MP3-Player und einfacher Bedienung gibt – wir wären auf Unverständnis gestoßen, da es diese Geräte vermeintlich bereits überall zu kaufen gab. Wir wissen aber ganz genau, dass das iPhone jeden gefesselt hat, der es in die Hände bekommen hat. Wichtig: Das Gerät hat uns überzeugt, obwohl wir die Funktionen nur angedeutet bekamen. Noch heute zeigt die TV-Werbung einfach nur Beispiele für die Nutzung des Gerätes.

Anzeige

High-Fidelity bedeutet also nicht, dass das Gerät fertig ist und jede Funktion perfekt; die Usability und das Design müssen aber bereits schlüssig vorliegen, um den Effekt auf den Nutzer abschätzen zu können und damit realistisch abschätzen zu können, welchen „Wert“ potenzielle Kunden dem neuen Produkt zumessen. Ein solchermaßen ermittelter Wert für den Kunden gibt bessere Indikatoren für eine mögliche Bepreisung und das zu erwartende Maß an Weiterempfehlung als jede Umfrage, die im Vergleich wie ein schwaches „Trockenschwimmen“ erscheint.

Doch selbst wenn man dem Business Case ohne HiFi-Prototype vertraut und keine Möglichkeit bekommt, einen solchen zu entwickeln, sollte man unmittelbar vor oder spätestens zu Beginn der Software-Entwicklung einen Prototypen entwickeln. Dabei kann beispielsweise der Aufwand zum Schreiben einer klassischen, monolog-artigen Spezifikation der Interaktion in die Entwicklung eines Prototyps gewandelt werden.

Die kontinuierliche Möglichkeit der Interaktion mit dem Entwurf (Prototypen) zeigt die Schwächen der eigenen Konzeption auf und liefert damit wesentliche Fragen und kurz darauf durch eine neue Iteration auch die Antworten, die andernfalls später in zeit- und kostenintensiven Änderungen in der Entwicklung resultieren würden. Die Pappmaché-Front des Prototypen ist wesentlich änderungswilliger als das Hochleistungs-Carbon des Produktionscodes. Er hilft allen Beteiligten wie auch den Entwicklern das Produkt besser zu verstehen. Die aus dem Erlebnis des Prototypen gewonnenen Erkenntnisse helfen sogar, den Kern des Produktes zu identifizieren und das Produktkonzept von „Featuritis“ zu entschlacken.

Aber manchmal kommt es eben doch anders…

Letztlich gibt es sie aber doch immer wieder – die Chancen eines Produktes, die es nicht gestatten, einen Prototyp frühzeitig zu entwickeln; weil Lieferanten nicht befragt werden können, da das eigene Vorhaben bis zum Projektstart geheim gehalten werden muss; oder ein Budget zur genaueren Sondierung erst bei Beauftragung verfügbar wird. Auch in dieser Situation sollte sich der Produktmanager Feedback einholen – gleich wie minimal: Zur Not muss ein einfacher Click-Dummy aus Mock-ups an internen Kollegen (à Geheimhaltung) verwendet werden, um Feedback einzusammeln, auch wenn es deutlich weniger repräsentativ ist.

Anzeige

Sturheit ist gefragt: Jede Veränderung, die fortan in das Projekt eingebracht wird, hat ein generelles Problem: Es ist eine Veränderung. Gleichgültig, wie oft wir „Embrace Change“ hören – es ist ein Ziel, keine Wahrheit. Veränderung der Produktinhalte kann die gewählte Architektur eines Systems unpassend erscheinen lassen, die mühsam erarbeitete Basisterminologie über den Haufen werfen, oder in sonst einer Form die Planung verändern. Ob es nun Projektmitarbeiter sind, die daran zweifeln, ob der Produktmanager denn überhaupt weiß, was er will – oder ob das Controlling bei der Geschäftsführung einwirft, dass das Budget nicht unter Kontrolle sei: Veränderung kann Misstrauen wecken und das Projekt aus dem Rhythmus bringen.

Es braucht also eine gewissen Sturheit des Produktmanagers, Änderungen abzuwehren. Die goldene Regel lautet daher „Messen statt Meinen“ – alle Änderungswünsche, aus dem Produktmanagement, dem Vertrieb, einem Investor oder sonstigen Quellen sollten zwingend durch User Testing auf Nützlichkeit (Value) und Nutzbarkeit (Usability) getestet werden, bevor sie den Weg Richtung Produktion nehmen dürfen. Von diesem Ansatz müssen alle überzeugt werden – was zumeist auch durchsetzbar ist, da es ein transparentes Prinzip darstellt.

Agilität gefordert: So relevant es ist, Veränderungen zu minimieren, so wichtig ist es, Veränderungen nicht aus Prinzip auszuschließen. Stellt sich im User Testing heraus, dass das Produkt zwingender Änderung bedarf – dann muss diese auch erfolgen. Die Kunst liegt hier darin, den Wert einer nachträglichen Veränderung gegen die Folgekosten abzuwägen: Gefragt sind hierbei möglichst messbare Punkte – steigert sich die Conversion Rate? Sinken die Kosten im Betrieb? Gibt es einen Frustrationsfaktor an zentraler Stelle, der den Net Promoter Score abstürzen lassen könnte? Muss eine günstigere Lösung gefunden werden, da die Probanden das Pricing nicht akzeptieren? Ist ein Missbrauchsszenario mit einer abschätzbaren Schadensgröße identifiziert worden?

Der schwierige Drahtseilakt in dieser Projektsituation ist, zwischen Nutzen und Schaden jeder Veränderung abzuwägen. Die wichtigste Vorbereitung neben dem Prototypen ist also die Definition relevanter Kennzahlen für das eigene Produkt: Ganz klar für den CFO sind finanzrelevante Kennzahlen (Umsatz, Ertrag, DBA1, ROI etc.) entscheidend, aber neben diesen Revenue-Stream-Kennzahlen sind weitere Kennzahlen wie im vorigen Absatz darzustellen, um die änderungsverneinende Sturheit von Ignoranz und die änderungserzwingende Agilität von Änderungswahn unterscheidbar zu machen.

Wir wünschen Euch allen bei der Schaffung Eures nächsten Produktes die notwendige Sturheit, die geforderte Agilität und vor allem die Metriken, um in der passenden Situation die richtige Qualität zu wählen.

Über die Autoren:

ralf-westbrockDiplom-Informatiker Ralf Westbrock sammelte ab 1995 parallel zu seinem Studium umfassende Erfahrungen als Software-Entwickler und Business Analyst in der damals ein Jahr alten DCon Software & Service GmbH. Von 2000 bis 2006 sammelte er detaillierte Erfahrungen im Customer Risk- und Customer Value Management – zunächst als Software-Entwickler der LHS Group und 2003 als Leiter Produktentwicklung der SHS Informationssysteme AG. Derzeit gestaltet er als Senior Product Manager der Wirecard AG den Internet-Bezahldienst Wirecard.

christian-von-hammel-bontenDiplom-Wirtschafts-Informatiker Christian von Hammel-Bonten startete 1996 seine berufliche Laufbahn als Produktmanager bei der Brokat Infosystems AG. Er wechselte 1999 als Leiter des Produktmanagements zur NorCom AG nach München und im November 2002 zur Wirecard AG. Dort verantwortete er das Produktmanagement und -marketing im Bereich elektronische Internet-Zahlungsabwicklung, Risikomanagement und Betrugsprävention und Kartenherausgabe. Seit Juli 2009 leitet er das Produktmanagement bei ClickandBuy.

GD Star Rating
loading...
Alle Bilder in diesem Artikel unterliegen der Creative-Commons-Lizenz (Namensnennung-Keine Bearbeitung, CC BY-ND; Link zum rechtsverbindlichen Lizenzvertrag). Ausgenommen sind anders gekennzeichnete Bilder unter anderem von Panthermedia, Fotolia, Pixelio, Morguefile sowie Pressefotos oder verlagseigenes Bildmaterial.