ODI on MYLES — Strategie & Innovation Beratung

Produktstrategie fuer Innovationsfuehrer im Unternehmen

Mon, 23 Mar 2026 00:00:00 +0100

Warum die meisten Unternehmens-Produktstrategien scheitern, bevor sie beginnen

Hier ist eine Zahl, die Sie beunruhigen sollte: Laut einer Studie der Product Development and Management Association (PDMA) verfehlen 40 Prozent der von etablierten Unternehmen lancierten Neuprodukte ihre Geschäftsziele. Nicht Startups, die mit Risikokapital und Bauchgefühl arbeiten — sondern etablierte Unternehmen mit dedizierten F&E-Budgets, erfahrenen Produktteams und jahrzehntelangem Marktwissen.

Das Problem ist nicht mangelnde Strategie. Gehen Sie in jedes Produktplanungsmeeting eines DACH-Konzerns und Sie finden Strategiedokumente. Reichlich davon. Das Problem ist, dass die meisten Unternehmens-Produktstrategien auf einem Sandfundament gebaut sind: Interne Annahmen, die als Kundenerkenntnisse verkleidet sind. Wettbewerbsanalysen, die für Differenzierung gehalten werden. Roadmaps, die vom lautesten Führungskräftigen getrieben werden statt vom wichtigsten Kundenoutcome.

Jobs to Be Done: Der vollstaendige Leitfaden

Sun, 22 Mar 2026 00:00:00 +0100

Warum Innovation so oft scheitert — und was die Jobs to Be Done Methode daran ändert

Eine Zahl, die man sich vor Augen halten sollte: Branchenforschung beziffert die Misserfolgsquote neuer Produkte konsistent auf rund 70 Prozent — die viel zitierte Doblin-Studie nannte 96 Prozent über alle Innovationsinitiativen hinweg; spätere akademische Arbeiten verorten neue Konsumprodukte im Bereich 70–80 Prozent. Welche Zahl auch immer Sie heranziehen: Die Mehrheit neuer Produkte verfehlt ihre finanziellen Ziele. Nicht weil Teams an Talent oder Einsatz mangeln. Nicht weil Budgets zu eng kalkuliert sind. Sondern weil Produktteams um das bauen, was sie denken, was Kunden wollen — statt zu verstehen, was Kunden tatsächlich zu erreichen versuchen.

Wertversprechen gestalten mit Jobs to Be Done

Fri, 20 Mar 2026 00:00:00 +0100

Das Präzisionsproblem beim Wertversprechen

Jedes B2B-Unternehmen hat ein Wertversprechen. Die meisten klingen gleich.

“Wir liefern innovative Lösungen, die unseren Kunden helfen, Effizienz zu verbessern und Kosten zu senken.” Ändern Sie den Firmennamen, und dieser Satz könnte jeden Industriehersteller in Europa beschreiben. Er kommuniziert nichts Spezifisches. Er differenziert sich von nichts. Er trifft niemanden im Besonderen.

Das Problem liegt nicht an mangelndem Einsatz oder fehlender Intelligenz der Produktteams. Das Problem liegt darin, dass traditionelle Methoden des Wertversprechen-Designs — sogar angesehene wie Osterwalders Value Proposition Canvas — die Präzision vermissen lassen, die nötig ist, um Wertversprechen zu gestalten, die wirklich bei spezifischen Kundensegmenten ankommen.

Von Kundenerkenntnissen zur Produkt-Roadmap

Thu, 19 Mar 2026 00:00:00 +0100

Der Erkenntnisfriedhof

Jedes Unternehmens-Innovationsteam hat ihn. Einen Ordner — digital oder physisch — voller Forschungsberichte, die niemand mehr liest. Kundenbefragungs-Transkripte. Ethnografische Studien. Umfrageergebnisse. Design-Sprint-Outputs. Personas, die mit großem Enthusiasmus entwickelt wurden und dann nie wieder referenziert wurden.

Das ist der Erkenntnisfriedhof. Und seine Existenz enthüllt das zentrale Versagen der meisten Unternehmens-Produktorganisationen: die Unfähigkeit, Kundenerkenntnisse in Roadmap-Entscheidungen zu übersetzen.

Das Forschungsteam produziert Erkenntnisse. Das Produktteam nickt. Und dann werden Roadmap-Entscheidungen auf dieselbe Weise getroffen wie immer — durch eine Kombination aus Führungsmeinung, Wettbewerbsreaktion, Vertriebsdruck und Engineering-Begeisterung. Die Erkenntnisse liegen auf dem Friedhof, gelegentlich für eine Präsentation ausgegraben, aber nie für eine Entscheidung genutzt.

Product-Market Fit im B2B: Besonderheiten fuer Unternehmen

Wed, 18 Mar 2026 00:00:00 +0100

Der Product-Market-Fit-Mythos im Enterprise B2B

Marc Andreessens berühmte Formulierung — “Product-Market Fit bedeutet, in einem guten Markt mit einem Produkt zu sein, das diesen Markt befriedigen kann” — ist im Startup-Umfeld zur Lehrmeinung geworden. Und im Startup-Umfeld funktioniert sie einigermaßen gut. Man startet ein Produkt, beobachtet, ob Kunden es geradezu aus den Händen reißen, und weiß innerhalb von Monaten, ob man Fit hat.

Versuchen Sie, das auf einen Kranhersteller anzuwenden, der Bauunternehmen in ganz Europa beliefert. Oder auf ein Medizintechnikunternehmen mit einem 18-monatigen regulatorischen Zulassungszyklus. Oder auf einen Landmaschinenhersteller, dessen Kunden alle sieben Jahre kaufen.

Product Discovery: Methoden, um das Richtige zu bauen

Tue, 17 Mar 2026 00:00:00 +0100

Das rückwärts laufende Discovery-Problem

Die meisten Produktteams in Unternehmen sind überzeugt, Product Discovery zu betreiben. Sie befragen Kunden. Sie führen Umfragen durch. Sie besuchen Messen und hören, was der Markt sagt. Sie erfassen Feature-Anfragen von Vertriebsteams und Support-Tickets.

Und dennoch liegt ihre Trefferquote bei neuen Produkten trotz all dieser Bemühungen in der Nähe des Branchendurchschnitts: Rund sechs von zehn Produkten verfehlen ihre Geschäftsziele.

Das Problem ist nicht, dass diese Teams Discovery überspringen. Das Problem ist, dass ihr Discovery-Prozess rückwärts läuft. Sie beginnen mit Lösungen und arbeiten sich zurück zu Problemen. Sie fragen Kunden “Was wollen Sie?” statt “Was versuchen Sie zu erreichen?” Sie erfassen Feature-Anfragen statt unerfüllte Outcomes zu messen. Sie lassen die lautesten Stimmen — ob interne Fürsprecher oder Großkunden — die Agenda bestimmen.

Produktstrategie-Frameworks: Ein vergleichender Leitfaden

Mon, 16 Mar 2026 00:00:00 +0100

Das Framework-Problem

Produktverantwortliche in Unternehmen leiden nicht unter einem Mangel an Frameworks. Sie ertrinken darin. Porters Five Forces. Blue Ocean Strategy. Lean Startup. Design Thinking. Jobs to Be Done. Die JTBD Growth Strategy Matrix. Jedes Framework hat seine eigenen Bücher, Berater, Zertifizierungen und Versprechen.

Das Ergebnis ist keine Klarheit, sondern Verwirrung. Produktteams kombinieren Elemente verschiedener Frameworks, ohne ihre grundlegenden Annahmen zu verstehen. Sie wenden Startup-Methoden auf Unternehmenskontexte an. Sie benutzen Wettbewerbsanalyse-Werkzeuge, um Kundenbedürfnis-Fragen zu beantworten. Und sie wundern sich, warum ihre Produktstrategien mittelmäßige Ergebnisse liefern.

Innovationsberatung: Systematische Innovation im Unternehmen

Sun, 15 Mar 2026 00:00:00 +0100

Das Problem mit Innovation in DACH-Unternehmen

Ein mittelständischer Maschinenbauer aus Oberösterreich investiert jährlich 7 % seines Umsatzes in Forschung und Entwicklung. Die Ingenieure sind erstklassig, die Fertigungstiefe beeindruckend, die Patentquote über Branchendurchschnitt. Trotzdem verliert das Unternehmen seit drei Jahren Marktanteile an einen Wettbewerber, der technisch weniger kann — aber offenbar besser versteht, was Kunden tatsächlich brauchen.

Diese Geschichte ist kein Einzelfall. Sie ist der Normalfall.

Studien zeigen seit Jahrzehnten dasselbe Bild: Zwischen 70 und 95 Prozent aller neuen Produkte scheitern kommerziell. Nicht, weil die Technologie versagt. Sondern weil Unternehmen Probleme lösen, die niemand hat — oder Probleme lösen, die bereits gut genug gelöst sind.

Kundenzentrierte Innovation: Warum klassische Methoden versagen

Sun, 15 Mar 2026 00:00:00 +0100

Die unbequeme Wahrheit über kundenzentrierte Innovation

Jedes Unternehmen behauptet, kundenzentriert zu sein. In jeder Unternehmenspräsentation steht “Der Kunde steht im Mittelpunkt.” In jeder Strategiediskussion fällt der Satz “Wir müssen näher an den Kunden.”

Und trotzdem scheitern 70 bis 95 Prozent aller neuen Produkte am Markt.

Wie kann das sein? Wenn alle kundenzentriert arbeiten — warum versagen dann so viele Innovationen?

Die Antwort ist schmerzhaft einfach: Die meisten Unternehmen verwechseln Kundennähe mit Kundenverständnis. Sie reden mit Kunden, führen Befragungen durch, laden zu Fokusgruppen ein, erstellen Personas und User Journeys. Aber sie stellen die falschen Fragen — und interpretieren die Antworten falsch.

Outcome-Driven Innovation im DACH-Raum

Sun, 15 Mar 2026 00:00:00 +0100

Warum ein amerikanisches Framework perfekt in die DACH-Ingenieurskultur passt

Outcome-Driven Innovation (ODI) wurde in den USA entwickelt. Tony Ulwick, Gründer von die ODI-Praxis, hat die Methodik über drei Jahrzehnte in Projekten mit Unternehmen wie Johnson & Johnson, Microsoft und Bosch verfeinert. Die Erfolgsquote: 86 Prozent der ODI-gestützten Produktlaunches sind erfolgreich — fünfmal besser als der Branchendurchschnitt.

Diese Zahlen klingen beeindruckend. Aber für einen deutschen Ingenieur, einen österreichischen Produktmanager oder eine Schweizer Geschäftsführerin reicht die amerikanische Erfolgsgeschichte nicht. Die Frage lautet: Funktioniert das auch hier? In unserer Kultur, mit unseren Kunden, in unseren Märkten?

Was ist ODI? Outcome-Driven Innovation erklaert

Sun, 15 Mar 2026 00:00:00 +0100

Das Innovationsproblem, ueber das niemand sprechen will

Jedes grosse Unternehmen im DACH-Raum hat einen Innovationsprozess. Die meisten haben mehrere. Es gibt Stage-Gate-Modelle, Design-Thinking-Workshops, Hackathons, Innovationslabs und — der neueste Trend — KI-gestuetzte Ideengeneratoren. Was die meisten davon teilen: Sie liefern keine zuverlaessig erfolgreichen Produkte.

Die Daten sind eindeutig und unbequem. Je nach Studie scheitern zwischen 72 und 95 Prozent der Neuprodukte daran, ihre Umsatzziele zu erreichen. McKinsey, BCG und die Product Development and Management Association haben Varianten dieser Zahl veroeffentlicht. Sie hat sich in 40 Jahren nicht wesentlich verbessert.

Der ODI-Prozess: 6 Schritte zur systematischen Innovation

Sat, 14 Mar 2026 00:00:00 +0100

Sechs Schritte, die veraendern, wie Sie innovieren

Die meisten Innovationsprozesse sind entweder zu vage (“empathisieren, ideieren, prototypieren, testen”) oder zu starr (“Formular Gate-2-14B ausfullen”). Outcome-Driven Innovation nimmt den Raum dazwischen ein — strukturiert genug, um wiederholbar zu sein, spezifisch genug, um bei jedem Schritt handlungsweisende Ergebnisse zu liefern.

Der ODI-Prozess hat sechs Schritte. Sie sind sequenziell: Jeder Schritt produziert Deliverables, die der naechste Schritt benoetigt. Einen Schritt zu ueberspringen oder sie in falscher Reihenfolge durchzufuehren, unterbricht die Logikkette und schaedigt die Ergebnisse. Das ist kein Bueffet, bei dem man Favoriten auswaehlt — es ist ein Ingenieursprozess, bei dem jede Stufe auf der vorigen aufbaut.

Outcome Statements schreiben: Produktentscheidungen gezielt treffen

Fri, 13 Mar 2026 00:00:00 +0100

Die Satzstruktur, die den Produkterfolg voraussagt

Hier ist eine Behauptung, die absurd klingt, bis man sie in der Praxis sieht: Der einzelne groesste Bestimmungsfaktor dafuer, ob Ihr naechstes Produkt erfolgreich oder ein Misserfolg ist, ist die Qualitaet von ein paar hundert Saetzen.

Nicht Ihr Ingenieurtalent. Nicht Ihr Marketingbudget. Nicht Ihre Wettbewerbsanalyse. Saetze.

Konkret: Outcome Statements — die praezise formulierten Ausdruecke von Kundenbeduerfnissen, die das Rueckgrat von Outcome-Driven Innovation bilden. Schreiben Sie sie richtig, und Sie haben eine quantifizierbare Karte jeder Chance in Ihrem Markt. Schreiben Sie sie falsch, und Sie erheben Rauschen.

Der Opportunity-Algorithmus: Unterversorgte Kundenbeduerfnisse finden

Thu, 12 Mar 2026 00:00:00 +0100

Die Formel, die das Bauchgefuehl ersetzte

Jedes Produktteam kennt dasselbe Argument: “Welche Kundenbeduerfnisse sollen wir zuerst angehen?” In den meisten Organisationen wird diese Debatte durch Senioритaet, Lautstaerke oder Vertriebsdruck entschieden. Das Lieblingsprojekt des VPs gewinnt. Der Kunde, der am lautesten geschrien hat, gewinnt. Der Auftrag, der kurz vor dem Abschluss steht, gewinnt.

Der Opportunity-Algorithmus ersetzt diese Dysfunktion durch Mathematik. Er ist die quantitative Grundlage von Outcome-Driven Innovation und tut etwas, das kein Brainstorming, keine Empathy Map und kein NPS-Score kann: Er teilt Ihnen mit statistischer Sicherheit genau mit, welche Kundenbeduerfnisse in Ihrem Markt unterversorgt, angemessen versorgt oder ueberversorgt sind.

ODI vs. Design Thinking: Ergaenzend oder konkurrierend?

Wed, 11 Mar 2026 00:00:00 +0100

Der Methodenstreit ist eine Ablenkung — meistens

Gehen Sie in jedes Innovationsteam in Muenchen, Wien oder Zuerich und Sie werden zwei Lager finden. Das eine schwort auf Design Thinking — Post-its, Empathy Maps und Prototyping-Labs inklusive. Das andere Lager hat still Outcome-Driven Innovation uebernommen und fragt sich, warum es Jahre damit verbracht hat, im Brainstorming-Kreis zu drehen.

Das Internet behandelt diese als konkurrierende Religionen. Das sind sie nicht. Aber die Beziehung zwischen ihnen ist nuancierter — und unausgewogener — als die diplomatische “die ergaenzen sich”-Antwort, die die meisten Berater geben.

ODI Fallstudien: Wie Grossunternehmen systematisch innovieren

Tue, 10 Mar 2026 00:00:00 +0100

Jenseits der Theorie: ODI in der Praxis

Theorie ist billig. Frameworks gibt es en masse. Was die meisten Produktverantwortlichen tatsaechlich brauchen, sind Belege — konkrete Beispiele dafuer, was passiert, wenn Outcome-Driven Innovation in der Praxis angewandt wird, in Branchen aehnlich ihren, mit der Komplexitaet und den Organisationspolitiken, denen sie taeglich begegnen.

Dieser Artikel praesentiert vier detaillierte Fallstudien zu ODI-Implementierungen in Unternehmensumgebungen. Aus Vertraulichkeitsgruenden wurden Firmennamen und einige identifizierende Details geaendert. Aber die Daten, der Prozess und die Ergebnisse sind real. Jede Fallstudie folgt derselben Struktur: die Situation vor ODI, wie der Prozess angewandt wurde, was die Daten enthuelten und was danach passierte.

ODI fuer Produktmanager: Ein praktischer Implementierungsleitfaden

Mon, 09 Mar 2026 00:00:00 +0100

Das Dilemma des Produktmanagers: Alle haben eine Meinung, niemand hat Daten

Wenn Sie Produktmanager in einem DACH-Unternehmen sind, sieht Ihr Job ungefaehr so aus: Sie sitzen zwischen der Entwicklung (die technisch interessante Dinge bauen will), dem Vertrieb (der das will, was der letzte Kunde verlangt hat), dem Marketing (das will, was gerade angesagt ist) und der Fuehrung (die Wachstum will, aber kein Risiko). Ihre Aufgabe ist es, diese konkurrierenden Inputs zu einer kohaerenten Produkt-Roadmap zu synthetisieren.

Von JTBD zu Produktanforderungen: Die Bruecke schlagen

Mon, 09 Mar 2026 00:00:00 +0100

Die gefährlichste Lücke in der Produktentwicklung

Sie haben die Forschung durchgeführt. Den Job kartiert. 130 gewünschte Outcomes erfasst, 300 Kunden befragt und 15 Outcomes mit Opportunity Scores über 12 identifiziert. Sie wissen — mit quantitativer Sicherheit — was Ihre Kunden brauchen.

Und dann passiert nichts.

Die JTBD-Erkenntnisse liegen in einem Forschungsbericht. Die Produkt-Roadmap setzt ihren vorherigen Kurs fort. Engineering arbeitet an Features, die beschlossen wurden, bevor die Forschung abgeschlossen war. Der sorgfältig erstellte JTBD Canvas hängt an der Wand — bewundert und ignoriert.

Kundengewuenschte Ergebnisse: Die Bausteine von ODI

Sun, 08 Mar 2026 00:00:00 +0100

Das Konzept, das ODI zum Funktionieren bringt

Jede Methodik hat eine Kerneinheit — das Atom, aus dem alles andere aufgebaut ist. Fuer Lean ist es Verschwendung. Fuer Six Sigma ist es Variation. Fuer Outcome-Driven Innovation ist es das kundengewuenschte Ergebnis (Desired Outcome).

Ein Desired Outcome ist die Metrik, die ein Kunde verwendet, um den Erfolg bei der Ausfuehrung eines Job-to-be-Done zu messen. Nicht das, was er kaufen moechte. Nicht das Feature, das er verlangt. Nicht das Problem, ueber das er klagt. Das Ergebnis — das spezifische, messbare Resultat, das er bei jedem Schritt des Jobs zu erreichen versucht.

Outcome-Driven Innovation: Der umfassende Leitfaden

Sat, 07 Mar 2026 00:00:00 +0100

Warum Innovation immer noch scheitert — und eine Methode nicht

Hier ist eine Zahl, die jeden Entscheider beschaeftigen sollte: Die Misserfolgsrate bei Neuprodukten liegt seit vier Jahrzehnten zwischen 72 und 90 Prozent. Milliarden in F&E-Ausgaben, Tausende von Design-Sprints, Berge von Post-its — und die Erfolgsquote hat sich kaum bewegt.

Jetzt eine andere Zahl: 86 Prozent. Das ist die Erfolgsquote von Produkten, die mithilfe von Outcome-Driven Innovation (ODI) entwickelt wurden, basierend auf dem dokumentierten Track Record der ODI-Methodik ueber mehr als 1.000 Innovationsinitiativen seit 1991.

Die Job Map: Was Kunden wirklich erreichen wollen

Thu, 05 Mar 2026 00:00:00 +0100

Was passiert wirklich, wenn Ihr Kunde Ihr Produkt einsetzt?

Diese Frage klingt einfach. Die Antwort ist es fast nie.

In meiner Arbeit mit Produktteams aus dem DACH-Raum erlebe ich regelmäßig eine verblüffende Diskrepanz: Die Ingenieure und Produktmanager kennen ihr Produkt in- und auswendig. Sie kennen seine technischen Spezifikationen, seine Stärken, seine Schwächen. Aber was der Kunde tatsächlich tut, bevor er das Produkt einsetzt, während er es einsetzt und nachdem er es eingesetzt hat — das wissen sie erstaunlich wenig.

Von Opportunity Scores zur Produkt-Roadmap

Wed, 04 Mar 2026 00:00:00 +0100

Das Problem mit Ihrer Roadmap

Ich stelle Produktmanagern gerne eine Frage: “Warum steht genau das auf Ihrer Roadmap, was dort steht?” Die Antworten sind aufschlussreich. Selten kommt die Antwort: “Weil wir quantitative Kundendaten haben, die zeigen, dass genau diese Outcomes am stärksten unterversorgt sind.” Häufig kommen Antworten wie: “Das hat der CEO priorisiert.” “Unser größter Kunde hat darum gebeten.” “Das Entwicklungsteam hatte Kapazitäten.” “Wir haben in einer Fokusgruppe das Feedback bekommen.”

Quantitative Innovationsforschung: Warum Bauchgefühl nicht reicht

Mon, 02 Mar 2026 00:00:00 +0100

Das Vertrauen in den Vertrieb

“Wir hören unsere Kunden. Unser Vertrieb spricht täglich mit ihnen.” Diese Aussage höre ich in fast jedem ersten Gespräch mit Produktleitern aus dem DACH-Raum. Sie ist gemeint als Argument dafür, dass systematische Kundenforschung nicht notwendig ist — weil man ohnehin nah am Kunden ist.

Ich widerspreche dieser Logik immer. Nicht weil der Vertrieb keine Kundennähe hat — sie ist real und wertvoll. Sondern weil das, was Vertriebsleute aus Kundengesprächen mitbringen, kein repräsentatives Bild der Kundenbedürfnisse ist. Es ist das Feedback der lautesten Kunden, der aktivsten Beschwerdeführer und der Gesprächspartner, die man gut kennt. Das ist ein systematisch verzerrtes Sample — und es ist eine bekannte, gut dokumentierte Verzerrung.

Die ODI-Marktdefinition: Warum der richtige Markt alles verändert

Sun, 01 Mar 2026 00:00:00 +0100

Der häufigste Fehler in ODI-Projekten kommt ganz am Anfang

In meiner Arbeit mit Unternehmen über zwei Jahrzehnte habe ich eine Beobachtung gemacht, die mich immer noch überrascht: Die meisten Fehler in Innovationsprojekten entstehen nicht in der Ideengenerierung, nicht in der Entwicklung und nicht in der Markteinführung. Sie entstehen in der Definition des Marktes — in den ersten Tagen eines Projekts, bevor die erste Kundenbefragung stattgefunden hat.

Eine falsche Marktdefinition führt dazu, dass alle nachfolgenden Schritte — Kundenbefragung, Opportunity-Score-Analyse, Segmentierung, Strategieentwicklung — auf einem falschen Fundament aufgebaut werden. Es ist, als würde man ein präzises Navigationssystem auf einer falschen Karte betreiben. Die Präzision ist vorhanden, aber sie navigiert in die falsche Richtung.

Agile Produktentwicklung mit Fokus auf Kundenergebnisse

Sat, 28 Feb 2026 00:00:00 +0100

Agile ist eine Antwort auf die falsche Frage

Seit den frühen 2000er Jahren hat sich Agile als Standard in der Softwareentwicklung etabliert — und in den letzten Jahren auch in der physischen Produktentwicklung. Die Versprechen: schnellere Lieferung, bessere Anpassungsfähigkeit, engere Kundennähe.

Viele dieser Versprechen halten. Agile Teams liefern schneller als Wasserfall-Teams. Sie reagieren flexibler auf Veränderungen. Und durch regelmäßige Review-Zyklen entstehen tatsächlich kürzere Feedback-Schleifen.

Aber Agile beantwortet eine falsche Frage. Die Frage, die Agile beantwortet, lautet: “Wie entwickeln wir schnell und anpassungsfähig?” Die Frage, die für Innovationserfolg entscheidend ist, lautet: “Was sollen wir entwickeln — und wie wissen wir, dass es das Richtige ist?”