Product Roadmaps 📋: So optimierst du deine Entwicklung

Intro: Digital Kompakt. Heute aus dem Bereich Tech mit deinem Moderator Joel Kaczmarek. Los geht's.

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von Digital Kompakt und heute habe ich wieder meine beiden Product-Granden an meiner Seite, nämlich den lieben Björn Wagner und den guten Till Reiter. Die arbeiten beide bei SAP Signavio. Kennt ihr auch, weil der liebe Gero ja regelmäßig hier ist und über Sales mit mir redet. Und Björn ist dort VP Engineering und Till VP Product. So, und wenn die beiden da sind, dann reden wir über Product-Themen. Wer hätte es gedacht? Und da haben wir uns heute ein besonderes Thema vorgenommen, wo die beiden sich ein bisschen streiten wollen, haben sie mir gesagt. Nämlich Product, Roadmaps und Engineering-Prioritäten. Das heißt, wir reden darüber, wie man eigentlich seine Roadmap in Sachen Product mal so planen kann. Das heißt, wie führe ich das ein? Was sind so Pros und Kontras davon? Wie stimme ich das ab? Welche Priorisierungsherausforderungen habe ich? Ziele, Ressourcenmanagement und, und, und. Also heute kommt man auf seine Kosten und ich hoffe auf ein bisschen Zoff, ihr beiden. That being said, moin. Hallo.

Björn Wagner: Hallo Joel.

Joel Kaczmarek: Ihr habt euch so gerne, ihr zofft euch gar nicht, oder?

Till Reiter: Habt ihr mich geködert, gebt es doch zu.

Björn Wagner: Konstruktives Streitgespräch vielleicht.

Joel Kaczmarek: Okay, okay. Fangen wir basic an, wie man es immer macht im Leben, mit Definitionen. Hurra, hurra. Erzählt doch mal, was ihr so, was ihr begreift, wenn man sagt, Roadmap, was da für euch dazugehört, was so das kleine 1x1 davon ist, ganz simpel.

Björn Wagner: Na ja, eine Roadmap zeigt dir eigentlich auf, jetzt in einem Software-Business, was willst du bauen und wann. Steckt ein strategischer Plan dahinter mit einer bestimmten Vision und dann kannst du eben deine Prioritäten ablesen und welche Fortschritte du zu welcher Zeit planst zu machen. Und oft gibt es natürlich die Verwirrung, dass Leute denken, das ist jetzt alles in Stein gemeißelt und man veröffentlicht eine jährliche Product Roadmap und daran kann man nichts mehr ändern. Das ist natürlich nicht das Ziel, die muss man auch relativ flexibel bleiben. Aber ich sage mal, ohne einen groben Plan steht man relativ nackt da, wenn es darum geht, mit seinen Stakeholdern in der Company und außerhalb der Company zu kommunizieren.

Joel Kaczmarek: Wenn ihr mir vorher sagt, dass ihr da geteilter Meinung seid, überlege ich jetzt gerade, wen ich nach Pro und wen nach Contra frage.

Till Reiter: Ich bin nicht grundsätzlich gegen Roadmaps. Ich glaube, es gibt gute Gründe, warum man sie auch braucht teilweise. Vor allem im B2B. Also warum braucht man Roadmaps? Häufig ist es halt so, dass Kunden, wenn sie bestimmte Produkte evaluieren und gerade im B2B entscheidet man sich ja sehr, sehr lange über mehrere Jahre, ein Produkt einzuführen. es ihnen halt wichtig, nicht nur zu verstehen, was das Produkt heute kann, sondern auch, was kann das Produkt in der Zukunft. Das heißt, der Kunde kauft nicht nur das Produkt heute, sondern er guckt auch immer, was passiert in der Zukunft. In besonderen Szenarien sind dann, wenn bestimmte gewünschte Funktionalitäten vielleicht noch nicht verfügbar sind, man aber glaubhaft versichern kann und der Kunde auch den Roadmaps vertrauen kann und dass es in einem bestimmten Zeitraum noch geliefert wird, dass man sich dann trotzdem halt für das Produkt entscheidet. Ich habe das sogar, also häufig im B2B, aber ich habe das auch im B2C schon öfter gesehen, dass Kunden gerade bei neuen Produkten, dann hoffe ich, sagen, hier fehlen mir noch zwei, drei Funktionalitäten, aber wenn man dann sagen kann, hey, ja, das haben wir geplant und im nächsten halben Jahr oder so kommt das vielleicht, dass man die Kunden dann doch noch davon überzeugen kann, sich für das Produkt zu entscheiden. Also das ist so. das Why dahinter vielleicht. Also die Roadmap ist eigentlich vielleicht nur das Artefakt, aber das Wichtigste ist eigentlich das Vertrauen dahinter, dass man halt auch entsprechend liefern kann.

Joel Kaczmarek: Ich bin gerade so ein bisschen baff, dass ich das erste Mal in meinem Leben habe, dass ein Techie ein Sales-Thema als Pro von einer Roadmap einführt. Hätte ich jetzt genau gegenteilig gedacht.

Björn Wagner: Ja, das sind natürlich noch andere Pros, die auch für Björn und seine Engineering-Organisation wichtig sind. Eine klare Richtung, Priorisierung. Wie schon gesagt, das Stakeholder-Management ist ja nicht nur mit einer Go-To-Market-Organisation. Das ist natürlich auch zwischen deinen Engineering-Units. Und dann Kontrast in eben die Rigidität, die damit kommen kann, mögliche Fehlinterpretationen etc., Was Björn jetzt auch erwähnt hat mit dem B2B, B2C, stimme ich zu. Ich glaube, niemand interessiert sich jetzt für die Roadmap von Facebook. Ich weiß nicht mal, ob sie eine veröffentlichen. Aber man kann natürlich davon ausgehen, dass sie intern eine haben. Zum Beispiel, wenn jetzt bei Facebook das Mobile-Team sagt, wir releasen Videoreels im März, dann wird es bestimmte Plattform-Teams geben und die Web-App etc., die damit auch arbeiten muss. Also für die interne Planung ist es dann immer noch ein Requirement. Ob das dann oft Roadmap genannt ist, ist eine andere Frage.

Till Reiter: Was ich auch schon im B2C gemacht habe, es gibt zum Beispiel so Plattformen wie Product Board, wo dann halt auch Leute ihre Wünsche, Requirements, Probleme submitten können. Und es ist schwierig, weil wir normalerweise keinen Feedback-Channel hatten. Also die Kunden tragen da fleißig Feedback ein, aber sie kriegen nie so wirklich eine Rückmeldung. Und wenn man ihnen dann zumindest so einen Ausblick geben kann, wann bestimmte Wünsche dann erfüllt werden oder auch sagen kann, hey, nein, das planen wir gar nicht, da haben wir mal sehr, sehr gutes Feedback auch im B2C bekommen, wo das geholfen hat.

Björn Wagner: Ja, aber jetzt müssen wir eigentlich zurück zu Joels Frage, wieso du kein wirklicher Fan von Roadmaps bist.

Till Reiter: Ja, sehr gute Frage. Also grundsätzlich, mein Hauptproblem ist eher mit dem zweiten Teil, was du gesagt hast, Till, dass man das intern zur Priorisierung und zum Alignment verwendet. Und hier, ich glaube, Roadmaps haben Wert gegenüber den Kunden, aber um die interne Entwicklung zu steuern, voranzutreiben, sehe ich andere Mechanismen, die deutlich besser getrieben sind. Also wenn man sich auch so anguckt, Vorbilder für gute Produktorganisationen, wird sehr, sehr viel davon gesprochen, Teams über Outcomes zu steuern. Das heißt nicht mit Engineering-Teams darüber zu reden, bitte baut mir jetzt Features ABC, sondern darüber zu sagen, hey, das sind die Probleme, die wir lösen wollen, das sind die Ziele, die wir erreichen wollen. Und dass dann die Teams selbstständig diese Probleme als Experten umsetzen und vorantreiben. Und natürlich kommen dann aus der Planung, aus der Discovery, kommen dann gewisse Roadmap-Items raus. Aber es ist halt nicht, meiner Meinung nach, kein gutes Wiehinkel, um intern Alignment und Fokus zu schaffen.

Joel Kaczmarek: Aber jetzt mal für den Dummi am Tisch, also was du gerade beschrieben hast, Jobs to be done, wenn ich mich von Problemen nähere, dann baue ich doch auch eine Roadmap, nur dass quasi das Item, was ich auswähle zum Clustering, also welcher Pattern, auf den ich gucke, ein anderer ist. oder bin ich da falsch gewickelt?

Till Reiter: So gesehen, Roadmap sind ja Features, die delivered werden. Und man kann ja ganz viele Features erfolgreich deliveren und die Roadmap am besten erfüllen, weil man kann halt seine Businessmetriken damit total verfehlen. Das heißt, es ist meiner Meinung nach wichtiger, intern halt über wirklich ein Outcome zu sprechen. Und ja, denn in der Planung und so weiter kommt man dann zu dem Punkt, dass wir bestimmte Features bauen, von denen wir dann glauben, dass sie die Metriken, die Ziele, die Businessziele, die wir erreichen wollen, wirklich erfüllen. Aber man sagt halt nicht, man baut Features. Weil wenn man auch ein zu starkes Roadmap-Denken hat, dann kommt man eher dahin, Wir bauen jetzt hier 10 Features, wir shippen die und dann war es erfolgreich, aber man kümmert sich gar nicht mehr darum, was denn im Nachhinein passiert. Funktionieren die Features so wie gedacht oder erzeugen sie den gewünschten Wert? Deshalb glaube ich, dass wie gesagt für interne Sachen sowas wie OKRs, strukturiert mit Zielen, viel mit Metriken zu arbeiten, bessere Steuerungsmöglichkeiten sind als ein sehr starkes Roadmap-Feature-Mindset.

Björn Wagner: Aber da hast du eigentlich ja jetzt schon gesagt, die Roadmap ist ein Artefakt. Man kann darüber debattieren, wann man das haben will. Ich muss mich da gar nicht mit dir schreiten zu sagen, dass man es nicht von Anfang an benutzt, zu sagen, hier ist die Roadmap, viel Spaß. Aber irgendwann im Prozess braucht man das. Und vielleicht macht das dann Sinn, wenn wir jetzt sagen, okay, wie stimmt man zwischen Engineering und Product die Arbeit ab? Du bist ja auch ein Fan, Björn, vom Double-Diamond-Modell zum Beispiel. Und ich denke, da finden wir genau in der Mitte, wo die zwei Diamanten aufeinandertreffen, die Roadmap. Aber vielleicht willst du mal kurz erläutern, wie das bei uns so strukturiert ist. oder im Optimalfall strukturiert ist.

Till Reiter: Die grundsätzliche Frage ist, es reden ja ganz viel über agile Softwareentwicklung, Design Thinking, Double Diamond, Design Prozesse. Und die magische Frage ist jetzt, wie verbindet man die beiden Welten so ein bisschen?

Joel Kaczmarek: Ich kenne Double Diamond nicht, also hol mich gerne danach ab im Zuge deiner Erklärung.

Till Reiter: Double Diamond geht eigentlich von einem Doppelzyklus aus an der Stelle. Das heißt, man hat zwei Phasen. Man findet zuerst heraus, ob eine Idee, man fängt mal mit einer Idee an, die ein Problem lösen will. und validiert dann erstmal, ob die Idee denn wirklich wertstiftend ist. Das heißt, man validiert mit Kunden, interviewt ganz viel Kunden, versucht zu verstehen, sind das die wirklichen Probleme der Kunden, hat man die Probleme richtig verstanden, bis dann dann auch zu verstehen, also nur weil man das Problem des Kunden löst, heißt es ja noch nicht, dass man damit Geld verdienen kann. Das ist dann so das Thema neben Desirability, der Kunde möchte das, zu Viability, man kann damit Geld verdienen, bis dann auch, kann man dann das Problem auch technisch lösen, was denn so Feasibility ist. Es gibt eigentlich so immer zwei Mindsets, die man hat. Das erste Mindset ist, man ist halt super offen, super, super breit. Das heißt, man sammelt so viele Ideen von überall wie möglich ein. Hat dann dort ganz verschiedene Techniken, die man quasi verwendet. Und ab einem bestimmten Punkt geht man dann wieder quasi zusammen. Hat dann ein ganz anderes Mindset, dann trifft man Entscheidungen. Dann sagt man, okay, das ist wichtig, das ist wichtig, darauf fokussiere ich mich, das ignoriere ich. Und man kommt dann irgendwann zu einem Punkt in der Mitte des Double Diamonds, wo man sagt, okay, man hat jetzt halt ein Problem gefunden. was es wert ist zu lösen und geht danach halt erst in den Solution-Space. Und das ist dann eigentlich der Hauptteil. Das heißt, man geht dann wieder sehr breit, schaut sich an, was sind mögliche Solutions. Sehr breit, Brainstorming-Modus, bevor man dann wieder die Themen zusammenführt, Entscheidungen trifft und sich dann am Ende für eine Lösung oder halt für eine, sag ich mal mehrere Versionen einer Lösung entscheidet. Also das ist so der Ansatz vom Double Diamond und ganz, ganz wichtig und auch in der Praxis überraschend schwierig. für viele Leute ist halt wirklich dieses sich zuerst rein aufs Problem zu fokussieren. Ich habe ganz, ganz häufig Probleme in der Entwicklung festgestellt und wenn man dann anfängt mit verschiedenen Leuten zu sprechen, dann merkt man okay, wir haben noch nicht mal das Problem verstanden, was wir eigentlich lösen wollen, sondern jeder versucht die Lösung für verschiedene Sachen zu entwickeln. Keiner hat das Problem verstanden und auch nicht validiert, dass das eigentlich ein Problem ist, was wir lösen wollen. Und dann ist halt spannend, wie man Double Diamond oder aus dem Discovery-Prozess die Methoden dann halt auch nach und nach überführt in eine Entwicklung, die dann natürlich, sage ich mal, weniger kreativ und mehr strukturiert auch abläuft mitunter, wo es dann halt darum geht, Schritt für Schritt mit verschiedenen beliebigen agilen Methoden dann halt die Sachen auch entsprechend umzusetzen.

Joel Kaczmarek: Wäre es bei so einem Double Diamond jetzt so, dass Till die erste Achse macht des Diamanten, nämlich das Problemverständnis und du machst sozusagen dann die Solutions oder ist das immer ein Prozess, den ihr zusammen macht?

Björn Wagner: Da gibt es unterschiedliche Schulen. Je größer die Organisation wird, glaube ich, desto stärker fängst du an, die Bereiche zu trennen. Oft so bei Startups und Thought Leaders wie Marty Kagan etc. sagen, das muss zum Beispiel ein Produktmanager alles zusammen machen. Aber logischerweise ist das Engineering mehr involviert in Solutioning und der Produktbereich und Designbereich mehr involviert in die Problemfindung. Sollte man es strikt trennen, auf gar keinen Fall. Was Björn schon gesagt hat, auf einmal ist das Problem im Solutioning und irgendwie ist der Kontext gar nicht da, wieso dieses Problem jetzt gelöst werden soll.

Till Reiter: Der wichtigste Punkt, hier auch erfolgreich zu sein, ich glaube, da hatten wir schon mal in einer der ersten Folgen drüber gesprochen, ist halt, mit wirklich cross-funktionalen Teams zu arbeiten. Also, dass man nicht sagt, es gibt jetzt hier der Produktmanager oder der Designer, wir designen was, eine Lösung zu einem Problem und dann schmeißen wir das sozusagen über den Zaun und baut das lieber Entwickler, weil dann kommt man genau, also hat man verschiedenste Probleme, zum einen wurde halt Visibility gar nicht von Anfang an mit beachtet, zum anderen, wie man im Englischen so schön sagt, das Not-Invented-Here-Problem, das heißt, wenn man Leuten fertige Lösungen gibt, dann hat man auch häufig sehr, sehr wenig Beine, die dann halt auch entsprechend umzusetzen. Wichtig, schon möglichst früh für diese drei Bereiche auch die entsprechenden Experten, was dann zum Beispiel Produktmanagement, Design, Engineering oder zumindest, wie nennt man das, Techleads, das heißt sehr seniorige Engineering-Leute, die dann von Anfang an schon mal mit auf das Problem schauen und den Discovery-Prozess begleiten.

Joel Kaczmarek: Kannst du auch mal einen kleinen Input geben, wenn jemand jetzt noch nicht so weit ist wie ihr als Organisation und will sich gerade so an dieses Vorgehen rantasten, was wären so typische Quellen, wo man sich belesen kann oder Frameworks?

Björn Wagner: Es gibt unzählig viele Frameworks und ich kann auch nur dazu raten, die als Inspiration zu nutzen. Ich selber auch. im Interviewprozess, wenn man Kandidaten hat, wo man merkt, er rattert Frameworks runter, merkt man relativ schnell, er hat die in der Praxis noch nicht erprobt. Wir reden jetzt ja auch schön von Double Diamond, aber natürlich läuft das jetzt nicht eins zu eins so bei uns ab. Die musst du an deine Gegebenheiten, an deinen Kontext anpassen können. Literatur etc. können wir sicher ein paar gute Sachen noch in die Shownotes packen. Marty Kagan ist was. Okay, es gibt auch viele gute Literatur, was Björn erwähnt hat. Wie heißt da das Standardwerk von John Doerr? Können wir hinzufügen? Aber mir ist immer ganz wichtig, auch mit meinem Team zu sagen, haltet euch nicht an irgendwelchen Frameworks fest. Wenn man sich jetzt genau daran hält, ja, der Designer muss immer bei der Problemfindung anfangen, teilweise weiß man doch schon sehr genau, was das Problem ist und was man lösen will. Und da kann man extrem viel Ressourcen und Geld verbraten. Wenn jeder, der neu in das Team kommt, erstmal sagt, ja okay, ich muss jetzt erstmal mit fünf Kunden sprechen, um dann eineinhalb Jahre später wieder rauszufinden, okay, die Administratoren brauchen wirklich eine Reporting-Funktion. Das ist dann eben doch sehr konkret und man kann sagen, wir wissen, dass wir das bauen müssen. Jetzt geht es wirklich nur noch darum, den Kunden oder unseren Stakeholdern zu sagen, wann es kommt. Und da kommt unsere gute alte Roadmap wieder ins Spiel.

Till Reiter: Ich glaube, es gibt 100 verschiedene Ansätze, wie man Produkt, wie man Entwicklung machen kann. Ich glaube, es ist wichtig, dass man sich so eine eigene Meinung bildet und schaut, was ist halt eine Richtung, die zum Produkt, zur Organisation, zum Business Model, zur Kultur und so weiter gut passt am Ende. Und ich glaube, man sollte sich auch eher im Klaren sein, was sind so Anti-Pattern, so Ansätze, die man nicht verfolgt. Und dass man die dann halt schon kategorisch ausschließt. Ein Teil ist zum Beispiel sowas wie, es gibt so viele Frameworks, die rundum safe, das ist so Scaled Agile Framework, die halt sehr, sehr, sehr komplex sind und quasi jegliche Flexibilität eigentlich aus dem System rausnehmen und wo ich jetzt auch wieder, wie gesagt, mit meiner persönlichen Meinung, es kann sein, dass das für andere Organisationen super funktioniert, sagen würde, das ist eigentlich ein Anti-Pattern und das würde ich halt nicht verfolgen.

Joel Kaczmarek: Und nimm uns nochmal mit in die Hand. Du hast gesagt, du bist eigentlich Roadmap-Gegner, aber wenn man da so ein Double-Diamond-Element reinbringt, dann kann da langsam was Spannendes entstehen. Was sind jetzt so die wichtigen Faktoren, dass du sagen würdest, wenn ich eine Roadmap so und so konfiguriere oder der Weg zur Roadmap so und so abläuft, dann ist es gut?

Till Reiter: Wie gesagt, Roadmap kann ein Artefakt sein, was am Ende, ganz am Ende von dem Prozess halt rauskommt, um irgendwie mitzuteilen, was sind die Pläne, was haben wir vor. Ich glaube, auf dem Weg dahin sollte man eher anfangen, mit Zielen zu arbeiten, sich gerade aus der Company-Strategie, davon abgeleitet in der Produktstrategie, zu überlegen, welche Ziele möchte man denn erreichen. Und da gibt es ja verschiedene Möglichkeiten, Objectives, Key Results ist ein Framework zum Beispiel. Hier ist auch nochmal immer sehr spannend zu sehen in der Diskussion, so Ziele lassen sich mal relativ einfach, Die spannende Diskussion fängt dann an, sobald es um messbare Key Results geht, weil dann merkt man eigentlich mal, wie weit die Interpretationen der verschiedenen Ziele eigentlich auseinander gehen. Und dann, wenn man quasi seine Ziele hat, dann hat man ja viele Ideen von Problemen, von Features, die man vielleicht lösen möchte, herausbringen möchte. Und dann kann man so eine Matrix aufbauen und sagen, okay, das gibt dann auch so Tools wie Product Boards. Wenn man das nicht hat, macht man es halt in Excel oder so. Und sagt dann einfach, okay, das sind jetzt hier meine 20 Features, die ich ungefähr nächstes Jahr bauen könnte. Zu ungefähr können wir gleich nochmal kommen. Und sagt dann einfach am Ende, okay, wie viel passt denn jetzt mein Feature A zum Objective? Und macht dann quasi so eine Value-Driver-priorisierte Ansatz, wo man halt sagt, okay, meine verschiedenen Features haben jetzt eine gewisse Contribution zu verschiedenen Zielen. Und die kann ich halt, dann kann ich mir einfach Scoring überlegen. Und am Ende kann ich halt sagen, okay Ich habe jetzt halt meine fünf Ziele und kann dann halt quasi einfach einmal absteigend sortieren für jedes Feature, was ist denn so die Gesamt-Contribution zum obergeordneten Ziel und sehe dann, welche Sachen ich als erstes bauen sollte und kriege dann so eine priorisierte Liste raus, die mir halt sagt, okay, das sind jetzt die Sachen, die ich umsetzen könnte. braucht man meistens noch so ein bisschen Feintuning zu, aber das ist eigentlich ein Ansatz, der relativ strukturiert ist. Auch hier, es gibt wieder 25 andere Priorisierungsframeworks, aber das wäre so eine Möglichkeit eigentlich, wie man relativ gut von der Produktstrategie abgeleitet, outcome-basiert halt sagt, welche Features sollte man in welche Reihenfolge bauen.

Joel Kaczmarek: Bist du da mit ihm auf der gleichen Seite?

Björn Wagner: Ich denke schon. Wir machen den Prozess ja gerade gemeinsam durch. Wir haben dieses Jahr auch den Prozess ein bisschen gerebrandet. Wir haben es Ready for Roadmap genannt, wo wir bestimmte Kriterien definiert haben, ab wann wir ein Item extern auf eine Roadmap packen können. Das heißt, ein Tag Lead hat das Assessed, das besteht in der Architektur, wir haben die Prototypen etc. und fühlen uns seitdem ein bisschen besser, das auch mit Analysten, Stakeholdern etc. zu kommunizieren, weil wir da eine sehr hohe Konfidenz drauf haben. In dem Zusammenhang stimme ich überein und wie Björn schon sagt, klar, du brauchst ein übergeordnetes Framework for the Roadmap, was dir vorgeht, okay, das ist die Produktstrategie, Vision etc. Und dann gibt es bestimmte Faktoren, was Björn gerade so erwähnt hat, zum Beispiel gibt es diese 70-30-10, 70-20-10, I don't know. Unterschiedliche Formeln, wo man sagt, hey, dieses Jahr investieren wir 20% in Maintenance, 30% in Kunden-Request-Standard-Features, 50% Innovation. Das kann völlig unterschiedlich sein, aber das sind so Sachen, die mapst du eben auf deine Business-Strategie und dann hast du eben auch nur noch diese Töpfe, auf die du deine Capabilities und Engineering-Ressourcen verteilen kannst.

Joel Kaczmarek: Könnt ihr mich eigentlich mal an die Hand nehmen? Wie stimmt ihr das untereinander ab? Also wie sieht die Abstimmung dann zwischen Engineering und Product aus? Wie baut ihr sowas eigentlich? Macht man das in Sprints oder macht man sich einmal im Jahr einen Plan und sitzt dann das Jahr über um? Wie darf ich mir das vorstellen?

Till Reiter: Das passiert eigentlich auf verschiedenen Ebenen. Das heißt, die Teams arbeiten meistens in so zwei Wochen Sprints. Das sind dann entweder mit Kanban oder Scrum-Ansätzen, wo dann halt zwei Wochen quasi geplant werden. Das sind häufig so eine User-Story-Ebene.wie man das so aus dem Lehrbuch kennt. Das heißt, relativ kleine Features,die innerhalb von zwei Wochen halt entwickelt werden,fertiggestellt werden und am Ende der zwei Wochengibt es dann eine Demo. Meistens sind die Features noch nicht groß genug,um sie dann wirklich komplett mit einem großen Marketing-Releasean den Kunden zu releasen, sondern die leben dann meistensnoch hinter Feature-Flags. Das heißt, die sind nur für bestimmte Testbereiche zugänglich. Die sind noch nicht allen Kunden zugänglich,aber die sind schon fertig. Es gibt noch ganz viele Engineering-Ansätze,Deployed of Production und so weiter. Das würde jetzt zu weit führen Die zweite Ebene ist dann eigentlich die Quartalsebene, das heißt, man gruppiert dann sechs Sprints zusammen zu einem Quartal und plant dann hier in der Regel mit Inkrement, hinter dem man dann auch so einen größeren Marketing-Release machen kann, mit dem man dann wirklich sagen kann, okay, wir haben jetzt hier komplexere Features, größere Features und können damit den Release machen. Und dann oben drüber natürlich gibt es dann den Annual Plan, also dass man einmal quasi das Jahr wirklich plant, was möchte man in einem Jahr machen. Hier sind dann halt größere Themen, gerade wenn man sich dazu entscheidet, zum Beispiel, man möchte in einen Bereich investieren, neu investieren und man möchte jetzt hier bestimmte Teams aufbauen. Wenn ich mich halt im Januar entscheide, Teams aufzubauen, dann brauche ich ja in der Regel neun Monate, bis die da sind und geheiert sind. Das heißt, es ist dann schon auch ein größerer Prozess, alleine die Kapazität, die Teams aufzubauen, bevor man überhaupt anfangen kann, die Funktionalität richtig zu entwickeln. und das plant man dann eher so auf einem Jahreshorizont. Also kurz gesagt, die Teams arbeiten häufig auf so einem Zwei-Wochen-Sprint-Horizont. Dann auf dem Quartal gibt es dann einen spannenden Release für die Kunden. Und auf der strategischen Ebene plant man halt zumindest mal ein Jahr im Detail und in der Regel dann nochmal drei bis fünf Jahre so sehr vage in die Zukunft.

Björn Wagner: Das ist natürlich jetzt B2B komplexerer Enterprise-Kontext. Also wie gesagt, das muss sich je nach Szenario anpassen und muss jetzt im Startup sicherlich nicht mit einer jährlichen Planung anfangen. Das muss man vielleicht noch erwähnen.

Joel Kaczmarek: Lass uns doch mal über Priorisierung sprechen. Also was sich da eigentlich auch so für Herausforderungen einstellen, weil damit steht und fällt das ja. Und das ist ja ganz oft irgendwie wahrscheinlich auch relativ undankbar, weil alles ist irgendwie Cash-sensitiv, alles ist irgendwie für die Kundenfront relevant. Was sind da so die wichtigen Faktoren, wenn ich Priorisierung setzen will?

Björn Wagner: Klar, es muss machbar sein, es muss von den Kunden gewollt sein, es muss aber auch wirtschaftlich sinnvoll sein. Und dann ohne Produktstrategie und Vision drüber, glaube ich, lässt sich Priorisierung nicht wirklich machen. Und dann gibt es natürlich, jeder Produktmanager hat eine unendlich lange Liste an Dingen, die er gerne will. Und dann kommen wir eben in den Bereich, und da kann Björn ja vielleicht ein bisschen teilen, wie man dann in die Arbeit geht, zu sagen, okay, das hätten wir gerne, das passt hier auf dieses Objective. Was können wir denn tatsächlich davon eigentlich umsetzen nächstes Jahr?

Till Reiter: Genau, also ich glaube, es gibt sehr viele verschiedene Priorisierungsansätze, die man grundsätzlich machen kann. Der entscheidende Punkt ist immer, ich glaube, es ist sehr wichtig, ab einem bestimmten, sage ich mal, Reifegrad einer Idee, eine relativ gute Abschätzung des Aufwands, der Kosten dahinter zu haben. Und das ist halt sehr, sehr schwierig, weil natürlich möchte man auch nicht zu viel Aufwand in die Planung stecken und jetzt drei Monate lang analysieren, wie viel könnte das denn kosten, weil vielleicht kann ich es in einem Monat schon bauen direkt, das macht dann auch keinen Sinn. Das heißt, die Herausforderung ist, wie kommt man relativ schnell zu gut genugen Abschätzungen von den Aufwänden, weil ja, man kann natürlich sagen, okay, jetzt eine bestimmte Priorität von der Kundenseite, aber natürlich, wenn das Thema wahnsinnig komplex ist gegenüber zu allem, was vielleicht nicht ganz so gewünscht ist von den Kunden, kann es immer mehr Sinn machen, das Kunden-Prio-2-Thema zuerst zu bauen. Die Frage ist halt, wie kommt man dahin, möglichst einfach, aber vielleicht auch ein bisschen datengetrieben sogar, zu Abschätzung zu kommen. Und hier gibt es halt auch verschiedenste Ansätze. Wenn man jetzt sich so Can-Bin-Modelle oder auch Scrum-Modelle anschaut, wird ja quasi auf dieser Zwei-Wochen-Ebene User-Stories fertiggestellt. Und dann gibt es eine entscheidende Metrik, das ist halt im Through-Port nennt man das. Wie viel User-Story schafft ein Team innerhalb von zwei Wochen? User Story ist ein, sagen wir mal, klein, einfaches Feature. Ich baue halt einen neuen Button irgendwo ein oder eine neue Ansicht, eine neue Liste, um meine Kundeninformations anzuzeigen in einem CRM oder whatever. Also ein relativ einfacheres Feature, was innerhalb von, ich sage mal, normalerweise wenigen Tagen entwickelt werden kann. Das ist eine relativ gute Metrik und relativ meistens, wenn man gut ist, in seiner Agile Maturity eine relativ stabile Metrik auch, dass man halt dann extra polieren kann. Man schaut sich dann halt an, okay, ich kann halt von einem, ja, es gibt größere und kleinere Features, aber vereinfacht gesehen gleicht sich das aus. über einen Zeitraum. Das kann man auch nochmal im Detail analysieren und man schaut sich dann quasi an. Ich überlege mir ein neues, größeres Feature und schätze es dann jetzt halt nicht ab in Personentagen oder Zeit, sondern ich sage halt, okay, dieses Feature besteht halt aus, wir wissen noch nicht genau, sagen wir mal 10 bis 15 User Stories. Jetzt kann ich alle meine größeren Features, die ich vielleicht in einem Quartal bauen möchte, so grob abschätzen. Ich habe dann natürlich auch häufig schon Daten aus der Vergangenheit, wo ich mal reinschauen kann, hm, guck mal, vor drei Monaten haben wir hier ein Feature gebaut, das hatte dann zwischen, weiß ich nicht, drei und fünf User Stories gehabt. Basierend auf diesen Daten kann man in verschiedenen Techniken, zum Beispiel Monte-Carlo-Simulationen, so Forecasts machen und halt schauen, okay, hier sind meine zehn Features mit einer klaren Priorität und dann sagt einem halt die Simulation mit einer bestimmten Wahrscheinlichkeit, wie realistisch ist es, basierend auf der Kapazität, dem Throughput des Teams, dass ich das erreiche. Damit kann ich halt relativ gut einmal abschätzen und Entscheidungen treffen, was schaffe ich realistisch, das heißt, was kann ich in so ein Quartal reinpacken und was nicht. und ich kann halt auch abschätzen, auch im Quartal nochmal checken, habe ich ein Risiko, dass ich das, was ich dem Kunden versprochen habe, dann wirklich erreichen kann. Das ist jetzt eine Methode, die ist mittelmäßig aufwendig, würde ich sagen, aber gibt relativ gute Konfidenz, um irgendwie Entscheidungen treffen zu können, was ich dann jetzt realistisch in einem bestimmten Zeitraum mache. Und das kann man dann auch noch irgendwie extrapolieren, auf eine jährliche Ebene packen, wenn man das möchte und kann halt so quasi basierend mit den Daten, die man halt vom Team sammelt, von der Arbeitsweise des Teams, also Daten aus der Vergangenheit, relativ gut in die Zukunft projizieren, was man denn realistisch erreichen könnte.

Joel Kaczmarek: Und diese Monte-Carlo-Simulation, da geht es wahrscheinlich eher um Ressourcenmanagement als um Priorisierung, oder? Habe ich das richtig verstanden?

Till Reiter: Genau, aber man hatte immer das Problem, Priorisierung geht nur mit Ressourcen. Das heißt, ich habe jetzt eine Liste an zehn Items und die Frage ist jetzt, wie viele der zehn Items kann ich denn überhaupt machen? Ja. Also wenn ich einen Stack-Rank habe mit zehn Items, dann muss ich halt wissen, wo wäre jetzt die Line, was ich zum Beispiel im Sprint, im Quartal oder im Jahr halt nicht mehr erreichen kann. Und dann überlegt man sich halt genau, okay, kann ich denn damit leben? Oder muss man nochmal hingehen und vielleicht sagen, okay, so wie das Feature bisher geplant war, ist es zu groß, kann ich das nochmal teilen, runterschneiden, kann ich es komplett skippen an der Stelle? Ist aber sehr wichtig, dass man nicht nur Priorisierung im luftleeren Raum macht und eine Wunschliste hat und sagt, ja, das bauen wir jetzt, sondern auch ein ziemlich gutes Gefühl hat, was können wir denn mit der Organisation, mit den Ressourcen, die wir haben, realistisch leisten? Und das halt mit möglichst wenig Aufwand. Und wenn man da so ein bisschen Tooling, Automatisierung drum baut, hat man ein relativ gutes Framework, mit dem man mit moderatem Aufwand gute Entscheidungen treffen kann und ein gutes Gefühl dafür bekommt, was man denn realistisch umsetzen kann.

Joel Kaczmarek: Wie ist es denn eigentlich mit diesem ganzen Thema, wenn wir noch ganz kurz die Priorisierung abhaken? Man hat ja gerne mal so eine gewisse Starrheit, die man vielleicht haben möchte auch, also so eine gewisse Planbarkeit, auf der anderen Seite aber auch so Markttrends. Also auf einmal ist irgendwie ein neues Interface vielleicht total in oder es gibt einfach irgendeinen Trend. Wie mitigiere ich sowas?

Björn Wagner: Bestes aktuelles Beispiel ist AI. Ich glaube, da hat jeder, der nicht Frontrunner war, Ressourcen umschieben müssen und hoch priorisieren müssen. Man hat findige Mitarbeiter, hatten wir letztes Jahr in unserer Organisation, die haben sozusagen Integrationsmöglichkeit entdeckt zwischen zwei Produkten von uns. Wir haben gesagt, hey, das macht total Sinn, lass hier alle Ressourcen drauf lenken. Klar hat das, deswegen habe ich vorhin gesagt, eine Roadmap muss auch agil bleiben. Das hatte natürlich dann einen Impact, ein paar Items haben sich verschoben, aber aus Business-Perspektive hat das Sinn gemacht, ne? Und deswegen, es gibt die jährliche Planung, aber Pläne sind dann doch wieder dafür da, gerissen zu werden, wenn es Sinn macht.

Joel Kaczmarek: Ja, cool. Ich meine, dann, wenn wir über Priorisierung sprechen, finde ich, ist ja das, was naheliegt, auch mal Ziele nochmal zu betrachten. Vielleicht habt ihr da auch nochmal einen ganz spannenden Input, weil es gibt ja oft so kurzfristige Ziele und langfristige. Gerade wenn man Customer-Facing ist. Wie mische ich sowas richtig ab?

Björn Wagner: Ohne Produktstrategie, die wirklich sich mal die Mühe macht, drei bis fünf Jahre in die Zukunft zu gucken, ist es so oder so schwierig, langfristige Ziele zu haben. Wir auch in unserer Organisation ziehen uns dann für ein paar Monate zurück, schauen alle möglichen Input-Sourcen an, Daten getrieben, Interview getrieben etc. Markt getrieben, wohin wollen wir, wo wollen wir stehen in drei Jahren? Und dann gehst du natürlich dran, irgendwie konkreter darüber nachzudenken, okay, was sind die Next Steps, was wollen wir nächstes Jahr machen, um da hinzukommen? Aber das sind sozusagen die Items, wo du sagst, das muss ich machen, um meine Vision zu erreichen. Aber wenn du ein Existieren als Business hast, wie wir mit ein paar tausend Kunden, dann hast du natürlich auch ein paar Kundenanforderungen, die jetzt nicht unbedingt mit deiner Drei-Jahres-Vision übereinstimmen. Aber vielleicht klebt ein Multi-Million-Dollar-Deal dran etc. oder es gibt bestimmte Und da muss man eben auch sagen, deswegen habe ich vorhin diese 70-20-10-Formel, whatever, da gibt es unterschiedliche Lösungen, muss man sagen, okay, wir müssen uns hier abstimmen, wie viel investieren wir in die langfristige Business-Entwicklung und wie viel investieren wir, um nächstes Jahr ein gutes Jahr zu machen, ohne existierende Bestandskunden zu vergraulen oder zu viel Tech-Debt anzuhäufen.

Joel Kaczmarek: TechDev wäre das nächste, was ich euch mal fragen wollte. Also die technischen Schulden, die ich ja natürlich ganz schnell mal aufbaue, indem ich mich auf Feature-Ebene so überfokussiere. Wie kriegt man das denn, gerade wenn wir über das Thema Product Roadmap jetzt wieder zurückgucken und Ressourcenmanagement, wie kriege ich sowas denn abgefangen, dass ich nicht dauernd in so ein Thema reinlaufe?

Till Reiter: Ich habe eigentlich zwei Ansätze. Zum Ersten, man kommt in sehr, sehr schwierige Diskussionen rein, sobald man sagt, man möchte jetzt dauerhaft TechDev versus was anderes priorisieren, versus Product Features. Gute Organisationen bekommen es halt hin, kontinuierlich TechDev abzubauen. Das heißt, wenn ich halt ein neues, größeres Feature baue und anschaue, die Architektur, das aktuelle Setup passt nicht mehr, dass ich dann hingehe und quasi einfach im Kontext dieses Features, um das Feature entweder überhaupt oder schneller oder effizienter bauen zu können, auch TechDev mit abbaue. Natürlich gibt es immer wieder Themen, die trotzdem so groß sind, dass man sie zum Beispiel in Re-Platforming oder so, dass man das als eigenständiges Thema betrachten muss. und dann ist hier eigentlich ganz wichtig, dass man schaut, nicht die Sachen separat zu betrachten, dass ich nicht eine Liste habe, das ist meine Produktwunschliste und das ist die Tech-Wunschliste, sondern wirklich eine Liste habe, die dann verschieden klassifiziert ist. ist und wo ich dann genau wieder hingehe und verstehe, okay, das ist meine Gesamtkapazität. und dann muss ich halt Tetris spielen, sagen wir immer, so ein bisschen schauen, was kann ich jetzt, wie machen, kann ich das reinmachen, dann fällt das raus, um dann halt irgendwie den bestmöglichen Kompromiss zwischen allen Optionen, die man auf dem Tisch hat, zu finden.

Joel Kaczmarek: Und könnt ihr mir nochmal erklären, jetzt haben wir ja ganz viel schon gesagt, also wir hatten Priorisierung und Ziele, wir haben über Ressource-Management gesprochen und ich finde der eine Aspekt, der ja dabei wirklich immer so sehr essentiell ist, ist das Thema Stakeholder-Management. Also, dass man die richtigen Leute an der richtigen Stelle einbindet, dass die alle irgendwie gut orchestriert sind. Wie macht man sowas in so einem Roadmap-Prozess?

Björn Wagner: Das auch wieder ganz stark darauf an, wie komplex ist deine Organisation jetzt? Man muss halt schauen, dass man bei seiner Planung berücksichtigt, unterschiedliche Stimmen repräsentativ zu haben. Weil ansonsten hat man der, der am lautesten schreit, treibt die Roadmap am stärksten. Kann oft der Kunde sein, der einfach sein tägliches Support Ticket anlegt und immer wieder den Call mit dem Engineering Lead oder Product Lead, whatever, haben will. Das kann aber auch in der Organisation sein. von bestimmten, I don't know, Success-Managern etc., die große Kunden vertreten und hier sehr omnipräsent sind, in ihre Forderungen zu positionieren. Aber dann ist es natürlich jetzt wieder die Arbeit auch von dem Produktmanager, das zu abstrahieren und im Kontext mit den anderen Kundenrequests zu bringen. Und dann kann man auch formale Settings einführen, wie zum Beispiel haben wir, was es nennt sich die GTM Interlogs, also unsere Go-To-Market Interlogs, wo wir bestimmten Expertengruppen haben, die sich in regelmäßigen Abständen zusammensetzen und gemeinsam evaluieren, okay, was hat sich jetzt verändert, was sind die aktuellen Requests etc. Und ansonsten kommst du ganz schnell auch zum Beispiel in den Local Bias rein. Amerikanische Kunden haben ganz oft ganz andere Interessen wie europäische. Du bist aber natürlich, hast das Headquarter jetzt vielleicht in Europa und hast hier zum Beispiel einen Bias eher, der an Kundenbedürfnisse zu sehen. Also das ist ein sehr gutes Vehikel für Stakeholder-Einbindung. Und da kann man natürlich auch teilen, okay, das haben wir jetzt auch gebaut, das haben wir geliefert, das verschiebt sich auf der Roadmap etc. Dann gibt es Tools wie zum Beispiel Product Board, gibt es auch noch hundert andere, die man für Product Feedback nutzen kann, aber auch selber die Kunden Feedback hinterlassen und Input geben und man kann das dann in diesen Tools auch auf bestimmte Capabilities etc. clustern. Dann hat Man hat ein NPS bei uns, wir fragen auch in den Tools unseren Net Proponder Score ab, kann der Kunde sagen, wie wahrscheinlich ist es, dass ich das Produkt weiterempfehlen würde und einen Kommentar auch dazu lassen. Wichtiges Feedback, aber auch hier muss man wieder sagen, es ist eine bestimmte Nutzergruppe, die Feedback überhaupt im Tool hinterlässt. Das sind auch schon eher die Power-User. Es gibt auch ganz viele, die interessiert es nicht. Und auch da muss man wieder aufpassen. Amerikaner grundsätzlich sagen gerne, hey, your product is great, aber mögen es nicht. Die Deutschen tendenziell immer zwei Punkte drunter. Aber das ist eben auch, dass man da eine quantitative Grundlage hat und eine qualitative ist, glaube ich, ganz wichtig für das Stakeholder-Feedback. Und dann natürlich auch Input holen. aber dann auch wieder Output geben, wenn man einen Schritt gemacht hat. Also wir haben zum Beispiel Quarterly Roadmap Sessions mit unseren Kunden, mit unserer Go-to-Market-Organisation, sodass die einen Überblick behalten, okay, was ist hier jetzt passiert und wie hat sich unser Feedback in die Produktentwicklung ausgewirkt.

Joel Kaczmarek: Kommen wir mal zum letzten Faktor. Wie messe ich denn eigentlich den Erfolg von so einer Roadmap? Also wie realistisch sie ist, wie erfolgsversprechend im Sinne von dem, was wir gerade gesagt hatten, also Technical Depth verhindern, Featuren in den Start bringen etc. Wie läuft sowas ab?

Björn Wagner: Ja, da würde ich oben anfangen. Was hast du dir als Business für Ziele gesetzt? Also es gibt Frameworks wie Heart von Google. Was für ein MPS wollen wir nächstes Jahr haben? Was soll das Engagement sein? Das müsste man möglicherweise über Monthly Active Users oder Daily Active Users, was soll die Adoption sein, der Revenue. Also das sind so klassische Business-weite Ziele, die man sich setzt, sowohl im B2B- als auch im B2C-Kontext. Und da kann man sich natürlich in der Yellow Refraction hinsetzen und sagen, okay, was haben wir davon jetzt eigentlich erreicht? Wenn man etwas nicht erreicht hat oder auch overachieved hat, guckt man, okay, was hat dazu geführt? Haben wir bestimmte Capabilities gebaut, haben wir sie nicht gebaut, etc.? ? Und dann Level drunter schaut man natürlich, da kann Björn vielleicht was teilen, okay, wie effektiv waren wir wirklich? Wir haben uns 30 Items vorgenommen, haben wir die alle erreicht, haben wir die overachieved? Also das ist dann so klassisches Item-Counting, um die eigene Produktivität zu messen.

Till Reiter: Ich hatte am Anfang gesagt, Roadmaps hauptsächlich, um dem Kunden vertrauensvoll zu vermitteln, was man in der Zukunft liefert. Natürlich sollte man auf eine Output-Metrik schauen. Konnte man denn die Versprechen liefern oder hat man eine Roadmap gebaut, in der man alles nur drei Monate, vier Monate, sechs Monate nach hinten verschoben hat? am Ende des Tages? Was nochmal wichtig ist, ich glaube, es ist wichtiger, wenn es um wirklichen Erfolg geht, Delivery der Items ist das eine, aber wirklich zu schauen, jedes Item, mit dem möchte man ja was erreichen und dann auch zu messen, hat man das erreicht. Und hier, gerade im B2B ist es halt so, dass es häufig sehr, sehr eine lagging Metrik ist. Das heißt, wenn ich jetzt dieses Jahr was entwickle und release, dann hat das in der Regel einen relativ geringen Einfluss auf so Zahlen wie Revenue, Kundenadoption. Das heißt dann, in der Regel bewegen sich die Metriken viel, viel später. Das heißt, man schaut dann, was sind so frühe Leading Metrics, um halt irgendwie möglichst früh zu schauen, ob halt gewisse Features, die man jetzt im Rahmen der Roadmap veröffentlicht hat, ob die noch den gewünschten Erfolg haben.

Joel Kaczmarek: Also ich gehe hier heute so ein bisschen raus und habe den Eindruck, man kriegt euch aber beide, glaube ich, doch ganz gut unter den Hut, auch wenn der eine Roadmaps mag, der andere nicht.

Till Reiter: Haben wir zu viel versprochen.

Björn Wagner: Wir haben uns zu viel in der Vergangenheit gestritten, das ist alles geklärt.

Joel Kaczmarek: Ja, okay, also jetzt mal Spaß beiseite. Das ist sozusagen auch wirklich so ein Findungsprozess, wenn genau diese beiden Positionen, die ihr irgendwie eingenommen habt, dass ihr sagt, man muss das auch so ein Stück weit für sich zurecht ruckeln als Unternehmen, wie man so eine Roadmap mit all den Elementen, die wir eben genannt haben, implementiert kriegt.

Björn Wagner: Es ist auch teilweise ein Veränderungsprozess. Zum Beispiel bei uns, als wir noch kleiner waren, da hatten wir auch noch nicht wirklich so viele Stakeholder, die da nach einer klaren Richtung und Planung verlangt haben, auch kundenseitig nicht. Aber die Erwartungen wachsen da, je komplexer die Organisation wird und auch je größer die Kunden oder die Accounts werden.

Joel Kaczmarek: Na gut, ihr beiden. Also heute habe ich mal richtig fleißig mitgeschrieben. Heute habe ich ja wirklich viel gelernt. Vielen, vielen Dank. Jetzt merken wir, geht es ans Eingemachte. Wir haben so ein bisschen die Pipi-Folge am Anfang, wo wir den Leuten mal die Basics erklärt haben und jetzt langsam wird es komplexer. Habt ihr schon eine Sneak-Preview, worauf wir uns das nächste Mal freuen dürfen?

Till Reiter: Packen wir als Überraschung unter den Weihnachtsbaum, würde ich sagen.

Joel Kaczmarek: Ja, cool, ihr beiden. Dann ganz, ganz herzlichen Dank. Hat mir echt Spaß gemacht heute und ich bin schon gespannt, was mich das nächste Mal dann erwartet. Vielen, vielen Dank.

Björn Wagner: Bis dann. Ciao.

Outro: Danke fürs Zuhören beim Digital Kompakt Podcast. Du merkst, hier ziehst du massig Wissen für dich und dein Unternehmen heraus. Wenn du mit uns noch erfolgreicher werden möchtest, abonniere uns auf den gängigen Podcast Plattformen. Und hey, je größer wir werden, desto mehr Menschen können wir helfen. Also erzähl doch auch deinen Kolleginnen und Kollegen von uns. Bis zum nächsten Mal.