Es ist für viele Scrum-Teams ein leidiges Thema – „Oh Mann, schon wieder ein U-Boot!” heißt es dann schnell über den Flurfunk. Was ist so ein U-Boot oder Speed-Boot?
1. Speed-Boot oder U-Boot?
2. Beispiel Speed-Boot-Projekt
3. Wie funktioniert ein Speed-Boot-Projekt?
4. Fazit
1. Speed-Boot oder U-Boot?
Eigentlich möchte man ein Speed-Boot starten, das an der eigenen Organisation vorbei, möglichst schnell und unabhängig, etwas Spezielles ausprobiert. Leider werden diese Speed-Boote oftmals auch schnell zu einem U-Boot, da sie doch durch irgendwelche Abhängigkeit langsam in der Organisation auftauchen , und das meist ungeplant. Der Gedanke „Ohne Abhängigkeit nebenher“ steht natürlich völlig im Widerspruch zu dem Gedanken „Was nicht auf einer Product Roadmap steht, gibt es auch nicht“, das muss jedem Speed-Boot Fahrer klar sein.
Allerdings sind die Produkt-Teams mit deren Product Roadmaps derart hart getaktet, dass sie sich nebenher gar kein weiteres Experiment leisten können. Eigentlich sehr schade, aber bei einer laufenden Organisation mit zahlreichen Produkt-Teams, Product Roadmaps und übergeordneten Zielsetzungen ist es schwierig, mal eben etwas völlig Neues zu starten. Denn es ist ein schmaler Grat, die Produkt-Teams durch andere Themen – die nicht direkt auf die Unternehmensziele einzahlen – einerseits nicht ablenken zu wollen, aber andererseits ihnen auch nicht das Gefühl zu geben, bei den „coolen“ Innovationen nicht mitmachen zu dürfen.
2. Beispiel Speed-Boot-Projekt
Die Implementierung einer externen Applikation oder eines Prototyps ohne Systemabhängigkeiten ist ein gutes Beispiel für ein Speed-Boot. Ich habe zum Beispiel die Trusted Shops iOS App, damals in drei Monaten nebenher mit einer externen Agentur implementiert und im Appstore von Apple veröffentlicht. Es war meine erste Mobile App, eine tolle Erfahrung. Und vor allem auch ein cooles Feature für die Trusted Shops Kunden. Demnach ein erfolgreiches Speed-Boot-Projekt. Anschließend konnte ich ein neues Mobile Produkt-Team starten, welches sofort auf einem lauffähigen Minimum Viable Product (MVP) aufsetzen konnte.
3. Wie funktioniert ein Speed-Boot-Projekt?
Aber wie kann ein Speed-Boot funktionieren, hat man doch eigentlich selbst keine Zeit? Das Ziel darf immer nur ein möglichst schnelles und günstiges MVP der Idee sein. Der Projektumfang muss klar definiert sein, sonst verliert man sich später in den Details und hat keine Chance, das Projekt mit einem guten Ergebnis zu Ende zu bringen. Das Tagesgeschäft frisst ein zu großes Speed-Boot-Projekt schneller auf, als man es sich vorstellen kann. Denn das Projektmanagement dieser kleinen Innovationsprojekte gestaltet sich oftmals als aufwendig und wird häufig unterschätzt. Für alle anderen wie Entwickler oder UXler empfiehlt es sich, auf externe Freelancer zurückzugreifen.
Ist das lauffähige MVP erst mal gebaut, muss es auftauchen. Der große Vorteil eines lauffähigen MVPs ist, dass man nicht mehr auf dem Bierdeckel mit Stakeholdern oder Kunden diskutieren muss.
Mit einem lauffähigen MVP kann jeder das Produkt direkt ausprobieren und sich überzeugen lassen. Genauso gilt es dann als Nächstes, so früh wie möglich die ersten echten Kundenfeedbacks einzuholen.
Durch die eigene Vertriebsmannschaft lassen sich diese Produkte direkt bei den Kunden ausprobieren, um echtes Kundenfeedback möglichst früh zu erhalten. Ich persönlich bevorzuge jedoch eher Webinare, da ich hier mehrere Kunden gleichzeitig erreichen kann. Aber egal, wie die Feedbacks dieser ersten Testkunden ausfallen, es sind die Erfahrungen, die später über Erfolg oder Misserfolg des Produktes entscheiden.
Ist das MVP ein Erfolg, muss in der bestehenden Organisation ein Platz für das neue Produkt gefunden werden. Dies ist zudem immer wieder eine tolle Gelegenheit, das Team-Setup nochmals zu hinterfragen und auch wieder ein bisschen durchzurütteln. Denn neue Technologien oder neue Produkte sind für jeden Mitarbeiter immer wieder eine Chance, sich neu zu beweisen.
4. Fazit
Mein Fazit: Speed-Boote nebenher zu entwickeln, birgt eine Menge Arbeit und wird vom eigenen Team nicht immer gern gesehen. Aber eigentlich kann man nur gewinnen. Sogar für den Fall, dass das neue Produkt kein Erfolg werden sollte, wird man viele Erfahrungen aus der Arbeit mitnehmen. Und eine ausprobierte Idee ist besser als eine Idee, die man noch Jahre im Kopf behält und über die man sich ärgert, wenn sie jemand anderes dann irgendwann erfolgreich umgesetzt hat, oder?
4.1. 100% Support vom Management
Möglicherweise der meist unterschätzte Aspekt beim Growth Hacking, Speed-Boot-Projekten oder bei größeren Digitalisierungsvorhaben: „Das Management steht nicht zu 100% dahinter.“
Vor allem hinsichtlich der Priorisierung der Product Roadmaps gibt es in Unternehmen, aber auch in Start-ups oftmals unterschiedliche Meinungen. „Was machen wir als Nächstes?“ ist somit eine der kritischsten Fragestellungen, richtig? Für die Beantwortung dieser Frage benötigt der Growth Manager oder der Chief Product Owner stets das 100-prozentige Vertrauen des Managements. Dieses Vertrauen muss sich ein Chief Product Owner durch hervorragendes Stakeholder-Management immer wieder erarbeiten. Alle Stakeholder müssen immer gut abgeholt sein. Gut heißt auch auf der richtigen Flughöhe. Nicht zu hoch, so dass man nicht konkret genug ist. Aber auf keinen Fall auch zu tief, damit man sich in der Diskussion über Details verliert.
Eine der größten Herausforderungen, die ich in den letzten Jahre mit den Product Roadmaps hatte, war der Aspekt, dass die Beschreibung des Features oder der zu erreichenden Meilensteine meistens von niemand anderem verstanden wurde als vom Produkt-Team selbst. So hilft eine Product Roadmap natürlich nicht als Kommunikationsmittel, sondern schreckt andere eher ab. Das ist bedenklich, denn man möchte nicht als Black-Box angesehen werden – denn das macht Produktentwickler angreifbar. Einer Black-Box vertraut schließlich niemand.
Hinzu kommt die Dimension Zeit. Wie viel Zeit hat man zum Ausprobieren? Wie realistisch sind die Ziele gesetzt worden? Sind sie vielleicht nur an den Zahlen der Konkurrenz ausgelegt statt tatsächlich auch mit Hilfe einer Machbarkeitsanalyse? Sind wir ehrlich, kaum ein Speed-Boot-Projekt oder Produkt funktioniert schon in der ersten Iteration so, wie man sich das gewünscht hat. Aber oftmals ist das leider die Erwartungshaltung des Managements. Meine Erfahrung ist dazu, dass man schon im Vorfeld umso härter gemeinsam am gegenseitigen Erwartungsmanagement und den gesetzten Zielen arbeiten muss.
Ziele müssen sportlich, aber realistisch sein. Sind diese Ziele dann in der vorgesehenen Zeit nicht erreicht worden, dann müssen auch alle den Mumm haben, das Speed-Boot-Projekt oder das Produkt zu canceln. Nichts ist schlimmer, als Zeit und Ressourcen zu verbrennen, indem man das berühmte tote Pferd immer weiterreitet.
Beitragsbild by JuralMin
https://pixabay.com/en/boat-sea-ocean-water-blue-sky-1626519/
