Spezifikationen sein. Ihr Zweck ist es, den Designern und Programmierern zu verdeutlichen, was genau geschaffen werden muss.
Sind die Anforderungen zusammengetragen, wird das User-Experience-Designteam (vorausgesetzt, das Unternehmen verfügt über ein solches) mit dem Interaction Design, dem Visual Design und bei physischen Geräten mit dem Industrial Design beauftragt.
Schließlich werden die Anforderungen und die Design-Spezifikationen den Engineers vorgelegt. An dieser Stelle tritt für gewöhnlich Agile auf den Plan.
Die Programmierer werden die Arbeit typischerweise auf eine Reihe von Iterationen herunterbrechen – im Scrum-Prozess werden sie als »Sprints« bezeichnet. Es braucht also vielleicht ein bis drei Sprints, um die Idee auszugestalten.
Zu diesen Sprints gehört hoffentlich auch das QA Testing. Wenn nicht, wird das QA-Team dies nachholen und einige Tests vornehmen, um sicherzustellen, dass die neue Idee wie angekündigt funktioniert und nicht für weitere Probleme sorgt (die als Regressionen bekannt sind).
Sobald die QA grünes Licht gegeben hat, kann die neue Idee endlich bei echten Kunden zum Einsatz kommen.
Die Mehrheit der Unternehmen, ob groß oder klein, denen ich erstmals begegne, arbeiten im Wesentlichen genauso und tun das schon seit vielen Jahren. Doch diese Unternehmen klagen auch fortwährend über den Innovationsmangel und die sehr lange Dauer des Weges der Idee zum Kunden.
Ihnen ist vielleicht aufgefallen, dass ich zwar Agile erwähnt habe und dass so ziemlich jeder heute Agile für sich beansprucht, doch was ich gerade beschrieben habe, ist weitgehend ein Wasserfallprozess. Um den Programmierern Gerechtigkeit widerfahren zu lassen, muss gesagt sein, dass sie im Rahmen des größeren Wasserfall-Kontextes im Allgemeinen so viel Agile wie möglich anwenden.
Die meisten Teams werden vermutlich so arbeiten. Aber warum sollte das der Grund für so viele Probleme sein? Ziehen wir jetzt einmal die Verbindungslinien, damit wir genau erkennen können, warum diese weit verbreitete Arbeitsmethode für die meisten gescheiterten Produktvorhaben verantwortlich ist.
In der folgenden Liste führe ich auf, was ich für die zehn größten Probleme bei dieser Vorgehensweise halte. Denken Sie daran, dass jedes dieser zehn Probleme eine sehr ernste Angelegenheit ist, die allein schon ein ganzes Team ins Schleudern bringen kann. Viele Unternehmen haben jedoch mehr als eins oder sogar alle diese Probleme.
Zwar beansprucht so ziemlich jeder heute Agile für sich, doch was ich gerade beschrieben habe, ist weitgehend ein Wasserfallprozess.
1 Beginnen wir ganz oben – bei der Quelle der Ideen. Dieses Modell führt zu verkaufsgesteuerten Besonderheiten und zu stakeholdergesteuerten Produkten. Es gibt zu diesem zentralen Thema noch sehr viel mehr zu sagen, aber fürs Erste nur so viel: Das ist nicht die Quelle unserer besten Produktideen. Eine weitere Folge dieser Vorgehensweise ist die mangelnde Beteiligung der Teammitglieder. In diesem Modell haben sie nichts weiter zu tun, als zu implementieren – sie sind nichts als Söldner.
2 Als Nächstes wollen wir über den fatalen Irrtum bei diesen Business Cases sprechen. Um das klarzustellen, ich persönlich bin ein großer Befürworter von Business Cases, zumindest für Ideen, die eine größere Investition brauchen. Aber die Art und Weise, wie die meisten Unternehmen sie in diesem Stadium erstellen, um eine nach Prioritäten geordnete Roadmap zu erhalten, ist wirklich lächerlich, und zwar aus folgendem Grund. Erinnern Sie sich an die beiden wichtigsten Vorüberlegungen für jeden Business Case? Wie viel Geld Sie verdienen werden und wie viel es kosten wird? Also, die nackte, schonungslose Wahrheit lautet: In dieser Phase haben wir von beidem nicht die leiseste Ahnung. Genau genommen können wir das gar nicht wissen.Wir können nicht wissen, wie viel Geld wir verdienen, weil das komplett davon abhängt, als wie gut die Lösung sich erweist. Wenn das Team gute Arbeit leistet, könnte die Sache äußerst erfolgreich sein und wahrhaftig den Kurs des Unternehmens ändern. Die Wahrheit ist jedoch, dass viele Produktideen am Ende überhaupt nichts einbringen. Und das ist keine effekthascherische Übertreibung. Wirklich überhaupt nichts (das wissen wir aus A/B-Tests).Auf alle Fälle lautet eine der wichtigsten Lektionen beim Produktmarketing, zu wissen, was wir nicht wissen können, und wir können zu diesem Zeitpunkt einfach nicht wissen, wie viel Geld wir verdienen werden.Ebenso wenig Ahnung haben wir davon, wie hoch die Erstellungskosten sein werden. Ohne die eigentliche Lösung zu kennen, ist das für die Technik extrem schwer vorauszusagen. Die meisten erfahrenen Programmierer dürften es ablehnen, in diesem Stadium eine Schätzung vorzunehmen, aber manche werden zu einem T-Shirt-Größen-Kompromiss gedrängt – uns einfach zu sagen, ob es »S, M, L oder XL ausfällt«.Aber Unternehmen wollen diese nach Prioritäten geordneten Roadmaps unbedingt haben, und um einen zu erstellen, brauchen sie irgendein System zur Bewertung der Ideen. Also spielen die Leute das Business-Case-Spiel.
3 Ein sogar noch größeres Problem ist, zu sagen, was als Nächstes kommt, und an dieser Stelle sind die Unternehmen wirklich begeistert von ihren Product Roadmaps. Im Laufe der Jahre habe ich zahllose Roadmaps gesehen und die meisten davon sind im Wesentlichen Listen von Funktionen und Projekten. Das Marketing braucht diese Funktion für eine Werbekampagne. Der Verkauf braucht jene Funktion für einen neuen Kunden. Jemand möchte eine PayPal-Verknüpfung. Sie wissen schon, worauf ich hinauswill.Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen schlicht nicht funktionieren wird.Aber jetzt kommt das Problem – vielleicht das größte von allen. Es ist das, was ich als die beiden unbequemen Wahrheiten über Produkte bezeichne.Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen schlicht nicht funktionieren wird. Es gibt viele Gründe, warum eine Idee nicht umsetzbar ist. Der häufigste ist, dass die Kunden diese Idee einfach nicht so fantastisch finden wie wir. Also entscheiden sie sich, das Produkt nicht zu verwenden. Manchmal probieren sie es zwar aus, aber dann erweist es sich als so kompliziert, dass sich der Aufwand einfach nicht lohnt und die Kunden keinen zweiten Versuch unternehmen. Manchmal besteht das Problem darin, dass die Nutzer das Produkt zwar toll fänden, aber es stellt sich heraus, dass die Herstellung viel mehr erfordert, als wir gedacht haben, weshalb wir einfach nicht die notwendige Zeit und das Geld aufbringen können, um es anzubieten.Ich kann Ihnen garantieren, dass mindestens die Hälfte der Ideen in Ihrer Roadmap nicht das von Ihnen erhoffte Resultat bringen wird. (Übrigens, wirklich gute Teams schätzen, dass mindestens drei Viertel der Ideen nicht so laufen wie erhofft.)Als wäre das noch nicht schlimm genug, lautet die zweite unbequeme Wahrheit, dass selbst für die Ideen, die Potenzial beweisen, typischerweise etliche Iterationen notwendig sind, bis die Realisierung dieser Idee zu einem Punkt gelangt, an dem sie den notwendigen Geschäftswert erbringt. Wir nennen das Time to Money.Eines der wichtigsten Dinge, die ich über das Product Management gelernt habe, ist, dass diese unbequemen Wahrheiten sich einfach nicht umgehen lassen, egal wie clever Sie auch sein mögen. Und ich hatte das Glück, mit vielen wirklich außergewöhnlichen Produktteams zusammenzuarbeiten. Der tatsächliche Unterschied liegt darin, wie man mit diesen Wahrheiten umgeht.
4 Lassen Sie uns als Nächstes die Rolle des Product Managements in diesem Modell betrachten. Eigentlich sollten wir es gar nicht als Product Management bezeichnen– es ist genau genommen eine Form des Project Managements. In diesem Modell geht es mehr darum, Anforderungen zusammenzutragen und sie für die Programmierer zu dokumentieren. Lassen Sie mich an dieser Stelle nur sagen, dass dies um 180 Grad von der Realität des modernen Tech Product Managements abweicht.
5 Ganz Ähnliches gilt für die Rolle des Designs. Die Sache ist schon viel zu weit vorangeschritten, um dem Design zu seinem tatsächlichen Wert zu verhelfen, und was hier geschieht, sind in erster Linie »kosmetische Maßnahmen«. Der Schaden ist bereits angerichtet und wir versuchen jetzt bloß, eine Schicht Farbe darüberzupinseln. Die UX-Designer wissen, dass das nicht gut ist, aber sie geben sich Mühe, es so nett und stimmig wie möglich aussehen zu lassen.
6 Die vielleicht größte verpasste Chance in diesem Modell ist die Tatsache, dass die technische Seite viel zu spät ins Spiel gebracht wird. Wir sagen, wenn Sie Ihre Programmierer nur zum Coden einsetzen, nutzen Sie
