Über 100 Begriffe aus Agile, Scrum, Kanban, OKR, Design Thinking, Lean Startup und Business Model Innovation – mit Definitionen, Autoren, Beispielen und Querverweisen.
Iteratives Framework für komplexe Produktentwicklung mit festen Rollen, Events und Artefakten.
Bei komplexen Projekten mit unklaren Anforderungen.
Empirische Prozesskontrolle durch Transparenz, Inspektion und Adaption.
Ken Schwaber & Jeff Sutherland, 1995. Scrum Guide.
Software-Team arbeitet in 2-Wochen-Sprints, liefert jede Iteration ein funktionierendes Inkrement.
Feste Timebox von 1-4 Wochen für ein potenziell auslieferbares Produktinkrement.
Immer wenn regelmäßige Lieferzyklen gebraucht werden.
Rhythmus schafft Vorhersehbarkeit. Keine Scope-Änderungen während des Sprints.
Scrum Guide. Begriff aus Rugby.
2-Wochen-Sprint: Montag Planning, täglich Daily, letzter Tag Review + Retro.
Verantwortlich für Maximierung des Produktwerts durch Backlog-Management.
In jedem Scrum-Team. Eine Person mit Entscheidungsbefugnis.
'Was' wird gebaut, nicht 'Wie'. Einzige Quelle für Anforderungen.
Scrum Guide. Inspiriert von Chief Engineer bei Toyota.
PO entscheidet: Feature A vor Feature B, weil Kundenfeedback höher priorisiert.
Servant Leader, der das Team bei Scrum-Anwendung unterstützt und Hindernisse beseitigt.
In jedem Scrum-Team. Besonders wichtig bei Scrum-Einführung.
Enabler, nicht Manager. Schützt Team und fördert Selbstorganisation.
Scrum Guide. Servant Leadership von Robert Greenleaf (1970).
SM erkennt Abhängigkeits-Blockade und organisiert teamübergreifendes Meeting.
Priorisierte Liste aller bekannten Anforderungen – die einzige Quelle für Arbeit.
Immer. Lebendes Dokument, das sich mit jedem Sprint weiterentwickelt.
DEEP: Detailed appropriately, Estimated, Emergent, Prioritized.
Scrum Guide. DEEP-Akronym von Roman Pichler.
Top: detaillierte User Stories. Unten: grobe Epics.
15-minütiges Sync-Event: Was getan? Was geplant? Welche Hindernisse?
Täglich, gleiche Zeit, gleicher Ort.
Synchronisation, nicht Reporting. Team organisiert sich selbst.
Scrum Guide. Auch 'Stand-up' genannt.
'Ich warte auf Code-Review' → Team klärt sofort, wer übernimmt.
Team-Reflexion: Was lief gut? Was verbessern? Welche Maßnahmen?
Am Ende jedes Sprints, vor dem nächsten Planning.
Kontinuierliche Verbesserung durch ehrliche Reflexion.
Scrum Guide. Derby & Larsen 'Agile Retrospectives' (2006).
Sailboat-Format: Wind (treibt an), Anker (hält zurück), Felsen (Risiken).
Inspektion des Produktinkrements mit Stakeholdern – Demo, Feedback, Backlog-Anpassung.
Am Ende jedes Sprints, vor der Retrospektive.
Keine PowerPoint-Show, sondern funktionierende Software zeigen.
Scrum Guide. Max. 4 Stunden bei 4-Wochen-Sprint.
Kunden testen neue Suchfunktion live. Feedback: 'Filter fehlt' → neues Item.
Anforderung aus Nutzersicht: 'Als [Rolle] möchte ich [Funktion], um [Nutzen]'.
Für Product Backlog Items. Hält Anforderungen verständlich.
INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Kent Beck (XP). INVEST von Bill Wake (2003).
'Als Kunde möchte ich nach Preis filtern, um schneller passende Produkte zu finden.'
Gemeinsames Qualitätsverständnis: Wann ist ein Backlog-Item wirklich fertig?
Immer. Sichtbar aufhängen, bei jedem Item prüfen.
Transparenz über Qualität. Verhindert 'fast fertig'.
Scrum Guide. Unterschied zu Acceptance Criteria.
DoD: Code reviewed, Tests geschrieben, Dokumentation aktuell, deployed.
Spezifische Bedingungen, damit eine User Story als abgeschlossen gilt.
Für jede User Story. Definiert Scope und ermöglicht Testbarkeit.
Given-When-Then Format für klare, testbare Kriterien.
BDD, Dan North (2003). Gherkin-Syntax.
Given: eingeloggt. When: Filter 0-50€. Then: nur Produkte unter 50€.
Durchschnittliche Story Points pro Sprint – für Prognosen, nicht Vergleich.
Zur Sprint-Planung und Release-Prognose. Nicht als Leistungsmaß!
Diagnose-Tool, keine Zielvorgabe.
Extreme Programming (Kent Beck). Alternative: Throughput.
Durchschnitt 25 Points/Sprint → 100 Points Backlog ≈ 4 Sprints.
Relative Schätzeinheit für Aufwand/Komplexität – abstrakt, nicht in Stunden.
Beim Planning Poker. Fibonacci-Reihe (1,2,3,5,8,13...).
Relativ, nicht absolut. 'Doppelt so komplex wie Story X'.
Ron Jeffries (XP). Planning Poker von Mike Cohn (2002).
Referenz-Story = 2 Points. Neue Story doppelt komplex → 5 Points.
Summe aller fertigen Items am Sprint-Ende – muss 'Done' und auslieferbar sein.
Jeder Sprint produziert ein Increment.
Additiv zu allen vorherigen Increments. Immer funktionsfähig.
Scrum Guide.
Sprint 1: Login. Sprint 2: Login + Suche. Sprint 3: Login + Suche + Filter.
Große User Story, zu groß für einen Sprint – wird später zerlegt.
Für grobe Features im Backlog-unten.
Hierarchie: Epic → Features → User Stories → Tasks.
Agile Community. Story Mapping von Jeff Patton (2014).
Epic: 'Bezahlsystem' → Stories: Kreditkarte, PayPal, Rechnung.
Regelmäßige Backlog-Pflege: Items klären, schätzen, priorisieren, zerteilen.
Wöchentlich, max. 10% Sprint-Kapazität.
Just-in-time Detaillierung. Top-Items fein, Bottom-Items grob.
Scrum Guide. Umbenannt von 'Grooming' (2013).
PO stellt Epic vor, Team stellt Fragen, zerlegt in Stories, schätzt.
Grafische Darstellung verbleibender Arbeit über Zeit.
Sprint Burndown kurzfristig, Release Burndown langfristig.
Ideallinie vs. Ist-Linie zeigt Abweichungen früh an.
Ken Schwaber. Alternative: Burnup Chart.
Tag 5: Ideallinie 50% fertig, Ist-Linie 30% → frühe Warnung.
Grundlagendokument von 2001 mit 4 Werten und 12 Prinzipien.
Als Leitbild und Referenz für alle agilen Frameworks.
'Items on the right have value, but we value items on the left more.'
17 Autoren, Snowbird Utah, Februar 2001.
4 Werte: Individuen > Prozesse, Software > Doku, Zusammenarbeit > Verträge, Reagieren > Planen.
Feste maximale Zeitdauer für Aktivität – wenn Zeit um, stoppt man.
Für alle Scrum Events: Sprint, Daily (15 Min), Retro.
Zeit fixiert, Scope variabel. Zwingt zu Fokus.
Pomodoro-Technik (Cirillo, 1980er).
Design Sprint: 5 Tage timeboxt für Problem→Prototyp→Test.
Pull-basiertes Workflow-System mit Visualisierung, WIP-Limits und kontinuierlicher Verbesserung.
Bei kontinuierlichem Arbeitsfluss ohne feste Iterationen.
'Stop starting, start finishing.' Begrenze parallele Arbeit.
Toyota Production System (1940er). David Anderson (2007).
Support-Team: Tickets fließen von 'Neu' über 'In Arbeit' (max 3) zu 'Erledigt'.
Maximale Anzahl gleichzeitiger Aufgaben pro Spalte – verhindert Überlastung.
Immer! Wichtigstes Kanban-Element.
Little's Law: Weniger parallele Arbeit = schnellere Durchlaufzeit.
Toyota Production System. David Anderson.
Spalte 'In Entwicklung' WIP-Limit 3: Erst wenn eins fertig, kommt neues rein.
Gesamtzeit von Kundenanfrage bis Lieferung – inklusive Wartezeiten.
Zur Service Level Expectation, für Prognosen.
Lead Time = Cycle Time + Wartezeit. Oft 80% Warten!
Manufacturing/Lean.
Ticket erstellt Montag, erledigt Freitag = 5 Tage Lead Time.
Zeit von Arbeitsbeginn bis Fertigstellung – tatsächliche Bearbeitungszeit.
Zur Prozessoptimierung.
Startet bei 'In Arbeit', endet bei 'Done'. Teil der Lead Time.
Manufacturing, adaptiert für Kanban/DevOps.
Ticket 'In Progress' Di 9:00, 'Done' Di 15:00 = 6 Std Cycle Time.
Zustand optimalen, kontinuierlichen Arbeitsflusses ohne Unterbrechungen.
Flow ist das Ziel! Optimiere WIP-Limits bis Flow entsteht.
Flow Efficiency = Wertschöpfungszeit / Lead Time. Oft nur 5-15%!
Lean Manufacturing. Csikszentmihalyi für psychologischen Flow.
Gut: Items fließen gleichmäßig. Schlecht: Items stauen sich vor 'Review'.
Arbeit wird gezogen wenn Kapazität frei ist – nicht geschoben.
In Kanban fundamental. Gegenteil von Push.
Verhindert Überlastung. WIP-Limits machen Pull sichtbar.
Toyota Production System.
Entwickler fertig → zieht nächstes Ticket selbst.
Anzahl abgeschlossener Items pro Zeiteinheit.
Alternative zu Velocity/Story Points. Einfacher zu messen.
Little's Law: Throughput = WIP / Lead Time.
Queuing Theory. NoEstimates-Bewegung.
Team schließt 15 Tickets pro Woche ab = Throughput 15/Woche.
Engpass im Workflow – langsamste Stelle bestimmt Tempo.
Identifizieren und auflösen = höchster Hebel.
Theory of Constraints: Optimiere nur den Bottleneck.
Eliyahu Goldratt 'The Goal' (1984).
10 Entwickler, 1 Tester → Tester ist Bottleneck. Mehr Devs hilft nicht!
Visuelle Workflow-Darstellung mit Spalten für jeden Prozessschritt.
Immer. Physisch oder digital (Jira, Trello).
Visualisiere die Arbeit. WIP-Limits pro Spalte.
Toyota 'Kanban' = Signalkarte.
Spalten: Backlog → Analyse → Development → Review → Done.
Fundamentales Gesetz: Lead Time = WIP / Throughput.
Zur Argumentation für WIP-Limits. Mathematisch beweisbar!
L = λW (Warteschlangentheorie).
John Little (MIT), 1961.
10 Items WIP, 2 Items/Tag Throughput = 5 Tage Lead Time.
Japanisch für 'Veränderung zum Besseren' – kontinuierliche Verbesserung.
Immer. Kleine tägliche Verbesserungen.
1% besser jeden Tag = 37x besser nach einem Jahr.
Toyota. Masaaki Imai 'Kaizen' (1986).
Retro-Ergebnis: 'Meeting-Einladungen einen Tag früher'.
Visualisierung von WIP, Lead Time und Throughput über Zeit.
Für Kanban-Teams. Mächtiger als Burndown.
Horizontaler Abstand = Lead Time, vertikaler = WIP, Steigung = Throughput.
Statistical Process Control. David Anderson.
Bänder werden breiter = WIP steigt = Problem.
Hindernis, das Weiterarbeit verhindert – muss sofort adressiert werden.
Im Daily nennen, auf Board markieren (rotes Flag).
Blocker lösen hat höchste Priorität.
Scrum (Impediment) und Kanban.
'Warte auf API-Zugang vom Partner' – Team kann nicht weitermachen.
Prognose wie lange Items typischerweise dauern.
Statt fester Deadlines. Basiert auf historischen Daten.
Probabilistisch statt deterministisch.
Kanban Guide (2020).
'85% der Items in unter 10 Tagen.'
Zielmanagement: Qualitative Ziele (Objectives) mit messbaren Ergebnissen (Key Results).
Für strategische Fokussierung. Quartalsweise.
Fokus durch Priorisierung. Max. 3-5 Objectives.
Andy Grove (Intel, 1970er). John Doerr, Google (1999).
O: Marktführer im DACH-Raum werden. KR1: 10.000 Neukunden. KR2: NPS 50+.
Qualitatives, inspirierendes Ziel – beschreibt WAS erreicht werden soll.
Für Fokus und Richtung. Keine Zahlen!
Beginnt mit Verben: 'Werden', 'Etablieren', 'Transformieren'.
Andy Grove (Intel).
Gut: 'Das beste Onboarding der Branche schaffen'. Schlecht: '10% mehr Nutzer'.
Messbare Ergebnisse, die zeigen ob Objective erreicht wurde.
3-5 pro Objective. Outcome-fokussiert, nicht Output.
Binär prüfbar: Am Quartalsende klar ob erreicht.
Andy Grove.
Gut: 'NPS von 40 auf 55'. Schlecht: 'Feedback-Prozess verbessern'.
Vertikale und horizontale Zielabstimmung – alle ziehen am gleichen Strang.
Im OKR-Planning. Vertikal und horizontal abstimmen.
60% Bottom-up, 40% Top-down.
OKR-Methodik.
Company: 'Beste Customer Experience'. Marketing + Produkt + Support alignen darauf.
Extrem ambitioniertes Stretch Goal – 70% Erreichung gilt als Erfolg.
Für transformative Ziele. Nicht für Must-haves.
'Shoot for the moon – even if you miss, you land among the stars.'
Google OKR-Kultur. JFK Mondlandung (1961).
Moonshot: '10x Wachstum'. Roofshot: '20% Wachstum'.
Realistisches Committed Goal – 100% Erreichung erwartet.
Für verbindliche Ziele die nicht verfehlt werden dürfen.
Balance mit Moonshots.
Google OKR-Terminologie.
'99,9% Uptime aufrechterhalten' – kein Stretch, sondern Pflicht.
Wöchentlicher OKR-Review: Confidence aktualisieren, Blocker identifizieren.
Jede Woche, 15-30 Min.
Ampel-System: Rot/Gelb/Grün für jeden Key Result.
OKR Best Practice.
'KR2 ist gelb – Confidence 60%. Plan: User-Interviews nachholen.'
Subjektive Einschätzung (0-100%) wie wahrscheinlich Key Result erreicht wird.
Im Weekly Check-in. Startet bei ca. 50% (Moonshot).
Sinkendes Confidence = Handlungsbedarf.
OKR Best Practice.
KR '100 Neukunden': Woche 4 bei 30, aber Confidence 70% weil Pipeline gut.
Conversations, Feedback, Recognition – Begleitprozess zu OKRs.
Kontinuierlich. Ersetzt Jahresgespräche.
OKRs allein reichen nicht – Menschen brauchen Dialog.
John Doerr 'Measure What Matters' (2018).
C: 1:1s alle 2 Wochen. F: Peer-Feedback. R: Shoutouts im Team.
Key Performance Indicator – Kennzahl zur Messung von Leistung.
KPI: laufende Messung. Key Result: Zielwert für Zeitraum.
Was gemessen wird, wird gemanaged.
Balanced Scorecard (Kaplan & Norton, 1992).
KPI: 'Aktueller NPS = 42'. KR: 'NPS von 42 auf 55 bis Q3.'
Ergebnis/Wirkung – nicht die Aktivität selbst (Output).
Output: Feature gebaut. Outcome: Nutzer lösen Problem schneller.
'Focus on outcomes, not outputs.'
Outcome-Driven Innovation (Ulwick). Marty Cagan.
Output: 50 Features. Outcome: Conversion 2%→4%.
Management by Objectives – klassisches Zielvereinbarungs-System.
MBO: jährlich, Top-down, Bonus-gekoppelt. OKR: quartalsweise.
SMART-Ziele.
Peter Drucker 'The Practice of Management' (1954).
MBO: '15% Umsatzsteigerung für Jahresbonus'.
Nutzerzentrierter Innovationsansatz: Empathize, Define, Ideate, Prototype, Test.
Für komplexe Probleme mit unklaren Anforderungen.
Fail early, fail often. Iterativ, nicht linear.
Stanford d.school, David Kelley, IDEO (1991).
Krankenhaus: Mitarbeiter erleben Patientenperspektive → neue Lösungen.
Prozessmodell: Divergent-konvergent für Problem UND Lösung.
Zur Strukturierung von Innovationsprojekten.
Diamant 1: Problem finden. Diamant 2: Lösung finden.
British Design Council (2005).
Links: Research → Problem. Rechts: Ideen → Lösung.
Visualisierung von Nutzerperspektive: Says, Thinks, Does, Feels.
Nach User Research, vor Ideation.
Hypothesen über innere Welt des Nutzers.
XPLANE. Dave Gray 'Gamestorming' (2010).
4 Quadranten ausfüllen: Was sagt, denkt, tut, fühlt der Nutzer?
Frageformat: 'Wie könnten wir [Problem] für [Nutzer] lösen?'
Zwischen Define und Ideate. Öffnet Lösungsraum.
'How' = optimistisch. 'Might' = offen. 'We' = kollaborativ.
Procter & Gamble (Min Basadur). IDEO.
'Wie könnten wir Wartezeiten weniger stressig machen?'
Schnelle, günstige Umsetzung einer Idee zum Testen.
So früh wie möglich. Lieber 10 schnelle als 1 perfekten.
'A prototype is worth 1000 meetings.'
Design Thinking, IDEO.
Papier-Mockup einer App in 15 Min → sofort testen.
Fiktiver, repräsentativer Nutzertyp basierend auf Forschung.
Nach User Research. Macht abstrakte Nutzergruppe greifbar.
Name, Foto, Ziele, Frustrationen.
Alan Cooper 'The Inmates Are Running the Asylum' (1999).
Maria, 42, Projektleiterin: Will Überblick, hasst komplexe Tools.
Erste Design Thinking Phase: Nutzer verstehen durch Beobachtung.
Immer am Anfang. Bevor Lösungen gedacht werden.
Zuhören, beobachten, eintauchen. Keine Annahmen.
Stanford d.school.
Einen Tag als Patient im Krankenhaus verbringen.
Kreative Phase zur Generierung vieler Ideen – Quantität vor Qualität.
Nach Problemdefinition, vor Prototyping.
'Yes, and...' statt 'Yes, but...'. Wilde Ideen ermutigen.
Design Thinking. Brainstorming (Alex Osborn, 1953).
100 Ideen in 30 Minuten. Dot-Voting für Favoriten.
Denkmodus: Möglichkeiten öffnen, viele Optionen generieren.
In Ideation und Research. Gegenteil: Convergent Thinking.
Erst divergieren (öffnen), dann konvergieren (fokussieren).
J.P. Guilford (1967). Double Diamond.
'Was wäre wenn...?' Keine Kritik. Aufbauen statt abschießen.
Fokussiertes Problemstatement: [Nutzer] braucht [Bedürfnis] weil [Insight].
Zwischen Empathize und Ideate. Definiert das Problem.
Aktionsorientiert. Spezifisch und breit genug.
Stanford d.school.
'Maria braucht schnellen Projektstatus, weil sie 8 Meetings/Tag hat.'
Tiefe Erkenntnis über Zusammenhänge – mehr als Information.
Als Ergebnis von Research. Basis für Entscheidungen.
Insight = Information + Interpretation + Implikation.
Research/Analytics.
'Nutzer brechen ab weil Form zu lang' → 'Einfachheit > Vollständigkeit'.
Zentraler Lean Startup Zyklus: Bauen, Messen, Lernen.
Für jede Produktiteration. Schnellste Schleife gewinnt.
Minimiere die Zykluszeit. Validiertes Lernen ist das Ziel.
Eric Ries 'The Lean Startup' (2011).
MVP bauen → Conversion messen → Hypothese bestätigt/widerlegt.
Minimum Viable Product – kleinste Version um zu testen und zu lernen.
So früh wie möglich. Nicht perfekt, nur lernfähig.
Was ist das Minimum, um diese Annahme zu testen?
Eric Ries. Frank Robinson (2001).
Dropbox: Nur ein Video → 70.000 Anmeldungen über Nacht.
Durch Experimente bestätigte Erkenntnisse – nicht Meinungen.
Nach jedem Experiment. Was haben wir mit Daten gelernt?
Lernen ist das Produkt. Features sind Mittel zum Zweck.
Eric Ries.
'Wir glaubten X' → 'Wir haben getestet und gelernt: Y (mit Daten)'.
Strategische Richtungsänderung basierend auf Erkenntnissen.
Wenn Hypothesen widerlegt werden und Kurskorrektur nötig.
Pivot ist kein Scheitern, sondern Lernen in Aktion.
Eric Ries. 10 Pivot-Typen.
YouTube: Video-Dating → Video-Sharing. Instagram: Check-in → Fotos.
Testbare Annahme über Nutzer, Problem oder Lösung.
Vor jedem Experiment. Macht Annahmen explizit.
'Wir glauben, dass [X] weil [Y]. Wir testen durch [Z].'
Wissenschaftliche Methode, für Startups.
'Nutzer zahlen für Feature X.' Test: Landing Page mit Preorder.
Strukturierter Test einer Hypothese mit klaren Erfolgskriterien.
Für jede wichtige Annahme. Vor großen Investitionen.
Cheapest, fastest way to learn.
Lean Startup, Scientific Method.
A/B-Test, Smoke Test, Concierge, Wizard of Oz, Landing Page.
Manuell erbrachter Service, der später automatisiert wird.
Wenn Automatisierung zu teuer/riskant ist.
Things that don't scale. Manuell ist OK fürs Lernen.
Eric Ries.
Food Pail lieferte Essen manuell per Fahrrad bevor App gebaut wurde.
Produkt wirkt automatisiert, ist aber manuell betrieben.
Um Nachfrage zu testen bevor Technologie gebaut wird.
Fake it till you make it. Lernen vor Bauen.
Nach 'Zauberer von Oz' (Mann hinter dem Vorhang).
Zappos: Fotos online, manuell im Laden kaufen.
Test mit Fake-Produkt (Landing Page, Button) um Nachfrage zu messen.
Vor dem Bauen. Misst Interesse ohne echtes Produkt.
Messen ob Leute klicken würden, nicht ob sie es sagen.
Hardware-Testing adaptiert.
Landing Page mit 'Kaufen'-Button → misst Klicks, Produkt existiert nicht.
Zustand wo Produkt echtes Kundenbedürfnis befriedigt.
Vor Skalierung prüfen. Ohne PMF ist Wachstum Geldverbrennung.
Marc Andreessen: 'You'll feel it when you have it.'
Marc Andreessen (2007). Sean Ellis 40%-Test.
'40%+ wären sehr enttäuscht wenn Produkt weg wäre.'
Framework um Innovationsfortschritt zu messen – nicht klassische KPIs.
Für Startups und Innovationsprojekte.
Actionable Metrics statt Vanity Metrics.
Eric Ries.
Nicht 'Downloads' (Vanity) sondern 'Activation Rate' (Actionable).
Ein Durchlauf des Build-Measure-Learn Zyklus.
Kontinuierlich. Jede Iteration bringt Lernen.
Schnelle Iterationen schlagen perfekte Pläne.
Agile/Lean.
MVP v1 → lernen → v2 → lernen → v3 oder Pivot.
Strategisches Tool mit 9 Feldern zur Visualisierung von Geschäftsmodellen.
Für neue Geschäftsmodelle, Pivots, Analyse.
Alle 9 Bausteine müssen zusammenpassen.
Osterwalder & Pigneur 'Business Model Generation' (2010).
9 Felder: Value Prop, Segments, Channels, Relationships, Revenue, Resources, Activities, Partners, Costs.
Detaillierte Analyse von Kundennutzen: Customer Profile + Value Map.
Zur Schärfung der Value Proposition.
Fit zwischen Jobs/Pains/Gains und Products/Relievers/Creators.
Osterwalder 'Value Proposition Design' (2014).
Links: Was will Kunde? Rechts: Was bieten wir? → Fit herstellen.
Framework: Kunden 'heuern' Produkte um einen Job zu erledigen.
Für Produktentwicklung. Versteht wahre Kaufmotivation.
'People don't want a drill, they want a hole.'
Clayton Christensen 'Competing Against Luck' (2016).
McDonald's Milkshake: 'Job' = Beschäftigung für langweilige Fahrt.
Startup-Variante des BMC: Problem, Solution, Metrics, Unfair Advantage.
Für Startups. Fokus auf Risiken und Hypothesen.
Felder sind Hypothesen zum Testen.
Ash Maurya 'Running Lean' (2012).
Statt 'Partners' → 'Problem'. Statt 'Relationships' → 'Unfair Advantage'.
BMC-Feld: Verschiedene Kundengruppen mit unterschiedlichen Bedürfnissen.
Bei Business Model Design. Basis für alles andere.
Unterschiedliche Segmente = unterschiedliche Value Propositions.
Business Model Canvas.
B2B vs. B2C, Early Adopters vs. Mainstream, Freemium vs. Premium.
BMC-Feld: Warum sollten Kunden bei uns kaufen?
Kern des Geschäftsmodells. Muss klar und differenzierend sein.
Quantifiable, Differentiating, Primary.
Business Model Canvas. Michael Lanning (1988).
Uber: 'Push a button, get a ride.'
BMC-Feld: Wie erreichen wir Kunden und liefern Value Proposition?
Zur Planung von Vertrieb, Marketing, Delivery.
5 Phasen: Awareness, Evaluation, Purchase, Delivery, After Sales.
Business Model Canvas.
Direkt (Webshop) vs. Indirekt (Händler). Online vs. Offline.
BMC-Feld: Wie und wofür zahlen Kunden?
Bei Monetarisierungsstrategie.
Transaktional vs. Recurring. Asset Sale, Subscription, etc.
Business Model Canvas.
Freemium: Basis kostenlos, Premium kostenpflichtig.
BMC-Feld: Welche Assets sind für unser Geschäftsmodell unverzichtbar?
Zur Identifikation kritischer Ressourcen.
Physical, Intellectual, Human, Financial.
Business Model Canvas.
Google: Algorithmus + Rechenzentren. IKEA: Design + Logistik.
BMC-Feld: Welche Tätigkeiten sind für unser Geschäftsmodell unverzichtbar?
Zur Fokussierung auf das Wesentliche.
Production, Problem Solving, Platform/Network.
Business Model Canvas.
Consulting: Problem Solving. Amazon: Logistics. Facebook: Platform.
BMC-Feld: Strategische Partnerschaften die Geschäftsmodell ermöglichen.
Zur Optimierung, Risikoreduktion.
Make or Buy? Was können Partner besser?
Business Model Canvas.
Apple + Foxconn. Spotify + Labels.
BMC-Feld: Welche Kosten entstehen durch das Geschäftsmodell?
Zur Wirtschaftlichkeitsanalyse.
Fixed vs. Variable. Cost-driven vs. Value-driven.
Business Model Canvas.
Ryanair: Cost-driven. Apple: Value-driven.
Preismodell: Basisversion kostenlos, Premium-Features kostenpflichtig.
Für digitale Produkte mit geringen Grenzkosten.
Conversion Rate kritisch: 2-5% typisch.
Fred Wilson (2006). Spotify, Dropbox.
Spotify: Werbefinanziert kostenlos, Premium ohne Werbung + Offline.
Preismodell: Regelmäßige Zahlung für kontinuierlichen Zugang.
Für wiederkehrende Nutzung. Vorhersehbare Einnahmen.
MRR/ARR als Metric. Churn ist kritisch. LTV > CAC.
Tien Tzuo 'Subscribed'.
Netflix, Adobe Creative Cloud, Dollar Shave Club.
Geschäftsmodell das Wert durch Vermittlung zwischen Gruppen schafft.
Bei mehrseitigen Märkten. Network Effects sind Schlüssel.
Plattform besitzt nicht, sondern verbindet.
Parker, Van Alstyne, Choudary 'Platform Revolution' (2016).
Uber, Airbnb, Amazon Marketplace.
Produkt wird wertvoller je mehr Nutzer es hat.
Für Plattformen. Winner-takes-all Dynamik.
Direct vs. Indirect Network Effects.
Robert Metcalfe (Metcalfe's Law).
Facebook: Mehr Freunde → mehr Wert. Uber: Mehr Fahrer → kürzere Wartezeit.
Erste Kundengruppe die neues Produkt akzeptiert – risikobereit.
Für Produktlaunch und MVP-Testing.
2,5% der Bevölkerung (Rogers). Brücke zum Mainstream.
Everett Rogers 'Diffusion of Innovations' (1962).
Tech-Enthusiasten die Beta-Versionen trotz Bugs nutzen.
VPC-Element: Negative Erfahrungen und Hindernisse des Kunden.
Bei Value Proposition Design. Was vermeiden?
Funktionale, emotionale, soziale Pains.
Value Proposition Canvas.
Zeitverschwendung, hohe Kosten, Unsicherheit.
VPC-Element: Positive Ergebnisse die der Kunde anstrebt.
Bei Value Proposition Design. Was erreichen?
Required, Expected, Desired, Unexpected Gains.
Value Proposition Canvas.
Zeitersparnis, Kostensenkung, Anerkennung.
Strategie-Framework: Aspiration, Where, How, Capabilities, Systems.
Für strategische Planung auf Unternehmens- oder Produktebene.
Strategie = integrierte Wahl-Kaskade.
Lafley & Martin 'Playing to Win' (2013). P&G.
1. Winning Aspiration → 2. Where to Play → 3. How to Win → 4. Capabilities → 5. Systems.
Strategische Entscheidung: In welchen Märkten konkurrieren?
Bei Strategiedefinition. Fokus > Breite.
Bewusste Entscheidung wo man NICHT spielen wird.
Playing to Win.
Apple: Premium-Segment. Wenige Produktkategorien, aber führend.
Strategische Entscheidung: Wie gewinnen wir in den gewählten Märkten?
Nach Where to Play. Differenzierung oder Kostenführerschaft.
Must be different OR cheaper. Stuck in the middle = lose.
Playing to Win. Michael Porter.
Cost Leadership (Walmart) vs. Differentiation (Apple).
Erstes Playing-to-Win-Element: Was bedeutet 'Gewinnen' für uns?
Am Anfang der Strategiearbeit.
Play to play ≠ Play to win.
Playing to Win.
'Führender Anbieter für X in DACH' vs. 'Profitabel sein'.
Playing-to-Win-Element: Welche Fähigkeiten brauchen wir?
Nach How to Win. Welche aufbauen/stärken?
Activity System: Capabilities verstärken sich gegenseitig.
Playing to Win.
P&G: Consumer Understanding, Brand Building, Go-to-Market, Innovation, Scale.
Playing-to-Win-Element: Welche Systeme unterstützen die Strategie?
Zur Strategieumsetzung. Strukturen, Prozesse, Metriken.
Strategy must be supported by structure.
Playing to Win.
OKRs, Reporting-Struktur, Meeting-Rhythmen, Incentive-Systeme.
Framework: Strengths, Weaknesses, Opportunities, Threats.
Für strategische Bestandsaufnahme.
SO: nutzen. WO: überwinden. ST: verteidigen. WT: vermeiden.
Albert Humphrey, Stanford (1960er).
Intern: Was gut/schlecht? Extern: Was kommt auf uns zu?
Kommunikationsmodell: Why → How → What. Von innen nach außen.
Für Purpose-Definition, Markenpositionierung.
'People don't buy what you do, they buy why you do it.'
Simon Sinek 'Start with Why' (2009).
Apple: Why (Challenge status quo) → How (Beautiful design) → What (Computers).
Fundamentaler Daseinszweck eines Unternehmens – das 'Warum'.
Als Nordstern für alle Entscheidungen.
Purpose-driven companies outperform.
Simon Sinek. Jim Collins 'Built to Last'.
Patagonia: 'We're in business to save our home planet.'
Strategischer Ansatz: Einzigartig sein, Preispremium rechtfertigen.
Alternative zu Kostenführerschaft.
Be different, not just better. Blue Ocean statt Red Ocean.
Michael Porter 'Competitive Advantage' (1985).
Apple: Design + Ecosystem. Tesla: Tech + Brand.
Wechselkosten die Kunden an Anbieter binden.
Zur Kundenbindungsstrategie.
Gut: Kunden bleiben wegen Value. Schlecht: Kunden gefangen.
Michael Porter (Switching Costs).
Apple Ecosystem. SAP (Implementierungsaufwand).
Systeme mit vielen, vernetzten, dynamischen Elementen – nicht vorhersagbar.
Zur Einordnung von Problemen. Komplex ≠ kompliziert.
Cynefin: Simple → Complicated → Complex → Chaotic.
Dave Snowden (Cynefin, 2007).
Kompliziert: Uhr reparieren. Komplex: Markt verstehen.
Entstehung neuer Eigenschaften auf Systemebene.
Zum Verständnis komplexer Systeme. Ganzes > Summe.
Emergente Eigenschaften aus Teilen nicht vorhersagbar.
Systems Theory. Santa Fe Institute.
Bewusstsein aus Neuronen. Stau aus Autos. Kultur aus Menschen.
Volatile, Uncertain, Complex, Ambiguous – turbulente Umwelt.
Zur Begründung für agile Ansätze.
VUCA-Prime: Vision, Understanding, Clarity, Agility.
US Army War College (1990er).
COVID-19 zeigte VUCA: Volatilität, Unsicherheit, Komplexität.
Komplexes Problem ohne eindeutige Lösung.
Zur Problemkategorisierung. Wicked ≠ schwierig.
Jeder Lösungsversuch verändert das Problem.
Horst Rittel & Melvin Webber (1973).
Klimawandel, Armut, Organisationskultur.
Vernetzte Elemente mit Beziehungen und gemeinsamem Zweck.
Zur ganzheitlichen Problemanalyse.
Systemgrenzen sind Konstrukte. Feedback Loops zentral.
Ludwig von Bertalanffy (1968). Donella Meadows.
Organisation = System aus Menschen, Prozessen, Technologie, Kultur.
Rückkopplungsschleife: Output beeinflusst Input.
Zum Verständnis von Systemdynamik.
Reinforcing Loop (exponentiell) vs. Balancing Loop (stabilisierend).
Norbert Wiener (Cybernetics).
Mehr Nutzer → mehr Content → mehr Nutzer. Thermostat (dämpfend).
Methode, neue Produkte und Geschäftsmodelle unter Unsicherheit zu entwickeln: Annahmen als Hypothesen formulieren, schnell testen, aus Evidenz entscheiden.
Wenn nicht klar ist, ob Kunden ein Problem wirklich haben und dafür zahlen würden.
Build-Measure-Learn: kleinste testbare Version bauen, messen, lernen – und erst dann skalieren oder pivotieren.
Eric Ries, „The Lean Startup“ (2011), aufbauend auf Steve Blanks Customer Development.
Ein Mittelständler testet ein Service-Angebot mit einer Landingpage und 20 Kundengesprächen, bevor er ein Team dafür aufbaut.
Systematischer Katalog von Experimenten, mit denen sich die riskantesten Annahmen einer Geschäftsidee prüfen lassen – von Interviews bis Pre-Sales.
Wenn ein Business Model Canvas steht und die Frage ist, welche Annahme zuerst geprüft werden muss.
Erst die Annahme mit dem höchsten Risiko testen; billige Experimente vor teuren; Evidenz statt Meinung.
David J. Bland & Alex Osterwalder, „Testing Business Ideas“ (2019), 44 Experimenttypen.
Statt eines Prototyps zuerst eine Fake-Door-Anzeige schalten: Klickrate zeigt, ob überhaupt Interesse besteht.
Arbeitsweise, bei der ein Produkt in wiederholten Zyklen (iterativ) entsteht und mit jedem Zyklus nutzbar wächst (inkrementell).
Immer wenn Anforderungen unsicher sind und frühes Feedback wertvoller ist als ein vollständiger Plan.
Jede Iteration liefert ein Inkrement, das echtes Feedback erzeugt – die Richtung wird laufend korrigiert, nicht am Ende.
Evolutionäre Softwareentwicklung (1970er), Grundlage aller agilen Frameworks.
Nicht erst nach zwölf Monaten das fertige Portal, sondern nach vier Wochen die Anmeldung, nach acht die Suche – jeweils mit Nutzern getestet.
Haltung und Arbeitsweise, Entscheidungen konsequent vom Problem des Kunden her zu treffen – nicht von der eigenen Lösung.
Wenn Produkte an Kundenbedürfnissen vorbeientwickelt werden oder interne Perspektiven dominieren.
Erst das Problem verstehen, dann die Lösung bauen; Kundenkontakt ist Teil der Arbeit, nicht Aufgabe des Vertriebs.
Design Thinking, Jobs-to-be-Done (Christensen), Customer Development (Blank).
Das Team spricht jede Woche mit zwei Kunden und priorisiert das Backlog nach beobachteten Problemen, nicht nach Feature-Wünschen.
Modell, das Vorhaben nach Klarheit der Anforderungen und Sicherheit der Technologie einordnet – von einfach über kompliziert bis komplex und chaotisch.
Zur Entscheidung, ob ein Vorhaben planbar bearbeitet werden kann oder agil bearbeitet werden muss.
Je unklarer Was und Wie, desto weniger hilft Planung und desto mehr braucht es Experimente und Feedback.
Ralph D. Stacey (1996), populär geworden in der agilen Community.
Ein Rollout bekannter Software: kompliziert, planbar. Ein neues Geschäftsmodell mit unklarem Markt: komplex, iterativ.
Entscheidungsrahmen, der Situationen in fünf Domänen einteilt – klar, kompliziert, komplex, chaotisch, verworren – und je Domäne eine andere Vorgehensweise verlangt.
Bevor eine Methode gewählt wird: Welche Art von Problem liegt eigentlich vor?
Klar: Best Practice. Kompliziert: Analyse durch Experten. Komplex: Probieren, wahrnehmen, reagieren. Chaotisch: Handeln, dann stabilisieren.
Dave Snowden (1999, IBM), Sense-Making-Framework aus der Komplexitätsforschung.
Ein Team behandelt eine Kulturfrage wie ein Projekt (kompliziert) – und wundert sich, dass der Plan nicht greift. Cynefin zeigt: Das ist komplex.
Coaching-Ansatz, der Methoden nicht nach Lehrbuch einführt, sondern nach dem Kontext des Teams und der Organisation auswählt, anpasst – oder weglässt.
Wenn ein Framework „nach Buch“ eingeführt wurde und trotzdem nicht wirkt – oder wenn ein Team etwas anderes braucht als das Standardrezept.
Erst den Kontext lesen (Cynefin, Stacey, Reifegrad, Entscheidungsspielräume), dann die Methode wählen. Das Team ist nicht für die Methode da.
Praxis von Agile Impact; theoretisch gestützt auf Cynefin und die Unterscheidung kompliziert/komplex.
Ein Team mit klarem, wiederkehrendem Auftrag bekommt Kanban statt Scrum – nicht weil Scrum falsch wäre, sondern weil der Kontext keine Sprints braucht.
