Opportunity Solution Tree aus Continuous Discovery erklärt

Wie baue ich Produkte, die auch wirklich für Endkunden funktionieren? Da gibt es verschiedene Frameworks aus der Produktentwicklung und heute habe ich einen Kollegen von mir dabei, den Flo, der von einer ähnlichen Herausforderung steht und deshalb dachte ich, wenn ich es ihm eh erkläre, lasse ich die Kamera bei laufen und wir gucken mal, wie dieses Framework funktioniert. Flo, willst du nochmal sagen, was deine Herausforderung gerade war? Meine Herausforderung ist, dass ich ein Produkt bauen möchte, was sowohl beim Nutzer ankommt, also auch genutzt wird, gleichzeitig aber auch funktioniert in Form von Kosten-Nutzen-Verhältnis. Okay, ja cool. Also ich glaube, da könnte das Framework ganz gut helfen. Ich erkläre mal einmal, wo überhaupt das Problem da ist bei Produktentwicklung. Weil was wir üblicherweise haben, wenn wir digitale Produkte bauen, wir haben so einen Teil Business aus der Perspektive, wir wollen, dass es funktioniert, dass es Geld bringt, dass es zur Strategie passt. Dann haben wir auf der anderen Seite die Technologie, also wie setze ich das Ganze um, wie baue ich das, dass es funktioniert. Und auf der dritten Seite den Mensch, der das benutzen soll, wo zum Beispiel ein UX-Designer sitzt, der sich Gedanken macht, wie das verständlich ist und dass es auch ein Problem löst. Und wir haben hier quasi so dieses Dreieck in der klassischen Produktentwicklung, wo immer wieder die Probleme entstehen. Hier kommen Requirements von oben oder vom Kunden oder vom Vertrieb werden eingeschüttet. Der Designer hat aber mit den Endnutzern gesprochen, die haben andere Bedürfnisse. Und die Technologie sagt, naja, so ist das gar nicht machbar, was habt ihr euch dabei gedacht? Oder ich habe eine coole Technologie, die würde ich hier gerne ausprobieren. Passt dann aber am Ende nicht zu den beiden Zielen. Also ähnlich wie du vorhin mal sagtest, es gibt diese verschiedenen Dimensionen und es soll alles abdecken. Und was jetzt als alternatives Framework, anstatt dass wir ständig hier an den Ecken ziehen und auf den anderen beiden Seiten rutscht quasi die Decke vom Bett, gibt es eine Alternative. Das kommt maßgeblich von Theresa Torres, nennt sich Continuous Discovery. Und die hat gesagt, lass uns doch, anstatt dass wir ein Dreieck haben, wo immer die Ecken zu kurz sind, lass uns doch das als Baum quasi aufbauen, in einer gewissen Hierarchie, wie die Dinge sinnvoll zusammenpassen. Fängt hier oben an mit einem Business Impact. Also das, was soll dieses Produkt denn überhaupt geschäftlich erreichen? Das kann so etwas sein wie ein Umsatz oder wie einfach mehr Nutzer oder Abonnenten, die abgeschlossen sind. Das kann aber auch ein Gewinn, ein Deckungsbeitrag etc. Also welche Wirkung soll denn dieses Produkt erzielen geschäftlich, sodass es in die Strategie reinpasst? sind wir hier oben halt bei der Business Perspektive. Und da, das macht noch ein bisschen mehr Sinn, wenn du in einer Organisation bist. Ja, da darf ich kurz reingritschen. Kannst du vielleicht noch mal kurz von Impact und Outcome den Unterschied erklären? Mir ist gerade das nicht ganz, nicht ganz. Ah, das ist eine gute Frage. Bei Theresa Torres heißt das sogar Business Outcome. Das macht jetzt in dem Fall keinen Unterschied? Ja, es ist hier sehr nah beieinander. Der Outcome halt, was kommt dabei raus, werden wir hier in der nächsten Ebene sehen. Da ist dann der Product Outcome. Ich zeichne ihn vielleicht schon mal ein. Product Outcome. Der wäre so quasi die nächste Ebene. Was glaubst du mit deinem Produkt? Wo weißt du, dass dein Produkt erfolgreich ist und auf das Business einzahlt? Ich finde die Unterscheidung hier nochmal, als Haarspalterei, aber ein bisschen hilfreicher. Weil du beim Product Outcome sagst, wenn die Nutzer dieses und jenes machen, ist das das Ergebnis. Also zum Beispiel, die laden die App runter und dadurch setzen sie einen Account auf. Das Outcome ist quasi abgeschlossene Abonnenten zum Beispiel. Und der Impact, der dadurch entsteht für dein Business, sind dann Umsätze, Gewinne, reduzierte Kosten und solche Dinge. Ah, ja, das heißt, Business Impact wäre dann wahrscheinlich wirtschaftliche Zahlen? potenziell oder allermeisten schon oder auch marktabdeckung zum beispiel ja genau guter punkt und product outcome wäre dann outcome für endnutzer an der ecke dann durch endnutzer also dadurch dass menschen dein produkt nutzen entsteht ja ein gewisses ergebnis wie dein produkt dann auf dem business einzahlen gute frage stimmt Und bei Theresa Torres, nur wenn ihr euch das anschaut, die sagt Product Outcome und Business Outcome. Die sind einfach nur auf einer anderen Ebene. Business Impact betrifft die gesamte Organisation. Können wir auch hier mal hinschreiben. Und hier, das betrifft in der Regel dein Team. Wo du mit dem Team überlegst, wie können wir denn auf dieses Outcome einzahlen. Und was du halt jetzt machst. Eben um dieses Dilemma aufzulösen, dass immer alle an allen Ecken ziehen, sagst du halt, als erstes geh mal hin, spreche mal mit deinem Stakeholder oder mit deinem Sponsor, derjenige, der dein Team bezahlt und überleg mal, was ist denn eigentlich das strategische Business-Ziel, welchen Impact wollen wir erreichen? Woran macht derjenige, der dein Team bezahlt, euer Gehalt? Woran macht er fest, ob es sich das lohnt, das nochmal ein weiteres Jahr zu finanzieren? Und das sind halt meistens so Größen wie Umsatz, Marktabdeckung und solche Sachen. Das findest du aber wahrscheinlich hauptsächlich in größeren Organisationen vor, das musst du, oder? Weil also wenn du jetzt zum Beispiel irgendwie ein Startup hast oder so, dann hast du ja meistens einen Sinn oder eine Vision, weshalb du zusammenkommst. Dann ist ja meistens eher so das Outcome, der Hauptfokus, die Vision irgendwie zu realisieren. Und die Wirtschaftszahlen halten dich nur irgendwie am Laufen. Ja, das ist der Mittel zum Zweck, genau. Und in dem Fall fühlt es sich für mich gerade aber so an, dass der Impact das klare Ziel ist und deswegen seid ihr hier, hart gesagt. Und wie ist jetzt sozusagen euer Produkt, was ihr gerade machen wollt oder wo ihr gerade dran seid? Wie hilft uns das dabei, dass wir sozusagen weiterhin als Organisation bestehen bleiben oder unsere Wachstumszahlen erreichen? Ja, das beschreibt es ganz gut. Also wenn du OKR, sagt dir was, Objectives and Key Results, diese Business Impacts, das sind im Prinzip... Die Key Results von OKR. Also harte Metriken, das ist auf jeden Fall messbar. Hier das sollte auch auf jeden Fall messbar sein, quantitativ, an denen du festmachst, dass das jetzt einen positiven Impact auf deinen Geschäftserfolg hatte. Und bei einem Startup, da fällt das so ein bisschen zusammen. Wenn du quasi ein Team hast aus 10, 15, 20 Leuten, dann ist ja das Product Outcome gleichzeitig das Business sozusagen. Weil du hast nur ein Produkt, ein Team und Da kollabiert das in eine Größe wahrscheinlich. Was hier nochmal der Unterschied ist, Business Impact betrachtest du in der Regel so auf einem Jahr, auf einer Jahreszeitlinie, dass du sagst, dieses Jahr legen wir voll Fokus auf Umsatz oder auf Kundenzahlenwachstum oder sowas. Das heißt, da solltest du dich ungefähr so ein Jahr daran orientieren können. Product Outcomes, wenn du mit deinem Team ein Produkt entwickelst, in der Regel so auf einem Quartal, wo du sagst, Wir versuchen jetzt mal, indem wir die in die Größe hier verbessern, zum Beispiel der Onboarding-Prozess für Neukunden anstatt zwei Wochen nur noch zwei Tage dauert. Damit zahlen wir auf den Umsatz ein. Das wäre so eine Korrelation dazwischen zum Beispiel. Und da konzentrierst du dich in der Regel für ein Quartal so drauf, vielleicht auch mal zwei oder wenn es nach kürzerer Zeit erreicht ist auch weniger. Was du halt machst, um hier hinzukommen, wie gesagt, sprichst du mit deinem Stakeholder oder mit deinem Sponsor, mit dem Entscheider, der halt dein Team quasi finanziert. Und hier auf der nächsten Ebene sprichst du mit deinem Team halt, was ihr glaubt, wie könnt ihr darauf einzahlen. Und Outcomes habe ich meistens mehrere, wo ich überlege, das könnte aber auch eine Sache sein. Vielleicht ist es nicht nur der Onboarding-Prozess. Vielleicht ist auch der Support oder die Anzahl der Bugs und die Qualität der Software das Entscheidende, was hier drauf einzahlt. Also hast du hier immer weitere Product Outcomes. Und sagst dann aber, entscheidest dann aber gemeinsam hier, darauf konzentrieren wir uns, weil wir glauben, das macht jetzt den besten Hebel fürs nächste Quartal. Und das Team entscheidet das dann für sich oder ist das dann in Kombination mit der Organisation, dass man sich zusammen auf etwas einigt? Meistens entscheiden die das erstmal so für sich, treffen eine Entscheidung, sprechen dann wieder hier oben mit dem Stakeholder und sagen, wir haben uns aus den und den Gründen überlegt, dass wir so gut auf einzahlen können. Was hältst du davon? Siehst du das ähnlich? Und dann einigt man sich. Und wenn der Stakeholder aber weiß, dass das vielleicht eine schlechte Idee ist, weil der schon eine Ahnung hat, in einem halben Jahr wird sowieso was anderes gemacht, dann kann man sich das ein bisschen austauschen und in der Regel kommt man dann auf einen Ende. Also ja, guter Punkt. Eigentlich sollte man auch bei den Ebenen, die gleich noch kommen, halt immer wieder mit seinem Stakeholder checken, dass der quasi so im Prozess mit dabei ist. Dieses Stakeholder Alignment quasi. Und das ist auch eine schöne Sache. Alle sagen ja immer, ja, du musst die Stakeholder abholen und die müssen dabei sein. Und keiner weiß, es sagt dir aber, wie du das machen sollst. Das ist eine schöne Sache, wenn du sagst, hier, wir haben die drei Optionen, für die haben wir uns entschieden. Wie siehst du das? Und dann kann er sagen, bin ich dabei oder nicht. Da hast du immer wieder diesen Connect zu dem Gesamtbusiness. Und dann haben wir diese quasi, das ist das, wo wir über die Businessperspektive einkommen und das, was ja in der Organisation funktionieren muss. Was wir dann aber auf der nächsten Ebene machen, uns eher so den Menschen angucken, beziehungsweise deinen Kunden oder deinen Endnutzer und schauen auf der nächsten Ebene Opportunities. Möglichkeiten, man könnte auch sagen Challenges, die du rausfindest bei deinen Nutzern oder bei deinen Endkunden, die sagen, das stört mich, das ist problematisch, das wünsche ich mir. Also so Pains, Needs und Desires, sagt die Taurus immer. Das sind Dinge, die findest du mit deinen Kunden heraus in zum Beispiel Interviews oder mit Recherche, indem sie dich... wenn jemand sein Produkt nutzt, mal dahinter setzt, wenn es erlaubt ist, und einfach mal beobachtet, wie er seine Arbeit durchführt. Also ich schreibe hier mal User hin. Das wäre die Kontaktperson oder die Person, mit der ich das bespreche. Typischerweise halt hier führe ich Interviews und jetzt nicht in der Form von, ich will irgendwie, keine Ahnung, den Onboarding-Prozess verbessern, sag mir mal, wie ich den verbessern kann. Weil kann dir dein Kunde nicht sagen, der ist nun mal nicht der Produktentwickler, das bist in dem Fall ja du, sondern, indem du sagst, das letzte Mal, als du ein Onboarding bei einem Tool hattest, erzähl mir mal, wie das war. Fühl mich mal da durch. Und dann erzählt er dir eine Geschichte, was alles passiert ist. Und in der Geschichte hörst du dann, ah, das war irgendwie wohl problematisch, das hat ihn aber gefreut, das funktioniert gut. Und du lernst so quasi an der Story verschiedene Punkte, die wichtig sind oder die weniger wichtig sind oder die vielleicht so stören, dass du da eine Opportunity hast, die du lösen kannst. Also sowohl Wünsche als auch Probleme. sind immer wieder Opportunities, über die du ein Product Outcome generieren kannst, was auf dein Business Outcome einzahlt oder Business Impact. Das heißt, hier hast du in der Regel ganz, ganz viele, nachdem du diesen Customer Research betrieben hast. Machen wir auch nochmal, also ich wette, da gibt es nochmal jeweils zu den einzelnen Dingen ein eigenes Video, damit man das nochmal nachvollziehen kann, weil das gerade ein bisschen viel ist für ein Gespräch. Aber da kann man sich die Details nochmal angucken, wie finde ich denn Opportunities? Wie mache ich diese Leinwand und so? Und sozusagen das Team ist dann in der Mitte und sieht ganz viele oder erarbeitet ganz viele Opportunities und sieht den Business Impact, der erreicht werden soll und muss die beiden Sachen jetzt sozusagen zusammenbringen. Das eine ist vorgegeben, das andere gibt es einen riesen Pool an Möglichkeiten und das Ziel ist es, die richtigen, das wäre jetzt meine Frage auch, wie picke ich die richtigen raus? dass ich sage, jawohl, das klingt vielversprechend. Da gibt es verschiedene Bewertungsmethoden, was so im Prinzip, was die alle gemein haben, ohne jetzt auf eine spezielle einzugehen. Zwei Dinge. Einmal, wie stark ist die Verbindung hier zwischen dieser einen Opportunity und dem Product Outcome? Also wie stark zahlt das darauf ein? Kausalität quasi. Und wie viel weiß ich denn überhaupt darüber, ob das wirklich ein Problem ist? Also wenn ich mit einem Nutzer gesprochen habe und der sagt mir, das und das Feature ist irgendwie problematisch, stört mich, weil dauert zu lange, dann habe ich ja eine sehr, sehr kleine Evidenz, dass das ein Problem ist. Wenn ich aber mit 10, 20 Menschen gesprochen habe, ist es schon deutlich gesicherter, diese Erkenntnis. Und am besten ist es, wenn ich... zum Beispiel einen Prototypen gebaut habe und habe das mal gegeneinander vertestet und habe gesehen, die Leute, wenn die da draufklicken, das dauert wirklich ewig lange, bis die verstanden haben, wie sie von A nach B kommen. Also diese realen Daten aus der Praxis rausgeholt. Und so schaue ich mir quasi, das mache ich in dem Research, zu schauen, welche Opportunities sind wirklich wert, weiterverfolgt zu werden, indem ich... den Connect zwischen Product Outcome und Opportunity betrachte und wie viel weiß ich darüber. Ah ja, und wo kommt dann sozusagen in diesem das Thema eben der Machbarkeit vor? Nächste Stufe. Ah, ach so, ach so, wir sind noch, okay. Ja genau, es kommen nochmal zwei Stufen hier drunter. Du hast schon festgestellt, hier das hier ist alles Problemraum. Ich weiß irgendwie, wo ich hin will und ich überlege mir, welche Opportunities oder welche Probleme ich dabei lösen könnte. Und dann gehe ich in die nächste Stufe und gucke mal, was da Lösungen für sein könnten. Und da ist genau, da kommt dann die technische Perspektive. Welche Technologien gibt es da, welche Ideen habe ich, wie ich das auflösen könnte. Ah, und das ist abhängig von der Opportunity wieder. Und deswegen müssen wir da jetzt eins runtergehen. Genau, ja, genau. Weil ich habe ja hier Opportunity, hier Opportunity, da sage ich, aber hier, das ist mir gerade erst mal die wichtigste. Mit der möchte ich mal anfangen. Okay, jetzt bin ich aber fies. Und zwar, du sagst, du machst einen Baum. Was ist aber, wenn gewisse, also von der Machbarkeit kann es ja auch manchmal sein, dass es von mehreren Opportunities abhängig ist. Also ich ja eigentlich eher einen Graphen habe. Also ich muss zum Beispiel vielleicht erst die eine Opportunity nachgehen, damit ich eine andere nachgehen kann. Ach so. Und die zweite sozusagen im Step 2, die ist eigentlich wesentlich interessanter für das Outcome oder so. Ja, das bildet der Baum nicht ab. Stimmt, da hast du recht, das ist so eine methodische, Soll er vielleicht gar nicht abbilden, das weiß ich jetzt nicht? Ne, in dem Fall nicht. Also das ist zumindest nicht vorgesehen, ist aber ein interessanter Fall. Also in der Praxis würde ich mir jetzt wahrscheinlich einfach einen Pfeil von hier nach da machen, dass ich erst das löse und dann das. Dann ist es kein Baum mehr. Ne, aber das Team soll damit hier arbeiten können und verstehen. Genau, wenn man es genau nimmt, ist es dann kein Baum mehr. Ja, aber... Du verstehst ja, was du da gerade machst und dadurch, dass du es immer vor dir hast, würdest du dann sagen, erst mal müssen wir das lösen, bevor wir das lösen können. Das kam mir bisher noch nicht vor in der Praxis. Bisher waren die meisten Sachen so getrennt, weil es aus Geschichten entstanden ist, die erzählt wurden und dann konnte ich am Ende sagen, ich verfolge jetzt nur diese Opportunity. Bei den Lösungen ist anders. Bei den Lösungen kam dann schon mal, wir müssen aber erstmal die Server-Architektur hinstellen, bevor wir das und das so umsetzen können. Die würdest du dann wahrscheinlich untereinander malen. Aber bei den Opportunities noch nicht. Opportunities sind dann sowas in der Regel wie, mich stört das total, dass der Onboarding-Prozess so lang ist. Oder ich verstehe nicht, was dieser Button soll. Oder ich kriege keine Übersicht, wenn ich dieses Tool benutze. Das sind so klassische Opportunities, die dir die Nutzer sagen, die du erst mal aufnimmst und versuchst möglichst präzise aufzuschreiben. Warum ist das eigentlich ein Problem? Wie entsteht das? Du kannst ja auch dann Sub-Opportunities haben, wenn der sagt, ich verstehe das Tool hier nicht oder ich verstehe die Übersicht nicht, kann das ja verschiedene Ursachen haben. Das kannst du nochmal aufschlüsseln, sodass du dann diese Aufschlüsselung hast. Wenn du das Problem löst, versteht der das besser. nutzt dein Produkt eher, der ist eher bereit Geld zu zahlen und am Ende freut sich der Umsatz. Also du hast diesen Connect immer von oben nach unten, dass du immer weißt, warum mache ich das eigentlich, worauf zahlt das gerade? Ja, verstehe. Das war Opportunity. Dann schaust du, hast du dann mit dem User geresearcht und wenn du dir recht sicher bist, dass das was sinnvoll ist, dann gehst du rein und sagst, okay, diese Opportunity möchte ich jetzt verfolgen, die anderen ignoriere ich erstmal. Erstmal nur diese. Das ist das Schöne, du hast halt immer einen Fokus auf einen, auf ein Outcome, auf eine Opportunity, damit du nicht so all over the place versuchst, die Welt zu retten an allen Ecken, weil das geht ja am meisten schief. Und dann überlegst du dir, was könnten denn Ideen sein, also Solutions heißen die bei Taurus, um dieses Problem zu lösen. Kannst du zum Beispiel hier so ein Brainstorming, Brainwriting etc., diese ganzen Kreativmethoden, die man alle nutzen kann. Und da kommen dann meistens zwei Millionen Ideen raus, von denen ich viele auch direkt irgendwie aussortieren kann. Und ein paar machen vielleicht mehr Sinn. Da kann man sich dann für die zwei, drei, wo man sagt, okay, die sind vielversprechend und da habe ich auch eine gewisse Evidenz, dass das passt, geht man dann hin und formuliert die mal aus. Zum Beispiel mit so einem Idea Canvas, was ich in einem anderen Video mal vorgestellt hatte. Oder auch die User Story Map. um zu zeigen, wie würde diese Lösung aussehen auf einer Karte quasi mit den ganzen Features, was würde das bedeuten. Und da gibt es auch ein Video dazu und wir hatten auch schon mal darüber geredet, Story Map. Und damit kann ich dann erstmal beschreiben, was ist diese Idee. Und unter jeder Idee, also jetzt sage ich, okay, die bewerte ich wieder und was würde ich denn gerne verfolgen, was passt zum Team, was passt zum Problem, habe ich jetzt gesagt, naja, diese Idee und diese zwei vielleicht noch. gucke ich bei jeder Idee, leite ich mir Hypothesen ab und führe Tests durch. Jetzt haben wir hier noch mehr Tests und hier sind auch Tests. Test, Test, basierend auf Hypothesen. Also Hypothesen sind gewisse Annahmen, die du triffst, damit diese Idee funktioniert. Also damit die Idee funktioniert, heißt, damit die Idee auf diese Opportunity einzahlt. Genau. Ja, genau. Also sowohl das, also bei Hypothesen habe ich immer, ich habe einmal, zahlt die auf das Problem ein, so Desirability-Hypothesen quasi, ist das was, was dem Nutzer wirklich hilft. Und ich habe auch Usability-Hypothesen, versteht der Nutzer, wie das funktioniert und hat er die Zugänge dazu, um das so zu nutzen und das Fachwissen und keine Ahnung, Lust darauf, die Idee zu nutzen. Dann gibt es noch zwei andere Hypothesen. Das sind einmal Feasibility-Hypothesen. Also haben wir die Technologie, die Fachkräfte und die Ressourcen, die Zeit und das Geld, das umzusetzen. Und hier Viability, also Business-Viability-Hypothesen. Passt das zu unserer Strategie, zum Marketing, in die Organisation hinein? Wenn das irgendwie neue Arten von Verträgen sind, kann unsere Legal-Abteilung das überhaupt abbilden und so weiter. Also passt das zum Business? Ja, mal eine Frage als Anwendungsfall. Wenn du jetzt sagst, okay, Business Impact ist so vielleicht auf Ja gedacht, Outcome ist so quartalsweise. Von was für Zahlen, also wie viele Opportunities ist dann so, die man so pro Quartal dann nachjagt und wie viele Solutions schaut man sich dann so ungefähr an? Also mal so als Beispiel, um wie viele Tests fährt man dann auch? Also was sind so die Mengengröße dabei? Ja, das ist natürlich ganz schwer pauschal zu sagen, weil das geht so von bis. Aber in meinem letzten Projekt zum Beispiel hatten wir an Opportunities für ein Product Outcome so zwischen 15 und 20 ungefähr, die aus den... Also pro Outcome, wenn du mit Nutzern sprichst, die sagen dir natürlich nicht nur für dieses eine Outcome Dinge, sondern auch für alle anderen Sachen, die denen gerade so durch den Kopf gehen. Die haben wir dann auch schon mal aufgenommen und zu den anderen Outcomes zusortiert, aber halt nicht weiterverfolgt in dem Moment, weil wir gesagt haben, das ist unser Fokus. Dann hatten wir hier so 15 Opportunities, wo wir dann aus denen gesagt haben, ja, das ist die eine, die wollen wir weiterverfolgen. Und dann beim Ideen generieren, Das kann dir explodieren so zwischenzeitlich, wo du so 50 verschiedene Ideen hast, wovon dann aber 5 vielleicht sinnvoll sind. Wie kriegst du das raus? Ob die sinnvoll sind? Ja, also erst wenn die sinnvoll sind, gehst du ja wahrscheinlich in die Testing-Phase. Genau, ja. Also ob das für dich sinnvoll ist. Ich würde das wahrscheinlich für jetzt, für das Video, in ein separates Video auslagern, weil es dann zu viel wird. Für dich ganz kurz. wird es wahrscheinlich nicht aufgenommen mit dann, aber du hast diese Dimensionen, Business Viability, Human Desirability, Technological Feasibility, kannst du dir quasi auch hinmalen in der Tabelle und bewertest dann auf einer Skala von 1 bis 10 zusammen mit dem Team. Ah, okay, dann kriegst du eine Zahl raus und weißt dann so, die sind am besten für uns gerade auszusehen und dementsprechend, okay, verstehe. Genau, ja. Also eine Teilungsvorlage und dann so, ja, okay, die drei sind, die diese machen. Genau, ja, genau. Und dann hast du so drei, die du mal ein bisschen weiter noch ausformulierst, hier mit dem Idea Canvas, was ich eben angesprochen hatte. Die suchen, genau, ja, genau. Und dann sagst du, dann überlegst du dir im nächsten Schritt, welche Dinge müssen denn alle zutreffen, damit das eine gute Idee ist? Also... die löst das Problem, der Nutzer versteht es, wir können es umsetzen und es passt zu unserem Business. Das sind diese vier Dimensionen, zu denen Hypothesen generiert werden. Und bei den Hypothesen auch wieder pro Idee, wenn es eine große Idee ist, können da auch schon mal 25 bis 50 Hypothesen hinterstecken. Und da aber auch die gute Nachricht, ich muss nicht alle 50 Hypothesen testen. Viele davon sind einfach so unbedeutend, dass man auch sagen kann, naja... Ich habe ein gutes Gefühl dabei, das Risiko gehe ich ein. Aber es gibt auch Hypothesen, die du einfach schwer abschätzen kannst, wo du nicht weißt, versteht der Nutzer das und gefällt ihm das wirklich? Löst das sein Problem? Gerade da, ganz klassisch, baue ich einen kleinen Prototypen, der das mal vertesten kann und lass den Nutzer das mal erleben. Das kann irgendwie eine PowerPoint-Präsentation sein, die sich durchklicken lässt. Und was ich dir hinstelle und sage, hier, nutz mal das Tool. Ich sage nichts dazu, mach mal. Und dann schaue ich, verstehst du, welche Button du klicken sollst, in welcher Reihenfolge, um dein Problem zu lösen? Oder baust es in deine bestehende Software ein? MVP ist meistens sehr aufwendig, nur um die Hypothese zu testen. Deshalb halt in der Regel Prototypen, irgendwie Klick-Dummies oder auf die Value Proposition, also was dieser Wert liefern soll von der Idee. Zum Beispiel, was wir mal hatten, eine Werbung zu schalten und zu schauen, wie viele Leute klicken da drauf quasi und landen dann aber auf so einer Testseite oder so. Und du erhebst damit so diese Fake-Door-Tests quasi, erhebst damit Daten und schaust, wie viele Leute klicken auf die Idee im Vergleich zu der. Kannst du schön gegeneinander matchen. Da gibt es wieder ganz viele Möglichkeiten, Hypothesen aufzustellen und zu testen. Und halt immer zu schauen, da kriegen wir dann einmal den Bogen hin, wie stark zahlt diese Idee dann auf das Product Outcome ein. Deshalb hatte ich eben gesagt, Product Outcome sollte messbar sein, wie ein Key Result, damit ich sagen kann, da komme ich wirklich dem Ziel auch näher. Jetzt hatte ich mal in einem Projekt, dann hatte einer gesagt, es gibt aber auch Dinge, die können wir gar nicht messen, die keinen messbaren Unterschied machen. Kurz überlegt, ja okay, aber warum sollte ich es dann bauen, wenn es keinen messbaren Unterschied macht? Wenn niemand feststellen kann, dass dadurch die Welt besser geworden ist, dann ist das vielleicht nicht so eine gute Idee, die wirklich Wert beiträgt im Sinne des Produkts. Und so schließt sich quasi der Kreis und dann weiß ich am Ende, wenn ich teste. Also Ziel ist halt in... sagen wir mal in zwei Wochen von der Opportunity zu einem Test zu kommen, den zu validieren und dann sagen zu können, verfolge ich jetzt weiter oder nicht. Und wenn nicht, dann habe ich ja noch 27 andere Solutions, die ich halt auch weiter verfolgen kann. Ja, verstehe, verstehe. Aber es ist gar nicht so einfach, gerade von Tests wieder auf Outcome zu kommen. Also ich habe irgendwie so eine Testing-Card, wo ich reinschreibe, ich will Folgendes durchführen, ich nehme Folgendes an, was passiert, mache den Test und kriege ein Ergebnis mit. Du bist eingetroffen und auch folgendes ist passiert. Und jetzt den Bogen wieder aufs Outcome zu schlagen. Hast du da ein Beispiel? Sagen wir, dein Outcome war, es sollen sich mehr Leute, die Produktregistrierung oder das Onboarding in einem Tool soll schneller gehen. Du hast einen Neukunden, der sagt, ich möchte dein Tool haben. Und bis er das produktiv einsetzen kann, dauert aktuell zwei Wochen. Hatte ich ja am Anfang das Beispiel. So, und jetzt hast du deine Opportunities, die sagen, naja, ich verstehe halt hier den und den Schritt nicht immer. Und deine Solution wäre, okay, ich mache einen kleinen Tooltip dran. Immer wenn der an dem Schritt ist, poppt ein Tooltip auf, der dem erklärt, hier musst du übrigens das und das machen. Und dann schaue ich, hat dann dadurch im Schnitt, geht so mein Onboarding schneller. Die ersten zehn Nutzer, die ich da durchlaufen lasse, messe ich die Zeit und gucke, wie schnell die dann produktiv sind. Das ist jetzt ein bisschen ein konstruiertes Beispiel, aber so würde ich halt schauen, ist das, was ich hier implementiere, zahlt das darauf ein, was ich damit eigentlich erreichen wollte. Wenn ich dann sage, ah, okay, die können jetzt wirklich viel schneller onboarden, weil die nicht irgendwie an dem Schritt hängen, dann ist das ein gutes Zeichen, dann komme ich dem näher. Das heißt aber auch, oder was heißt aber, das bedeutet auch, dass damit du sozusagen diesen Flow einsteigen kannst, aber auch schon klar sein muss von deinem Produkt, wie kann ich meine Outcomes messen und ich habe sie schon gemessen. Weil ich habe schon Daten, lege jetzt neue Opportunities ran und gucke im Vergleich zu vorher. Ja, meistens. Also es muss ja nicht unbedingt 20 Prozent schneller sein. Das kann auch einfach heißen, dass du sagst, Nutzer sollen sich im Schnitt innerhalb von fünf Minuten in der Maske zurechtfinden oder keine Ahnung, die den Prozess durchlaufen können, den du vorgesehen hast. Du solltest vorher eine Ahnung haben, ungefähr ist in fünf Minuten jetzt viel oder wenig. Also du musst dich vorher mit dem Tool auseinandergesetzt oder mit deinem Produkt auseinandergesetzt haben. Für, wenn es jetzt komplett Greenfield ist und du hast so gar nichts, gar nichts. dann wäre das nicht der erste Schritt in der Produktentwicklung, dass du sagst, okay, lass mal einen Baum malen, weil da weißt du hier noch zu wenig über die Outcomes. Was aber okay ist, ist, wenn du hier erstmal Annahmen triffst, wo du glaubst, dass das ist, daran kann ich einen Erfolg festmachen und gehst dann aber hier im Prozess hin und findest Dinge heraus und überarbeitest auch deine Annahmen nochmal. Also auch Business Impact ist ja auch eine Annahme, wo du glaubst, diese Strategie hilft meinem Geschäft, um sich besser zu entwickeln. Vielleicht finde ich hier daraus, dass das andere Dinge sind, die ich hier oben verfolgen sollte. Und deshalb ist es, also dieses Framework, Continuous Discovery, über alle diese Dinge finde ich immer wieder neue Sachen heraus und lerne und entwickle mich dann weiter. Verständlich. Jetzt fehlt noch hier. Also hier unten sind wir dann in diesem ganzen Lösungsraum. und kriegen hier halt immer diesen Prozess einmal durch, von oben bis zu Lösungen, die teste ich und dann schaue ich mir weiter an. Wenn diese Lösungen schon funktionieren und ich implementiere die, dann kann ich ja auch zum nächsten Opportunity oder zum nächsten Product Outcome eingehen, je nachdem, wie viel ich hier verbessern will. Und das mache ich quasi immer, solange ich mein Produkt betreibe und habe so sichergestellt, dass ich immer... mein Produkt so weiterentwickele mit einem gewissen Fokus auf die Dinge, die mir wichtig sind und dass ich wirklich Dinge baue, die Probleme lösen, um auf mein Geschäft einzuzahlen. Cool, danke schön. Alles klar, danke fürs Zuhören. Also das war der Opportunity Solution Tree von Theresa Torres. Und wenn euch das geholfen hat, freue ich mich über einen kleinen Like, wie immer. Und würde mich aber auch sehr, sehr freuen, weil ich ja auch selber auf YouTube herausfinden möchte, welche Probleme ich am besten löse. Wenn ihr mal in die Kommentare schreibt, welche Fragen euch dabei durch den Kopf gehen, das hilft mir dann herauszufinden, wo sind Opportunities, um mein Produkt weiterzuentwickeln. Vielen Dank, liebe Grüße, ich bin Matthias Böhmer und bis bald.

Der Opportunity Solution Tree ist ein Werkzeug, um digitale Produktentwicklung zu strukturieren. Mit ihrem Buch "Continuous Discovery Habits" schlägt Teresa Torres ein Framework für Produktentwicklung vor, das viele sinnvolle Konzepte kombiniert und eine übersichtliche Struktur gibt.

Mein codecentric-Kollege Flo wollte mehr über digitale Produktentwicklung wissen und wir haben die Chance genutzt, das Gespräch aufzuzeichnen.

0:00 Herausforderung bei digitaler Produktentwicklung
1:50 Business Impact
3:25 Product Outcome
10:19 Opportunities
18:20 Solutions
19:38 Tests
25:38 Zusammenfassung