von André Morys

Agile Tretmühle: 5 Lösungsfelder für mehr Effektivität in agilen Produktteams (Part II)

“Stell’ dir vor, du sitzt in einer agilen Falle und merkst es nicht. ”, ungefähr so begannen meine Worte im ersten Beitrag unserer Serie “Agile Produktentwicklung”.

Wir schauten uns an, warum agile Teams in einem Hamsterrad stecken und wie du auf strategischer Ebene interne Hürden aufdecken und angehen kannst.

In diesem Beitrag wollen wir nun die richtigen Hebel für mehr Effektivität in agilen Produktteams finden.

Damit du ein möglichst breites Spektrum an Ideen für deinen Alltag erhältst, findest du auch in diesem Beitrag zusätzliche Inhalte aus meinen vergangenen Gesprächen mit Product Management Coaches, dem CDO der Klingel Gruppe sowie dem Vice President Product von auxmoney.

Vielleicht hast du weitere Beobachtungen aus der Praxis – dann bereichere diesen Artikel gerne mit einem Kommentar.

📌 Vielleicht hast du auch keine Zeit, das alles zu lesen – dann gibt es für dich am 11.08.2020 um 11:00 Uhr ein Webinar – meld dich hier an und stell mir live deine Fragen.

Hinweis: Dies ist der zweite Beitrag zur Serie “agile Produktentwicklung”.
Beitrag 1: Die strategische Ebene – finde heraus, warum agile Teams in einer Tretmühle stecken bzw. wie du interne Hürden besser erkennst.
Beitrag 2: Zeigt dir Lösungswege, wie du für mehr Effektivität in agilen Produktteams sorgst.
Beitrag 3: Scrum-Reality-Check: Welche Rolle ein Chief Product Officer im Unternehmen einnehmen sollte und wie du ein Gespür für Kundenbedürfnisse auf C-Level-Ebene etablierst.

Die fünf Kernproblemfelder (Hypothesen) denen agile Produktteams ausgesetzt sind

“Die agilen Methoden sind nicht verkehrt, sondern die Art, wie sie im Unternehmen eingesetzt werden. Das Problem beginnt mit den falschen Zielen.”

Tim Herbig Managemen CoachTim Herbig – Product Management Coach, Autor und Speaker

 

1. Das Management- und Ziel-Dilemma

Du bist Produktmanager, Product Owner, Scrum Master oder ein anderes Mitglied eines agilen Produktteams?

Ich versuche jetzt bewusst ein wenig zu polarisieren: Wenn dich der nachfolgende Text ärgert, habe ich eventuell einen Nerv getroffen. Ich sage es aber mal direkt: Niemand im Management interessiert sich für die Micro-Conversion oder die Klickrate im Suchschlitz.

Als PM der Onsite-Search ist es wahrscheinlich dein ganzes Universum – aber so lange du den Wertbeitrag (“Business Value”) deines Universums nicht messen und berichten kannst, wird sich kein Schwein dafür interessieren.

Noch schlimmer: Das Management wird dir erst gar nicht vertrauen, wirklich echten Wertbeitrag zu liefern. Du bist aus Management-Sicht nur ein Rädchen in der größeren Feature-Fabrik, die als Ganzes die Wertschöpfung liefert. Wenn etwas kaputt ist oder nicht pünktlich fertig wird, spürst du den Druck – aber ansonsten hast du wenig “Management-Attention”.

Und da beginnt unser Henne-Ei-Problem. So lange das Management kein Vertrauen in dich und deine Fähigkeit den Wertbeitrag zu beeinflussen hat, wird es weiterhin ganz altmodisch über Deadlines und Outputs managen. (“Wir brauchen dieses Feature bis Ende Q3!!!1elf!”)

Jetzt kannst du entweder warten, bis sich das Dinosaurier-Problem im Management ausgemendelt hat, von Deinem Taschengeld selbst ein Management-Seminar zu “Leadership 8.0” finanzieren” oder dein Leid in passiver Opfermentalität ertragen.

Oder du denkst über folgenden Gedanken nach:

Hypothese: Wenn du deine eigene Art zu arbeiten, zu messen und deinen Wertbeitrag zu reporten, änderst, veränderst du auch die Einstellung des Management zur Führung und zu deinem Reifegrad. Die Organisation ist ein System mit Wechselwirkung, du bist nicht ausgeliefert und diese “Management ist Schuld-Denkweise” ist wenig hilfreich.

Du bist selbst VP Product, CPO, Head of Product oder in ähnlicher Führungsposition?

Für dich besteht die Leadership-Aufgabe darin, deine Teams zur echten Messung und Beeinflussung ihres Wertbeitrag zu ermächtigen, denn das macht Effektivität aus. Hör auf, im OKR Prozess die Unternehmensziele immer weiter auf kleinere Ziele herunterzubrechen – jeder Wertbeitrag misst sich ausschließlich an einem zuvor definierten KPI. Gib’ deinen Teams Zeit für eine systematische Product Discovery und lass’ sie selbst entscheiden, wo sie den größten Wertbeitrag sehen. Auch wenn es schmerzt: Lass’ sie Fehler machen. Aber achte darauf, dass die Ziele der Teams auch wirklich einen echten Wertbeitrag darstellen.

 

“Führung agiler Teams ist kontra-intuitiv. Als Führungskraft tut es manchmal weh, so stark loszulassen, aber das musst du aushalten können.”

Chief digital officer Klingel GruppeSven-Christian Andrä – Chief Digital Officer (CDO) at Klingel Gruppe

 

2. Du bist, was du misst

Steigen wir tiefer in das Problem der falschen Ziele ein. Denn dieses Problem hat zwei Ursachen: Zum einen machen es sich viele Produktmanager einfach zu leicht. Es werden schlichtweg die falschen Kennzahlen gemessen, weil es einfacher ist. Zusätzlich werden dann in jedem Team andere Kennzahlen gemessen. Nur sehr selten helfen diese Kennzahlen dann dabei, den echten Wertbeitrag auf die unternehmerischen Ziele (KPI) vorherzusehen.

Bleiben wir beim Beispiel mit dem Suchschlitz: Die Suche ist zweifelsfrei ein wichtiger Teil der Customer Journey. Ohne Suche ist es schwierig, das richtige Produkt überhaupt zu finden. Wenn wir es also schaffen, dass mehr Nutzer die Suche benutzen, dann ist das gut, denn je stärker wir vorne im Funnel etwas optimieren, desto mehr kommt hinten raus.

Klingt logisch?

Stimmt aber nicht.

So lange du den Wertbeitrag der Suche innerhalb der gesamten Customer Journey nicht gemessen hast, kann es sogar sein, dass der Wertbeitrag negativ ist, weil die Suchergebnisse zum Beispiel nicht gut sind. Vielleicht werden Besucher durch zu viele ähnliche Ergebnisse verunsichert, vielleicht schafft es die Suche gar nicht, die Besucher zum Kauf zu motivieren.

Doch gehen wir davon aus, dass der Wertbeitrag tatsächlich positiv ist: Ein neues Feature oder eine Veränderung könnte dafür sorgen, dass nun andere Besuchertypen als vorher weiter gehen, diese Veränderung sorgt dann weiter hinten im Funnel für stärkere Abbrüche und der, an einer Stelle, positive Effekt, kehrt sich an anderer Stelle ins Negative um.

Also: Zum einen schwingt bei einer flexiblen Auswahl der Metrik immer der Vorwurf des Bestätigungsfehlers mit (“Confirmation Bias” – Menschen suchen sich bewusst Daten aus, die ihre ohnehin bestehende Ansicht verstärken). Zum anderen: mach’ es dir einfach nicht zu leicht. Wenn du echten Wertbeitrag liefern willst, musst du diesen auch messen – und keine proxy-vanity-clickibunti-metrik, die dir dein leben leichter macht.

 

Beispiel für eine Goalmap

Abb. 4: Eine (abstrahiert) typische Goal-Map, wie ich sie in Firmen-Workshops mit Teams erarbeite, zeigt die Lücke zwischen Team-Zielen und Management-Zielen.

Du bist CPO oder sonstige Führungskraft?

Es gilt immer noch das Ziel-Problem der ersten Hypothese. Zusätzlich: Warum sind die Analysten nicht Teil der Produktteams? Warum sind grundsätzlich so wenige Product- und Business-Analysten in deinem Unternehmen? Das würde die Teams befähigen, die eigenen Ziele und Wertbeiträge besser zu messen. Warum hat das Management nicht für mehr Führung durch klare Zielhierarchien und Treiberbäume gesorgt?

Es sollte gar nicht die Aufgabe des jeweiligen Produktmanagers sein, sich seine Zielmetriken pro Experiment selbst auszusuchen. Wer kann das durch klare Guidelines und Vorgaben ändern, wenn nicht du?

Übrigens: Eine Anleitung zur Verbindung der strategischen Unternehmensziele mit passenden Kennzahlen zur Entwicklung eines einheitlichen Verständnis von Experimentieren im Unternehmen findest Du in unserem Digital Experimentation Framework.

Anleitung AB Testing und Personalisierung

Es sollte außerdem obligatorisch sein, den Wertbeitrag von Releases über Experimente zu messen. Profitabel wachsende Unternehmen experimentieren viel. Das läuft jedoch auch dort nicht parallel oder optional zu den Releases der produktorientierten Teams aber, sondern die Vorgehensweise sieht so aus, dass jedes einzelne Feature, jedes Release, per Experiment auf seinen Wertbeitrag analysiert wird.

Als Führungskraft kannst Du dafür sorgen, dass das Experimentieren als “Betriebssystem” verstanden wird und nicht als optionales nice-to-have-MaFo-tool, das man gelegentlich nutzt, falls noch Zeit übrig ist.

Das gleiche gilt übrigens für Marktforschung und User Research.

Auch sie sind entkoppelt und ebenso wie die Analysten nur selten Teil der Produktteams – wie soll nun eine gute Product Discovery funktionieren, wenn an dieser wichtigen Stelle doch wieder Abhängigkeiten von anderen Teams geschaffen werden?

3. Fehlerkultur fehlt

“Man benötigt das richtige Mindset in der ganzen Organisation. Das wichtigste bei einer agilen Transformation ist es, erstmal das agile Mindset zu transportieren, vor allem auf dem Management-Level, und danach schaut man, wie man Scrum wirklich umgesetzt bekommt.”

Rainer Gibbert – Leitung Privatkunden starfinanz, Gründer und Autor produktbezogen

 

 

 

Jeff Sutherland hat den idealen Zustand eines autonom arbeitenden agilen Teams perfekt in seinem Buch “Scrum – The Art of Doing Twice the Work in Half the Time” aus dem Jahr 2014 beschrieben. Nach seiner Schilderung befinden sich Gewinnerteams – und hier bedient er sich bewusst an einer Analogie zum Team-Sport – in einem Zustand der Transzendenz. Der Begriff Transzendenz meint: Die Teammitglieder verstehen sich auf impliziter Ebene, spielen sich Bälle zu – jeder weiß instinktiv was der andere tut. Neben der Autonomie und der crossfunktionalen Besetzung der Teams ist dies eine der Kerneigenschaften erfolgreicher agiler Teams.

In vielerlei Hinsicht ergibt das Sinn. Es gibt jedoch auch eine Schattenseite dieser Kultur, die ich persönlich immer wieder beobachte: Die oberflächliche Konsenskultur, bei der nur die Dinge angepackt werden, mit denen sich das gesamte Team wohlfühlt. In Retrospektiven feiert sich das Team selbst, niemand traut sich, Ideen zu “challengen” und kontrastreicher oder mutiger zu machen, als es der Teamkonsens als Ganzes erlaubt. Dabei erwähnt Jeff Sutherland im gleichen Buch weiter hinten, wie gefährlich es ist, wenn Teams die Bodenhaftung verlieren. Er erklärt auch, wie wichtig die Rolle von Challengern ist – leider wird dafür nur ein Bruchteil der Seitenzahl verwendet, wie zuvor die Schilderung des transzendenten Zustands von Kommunikation und Kultur.

Klar, alle wollen Gewinner sein. Anders kann ich mir nicht erklären, warum so viele Produktteams in eine agile “Tschakka-Kultur” verfallen und sich oberflächlich selbst feiern, statt auch unbequeme Ideen zu verfolgen. Oft genug wird die oberflächlich positive Teamkultur stärker gewichtet als die mögliche Wertschöpfung als Outcome unbequemer Vorhaben.

Als Optimierer habe ich gelernt, wie wichtig es ist, eine erste Idee von anderen Menschen früh überprüfen und herausfordern zu lassen. Es ist unbequem, manchmal sogar ein persönlicher Schmerz. Jeder fühlt sich zunächst einmal den eigenen Ideen gegenüber verpflichtet, ein Hinterfragen dieser Idee durch andere wird schnell als persönliche Kritik empfunden. Ein systematisches Hinterfragen kann jedoch zur deutlichen Verbesserung führen – entweder führt es dazu, dass eine Idee “zu Grabe getragen” werden muss und niemand damit Zeit weiter verschwendet – oder aber die Idee wird weiter entwickelt, veredelt und verbessert.

Komfortzone und UnternehmensoptimierungScrum gibt in Wahrheit nicht vor, dass dein Team in eine oberflächliche Tschakka-Kultur verfallen soll. Der von mir geschilderte Zustand einer oberflächlichen, sich selbst feiernden Kultur, die bewusst in ihrer Komfortzone bleibt, ist wahrscheinlich eher das Resultat agiler Ideen in größeren Organisationen. Die Komplexität und die Abhängigkeiten größerer Organisation lassen keinen anderen Weg zu – denn Autonomie entsteht nur, indem mögliche Aufgaben “klein gemacht werden”. Den Teams bleibt letztlich nichts anderes übrig, als sich auf ihre Insel der Glückseligkeit zurückzuziehen. Das ist aber nicht der Ort, wo maximale Wertschöpfung entsteht.

 

 

“Je größer die Organisation, desto mehr Abhängigkeiten. Da es in diesem Umfeld immer schwieriger wird, echten Kontrast zu schaffen, fokussieren sich viele Teams auf ein Streben nach Geschwindigkeit – das behindert jedoch den Freiraum für echte Innovation.”

Rainer UtschRainer Utsch – Vice President Product, auxmoney

 

Was kannst Du tun?

Ich denke, es fängt grundsätzlich mit einem Bewusstsein für oberflächlichen Teamspirit und Konsenskultur an. Teste doch einfach mal aus, wie das Team damit umgeht, sobald du eine existierende Idee in Bezug auf ihre Wirksamkeit hinterfragst.

Wird dein Beitrag des Hinterfragens geschätzt oder wird es als Behinderung angesehen? Geht das Team auf der Suche nach Wirksamkeit heraus aus der Komfortzone oder wird bei der kleinsten Abhängigkeit zu anderen Teams oder kontrastreichen Veränderungen aufgegeben?

4. “Definition of Ready” ist zu kurz gedacht

Ein weiterer Aspekt aus der Geschichte der agilen Methoden, hat sich eventuell zu einem größeres Missverständnis entwickelt: Die “Definition of Ready”.

Woher kommt das? Was ist das Missverständnis?

Agile Methoden sind einst aus komplexen Softwareprojekten heraus entstanden, deren primäres Ziel es war, eine funktionierende Software bereitzustellen. Das heißt: mit der Auslieferung eines funktionierenden Inkrements war der Sprint abgeschlossen. Ein einfacher Usability-Test mit fünf Probanden reichte aus, um diesen Zustand zu validieren und das ergibt auch Sinn, wenn Funktionalität das einzige Qualitätskriterium ist.

Doch inzwischen werden mit Hilfe agiler Methoden, digital wertschöpfende Systeme gebaut. Somit kommen neben der Funktionalität als Hygienefaktor, weitere Ebenen dazu, die darüber entscheiden, ob das gelieferte Inkrement auch wirklich einen Wertbeitrag liefert.

Grob gesagt heißt das:

  • Funktioniert das Release, d.h. können Nutzer es ohne Probleme benutzen?
  • Wollen die Nutzer das Release auch wirklich benutzen? Wird es überhaupt akzeptiert?
  • Liefert das Release wirklich einen signifikant höheren Wertbeitrag (Business Value) oder ist er vielleicht sogar negativ?
Modell Return on Investment Pyramide
Abb. 5: Die konversionsKRAFT ROI Pyramide differenziert zwischen grundlegenden Hygienefaktoren (Funktionalität / Gebrauchstauglichkeit) und weiteren Ebenen als Leistungsfaktoren für echten Wertbeitrag.

Auch wenn es konstruiert klingt: Ein agiles Produktteam könnte ein funktionierendes Inkrement liefern (z.B. eine neue Darstellung von Filtern auf einer Listenseite im Onlineshop), das Feature wird von den Nutzern akzeptiert und tatsächlich genutzt (2. Ebene – Nutzer wollen es nutzen), dank der neuen Filter wird nun aber offensichtlich, dass es bestimmte Artikel im Shop nicht gibt und der Wertbeitrag ist negativ.

Das Resultat ist der Worst Case: Das Feature funktioniert – liefert aber einen negativen Wertbeitrag.

Im Rahmen einer Team-Retrospektive wird dieses Problem nicht erkannt werden, da die Outcomes eines neuen Features selten gemessen werden. Das ginge in der Praxis tatsächlich nur über ein Experiment. Einen A/B-Test, der die Variante der Listenseite ohne das neue Feature, mit der Variante mit dem neuen Feature, anhand einer echten KPI (z.B. Revenue per Visitor) vergleicht.

Stattdessen sind alle happy, dass das Produktteam eine gute Ideen hatte, die auch “ganz smooth” umgesetzt wurde.

Niemand wird sich beschweren, dass der Wertbeitrag des Features nicht gemessen wurde. Wie sollte das Team überhaupt damit umgehen? Schließlich kann das Team die Leistungsfaktoren gar nicht beeinflussen, oder?

Egal ob als Mitarbeiter oder Führungskraft: Du kannst diesen Zustand ändern. Ein erfolgreiches Team, das in einem Modus der Transzendenz arbeitet, wird durch Rückschläge und Fehler lernen und besser werden.

Es steht in keinem Widerspruch zu agilen Methoden, zwei bis vier Wochen auf die Messung des Wertbeitrags zu warten und dann daraus zu lernen. Das Team wird durch diese Erkenntnisse noch stärker – der Fokus der Betrachtung ändert sich bzw. erweitert sich um eine weitere Ebene, nämlich die Betrachtung “Was hat es eigentlich gebracht?”

Erst mit dieser Betrachtungsebene wird das Team zu wahrer Stärke kommen. Denn der neue Feedback-Kanal in Bezug auf Wertbeitrag ist deutlich stärker, als die “Wir sind alle super als Team”-Ebene, die ich allzu oft in Retros beobachte.

Erst mit Hilfe dieser Ebene werden sich Teams erlauben, sich gegenseitig herauszufordern, kontrastreichere Ideen zu entwickeln und Ideen zu veredeln.

5. User Stories ohne Wertschöpfung

Noch ein Missverständnis aus der Historie agiler Methoden heraus: Für das Erreichen der funktionalen Qualität eines Features war es bisher ausreichend, die gewünschte Qualität aus der Perspektive des Nutzers zu formulieren. Das ergibt Sinn, denn die Anforderungen wurden davor ja noch in Pflichtenheften aus technischer Sicht heraus definiert, daraus ergaben sich viel zu häufig Qualitätsdefizite.

Doch echter Wertbeitrag (“Outcome”) ergibt sich erst an der Schnittstelle zwischen Kundenbedürfnissen und dem eigentlichen Geschäftsmodell einer Software oder Website heraus.

Die Definition von User Stories ist zwar vor 20 Jahren der richtige Schritt gewesen, er geht jedoch heute, aus dem Blickwinkel der Wertschöpfung heraus, nicht weit genug.

Kundenbedürfnisse müssen viel tiefergehend analysiert und in Zusammenhang mit der gesamten Customer Journey und dem Geschäftsmodell gebracht werden. Das übersteigt oft die Fähigkeiten (s.o.: Customer Research ist nicht Teil der Teams) und auch die Komfortzone (s.o.: Komplexität und Abhängigkeiten als Impediment) der einzelnen Teams.

Das Resultat: Die gelebte Kundenzentrierung bleibt oberflächlich.

Zusätzlich ist zu wenig Zeit für eine systematische Product-Discovery, das bestätigen mir auch immer wieder einzelne Mitarbeiter aus agilen Teams. Es werden also lieber kurze Brainstorming-Workshops angesetzt um schnell Ideen zu entwickeln anstatt viel früher anzusetzen. Noch schlimmer: Oft ist das gar nicht gewünscht, das Management gibt ja im schlimmsten Fall die Roadmaps mehr oder weniger vor. Warum also tiefer einsteigen, wenn ohnehin keine Zeit da ist?

Zeitmangel verhindert eine systematische Analyse der Optimierungshebel

An dieser Stelle möchte ich auch nicht verbergen, dass eine wirklich tiefgehende Analyse der Kundenrealität, der gesamten Customer Journey, der Motive und Ängste auf bewusster und unbewusster Ebene, ein wirklich intensiver Prozess ist.

Überblick User Research Methoden
Abb. 6: Überblick über gängige Research-Methoden in der Product Discovery und ihre jeweiligen Vor- und Nachteile

Woran kannst Du erkennen, dass du und dein Team auf dieser oberflächlichen Ebene der Kundenzentrierung stecken? Ganz einfach: ihr redet stets über Features, Elemente, Kennzahlen, Buttons, Texte, etc.

Echte tiefgehende Kundenzentrierung führt dazu, dass ihr viel länger über die Probleme aus der Kundenperspektive heraus redet und sie analysiert, anstatt direkt über mögliche Lösungen zu reden. In den Gesprächen und Workshops wird dann viel mehr über Ängste, Erwartungen, Realitäten und Motive der Kunden gesprochen anstatt über die mögliche Lösung in Form deines Produkts oder deiner Website.

 

“Richtig gutes Produktmanagement ist irgendwo beides: Science und Art.”

Timo Bolse Head of Product consumer and new business ebayTimo Bolse, Head of Product Consumer and New Business, ebay

Die eigentliche Aufgabe eines guten Produktmanagers ist es, die Ziele und Motive der Kunden mit den Business-Zielen des Unternehmens in Einklang zu bringen. Ergebnisorientiert bewirkt es keinen Unterschied, ob die Teams gar nicht an den Business-Zielen arbeiten (Hypothese A) oder die wahren Kundenprobleme gar nicht kennen.

Keine Verbindung, keine Resultate.

Zusammen mit dem Zeit- und dem Effizienzdruck ergibt sich ein Bild:

Stell dir vor, du verbrennst mit deinem Sportwagen mal ordentlich Gummi auf der Startlinie. Sieht beeindruckend aus, aber du kommst nicht wirklich voran.

Noch schlimmer: Durch den ganzen Rauch um dich herum, hast du gar keine Orientierung mehr.

Genauso kommt mir oftmals die Situation in vielen agilen Teams vor.

Was kannst du tun? Gib’ dich nicht zufrieden mit diesem oberflächlichen Blick auf Kunden. Auch wenn die Zeit immer knapp ist: beginne mit einer systematischen und kontinuierlichen Erforschung der Kundenrealitäten auf allen Ebenen. Beschränke dich nicht auf das Thema deines Produktteams, vertehe die Customer Journey als ganzes.

Du wirst mit wirksameren Ideen belohnt – und das ist die Grundlage für die im ersten Teil genannte Hypothese A) – arbeite an den richtigen Zielen.

Sobald du diese Realität als Anspruch implementiert hast, wirst du schnell den Eindruck bekommen, wie wirkungslos wahrscheinlich rund 80% der Elemente in deinen Backlogs sind.

Frage Dich: “Wie kann diese Veränderung wirklich das Kundenverhalten und damit unsere Business-Ziele beeinflussen?”

Aus meiner Erfahrung heraus: Die Verbindung der Ideen im Backlog sowohl mit Kundenverhalten als auch mit den Business-Zielen ist das Qualitätskriterium schlechthin.

Kannst du eine glaubwürdige Verbindung herstellen? Bravo – arbeite weiter an der Idee, du kannst sie eventuell sogar noch stärker mache.

Du siehst nicht wirklich eine Verbindung? Räume dein Backlog auf, befreie es von dem Ballast wirkungsloser Ideen! Das Pareto-Prinzip gilt und es sagt uns, dass du mit nur 20% der Ideen 80% der Wirksamkeit erzielen wirst.

Fazit: Lösungswege für mehr Effektivität agiler Produktteams

Was muss sich ändern?

  1. Implementiere für mehr Effektivität Prozessartefakte aus CRO / Growth Hacking mit deinen agilen Prozessen.
  2. Das Management muss die richtigen Ziele setzen, die Teams müssen ihren Erfolg an den richtigen Zielen messen.
  3. Die Führung agiler Teams muss sich entsprechend verändern und mehr echte Verantwortung (“Ownership”) übertragen.
  4. Experimentieren ist nicht eine weitere Marktforschungsmethode am Ende eines Inkrements sondern ein grundlegendes Betriebssystem, Growth ist per se auf Effektivität getrimmt
  5. Fehlerkultur FTW! Vergeude die Zeit nicht mit oberflächlicher Konsenskultur. Relevanter Kontrast als Grundlage für die Verhaltensänderung der Kunden brauchen Mut und Kontrast.
  6. Die agilen Teams müssen anfangen, echte Outcomes über Experimente zu messen, Validation funktioniert nicht mit Interviews und erst recht nicht über Micro-Conversion. Always be Testing!
  7. Etabliere tiefgehende echte Kundenzentrierung, beginne damit die Kundenrealität systematisch erforschen, Product Discovery ist nicht in einem kreativen Brainstorming- oder Teamworkshop erledigt, sondern ein systematischer Prozess.

Geschafft 😉

In unserer Beitragsreihe zu den Themen Agile und Scrum folgt im August ein weiterer Beitrag, der sich mit der Rolle des Chief Product Officers auseinandersetzt.

Wir werden beleuchten, wie Konfliktpotenzial vermieden werden kann, wenn strategische Unternehmensmaßnahmen, mangelnde Vorkenntnisse zu Scrum und unterschiedliche Generationen an Mitarbeitern aufeinandertreffen.

André Morys

André Morys

André Morys (geb. 1974) ist Gründer und Vorstand von konversionsKRAFT, Deutschlands führender Agentur für Conversion-Optimierung und strategische Beratung in puncto digitales Wachstum. Darüber hinaus ist André Morys Initiator und Gründer der GO Group Digital, die ein weltweites Netz von Experten für digitale Transformation bildet.

Zu seinen Veröffentlichungen zählen “Die digitale Wachstumsstrategie” (2018) und „Conversion Optimierung” (2011) sowie zahlreiche Fachbeiträge in einschlägigen Medien zu Online-Marketing. Er ist zusätzlich als Dozent an der Fachhochschule Würzburg tätig und hält zahlreiche Keynotes und Vorträge auf nationalen und internationalen Kongressen zu den Themen digitales Wachstum, E-Commerce und Optimierungsstrategien.

Frage zum Artikel? Frag den Autor!

1 Reaktion auf „Agile Tretmühle: 5 Lösungsfelder für mehr Effektivität in agilen Produktteams (Part II)

  1. von Nicolas Meriel

    vielleicht nocht besser als der Teil 1.
    Bin gespannt auf Teil 3.
    Danke für diese nackte Wahrheit.

    Kann es sein, dass hier was nicht stimmt mit dem Wort „Kontrast“?
    „Fehlerkultur FTW! Vergeude die Zeit nicht mit oberflächlicher Konsenskultur. Relevanter Kontrast als Grundlage für die Verhaltensänderung der Kunden brauchen Mut und Kontrast.“

    Ich vermisse eine wenig das Thema KULTUR, corporate-culture bzw. it’s a cultural challenge etc..

    Gruss et merci

Schreibe einen Kommentar

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