Was vorher fertig sein muss
Mindestens fünf Gespräche mit potenziellen Zielnutzern liegen vor, aus denen Probleme und aktuelle Workarounds dokumentiert sind.
Eine formulierte JTBD-Aussage existiert oder wird in derselben Session erarbeitet, sodass Problem und Lösung am Nutzer-Job ausgerichtet sind.
Was vor Start vorliegen muss
Lean-Canvas-Vorlage als 9-Box-Raster (digital in Miro, FigJam oder als A1-Druck); Sticky Notes oder digitale Notizen; Timer; eine Farbe pro Hypothesen-Risikoklasse.
Ein Owner für das Venture (oft Product Lead oder Founder); ein Facilitator; ein bis vier weitere Personen aus Product, Engineering oder Business mit Domainwissen.
Aktueller Stand der Kundengespräche; existierende Konkurrenz-Übersicht; bekannte Constraints (Budget, Compliance, technische Plattform); falls vorhanden ein erstes JTBD-Statement.
45-90 min
Canvas auf gemeinsame Arbeitsfläche legen, Reihenfolge der Boxen markieren (1 Problem, 2 Customer Segments, 3 Unique Value Proposition, 4 Solution, 5 Channels, 6 Revenue, 7 Cost, 8 Key Metrics, 9 Unfair Advantage). Timer auf 60 min. Regel: pro Box maximal drei Sticky Notes.
Die eine Frage, die diese Methode beantwortet
Welche Annahmen über Problem, Zielgruppe und Geschäftsmodell muss das Venture als nächstes prüfen, bevor weiter investiert wird?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Problem und Customer Segments | 15 min | Maximal drei Top-Probleme der Zielnutzer notieren, jeweils mit aktuellem Workaround. Customer Segments auf eine konkrete Early-Adopter-Subgruppe verengen, nicht „alle KMU“. | Wenn das Problem ein Featurewunsch ist („braucht ein Dashboard“), ist es zu spät formuliert. Eine Stufe zurück: welche Entscheidung oder Aufgabe scheitert ohne dieses Feature. |
2Phase 2: UVP und Solution | 15 min | Unique Value Proposition in einem Satz formulieren, der das Problem-Outcome benennt, nicht das Produkt. Solution erst danach als drei Bullet Points skizzieren. | UVP zuerst, Solution zuletzt. Wer mit Solution startet, baut das Canvas um die bestehende Idee herum und verpasst Alternativen. |
3Phase 3: Channels, Revenue, Cost | 15 min | Channels auf jene reduzieren, die Early Adopter heute schon nutzen. Revenue Streams mit Preismodell und realistischer Zahlungsbereitschaft pro Segment. Cost Structure auf MVP-Phase begrenzt (nicht End-State). | Channel „SEO“ ist zu generisch. Konkret: welche Suchanfrage, welches Volumen, welche Konkurrenz auf Seite 1. |
4Phase 4: Key Metrics und Unfair Advantage | 10 min | Drei bis fünf Metriken benennen, die Fortschritt zeigen (Activation, Retention, Revenue). Unfair Advantage nur eintragen, wenn er nicht kopierbar ist; sonst Feld leer lassen. | Wenn Unfair Advantage „besseres Team“ oder „mehr Erfahrung“ lautet, ist es keiner. Leer ist ehrlicher als Phrase. |
5Phase 5: Risiko-Ranking | 10 min | Jede Box mit roter Farbe markieren, wenn Annahme unbelegt und Scheitern das Geschäftsmodell killt. Top 3 Risiken in Experiment Backlog überführen. | Häufig 5-7 rote Boxen am Anfang. Das ist normal. Ziel ist Priorisierung, nicht Vollständigkeit. |
Was am Ende rauskommt
Lean-Canvas-Datei (Bild oder strukturiertes Dokument) plus Experiment Backlog mit den Top 3 Riskiest Assumptions, je verbunden mit Validierungs-Idee, Erfolgskriterium und nächstem Owner.
Datum und Iteration im Titel (z. B. `lean-canvas-v3-2026-05-20`). Ältere Versionen behalten, nicht überschreiben. Bei jeder Iteration kurz dokumentieren, welche Annahme widerlegt oder bestätigt wurde.
Kompakte Arbeitsvorlage für Lean Canvas mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Lean Canvas Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Lean Canvas:
- Core Assumptions:
- Experiment Backlog:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Lean Canvas — InvoiceFlow (v2, 2026-05-20)
**Problem**: (1) Solo-Buchhalter verlieren 4h/Woche an manuelle Rechnungsmatching-Arbeit. (2) Fehler bei Mehrwertsteuer-Codes verursachen Nacharbeit. (3) Kein Echtzeit-Cashflow-Blick.
**Customer Segments**: Solo-Steuerberater mit 30-80 Mandanten, die DATEV nutzen.
**UVP**: Rechnungs-Matching in unter 10 Sekunden pro Beleg, direkt in DATEV exportierbar.
**Solution**: OCR-Upload, Regelbasierter Matcher, DATEV-Export.
**Channels**: Steuerberater-Foren (datev.community), Kammer-Newsletter, Empfehlung über Kanzleisoftware-Partner.
**Revenue**: 49 EUR/Monat pro Kanzlei, gestaffelt nach Belegvolumen.
**Cost**: OCR-API (~0,02 EUR/Beleg), Hosting (~200 EUR/Mo), 1 FTE Dev.
**Key Metrics**: Belege/Woche pro aktiver Kanzlei, Matching-Genauigkeit, MRR.
**Unfair Advantage**: (leer, noch keiner identifiziert).
**Top-Risiken**: Zahlungsbereitschaft 49 EUR (unbelegt), DATEV-Export-Komplexität (technisch unklar), Kammer als Channel (nicht getestet).Symptome erkennen, gegensteuern
Boxen werden ausgefüllt, ohne Risiko-Markierung. Ergebnis liest sich wie ein Pitch-Deck.
Pflicht-Schritt Risiko-Ranking am Ende einbauen. Kein Canvas verlässt die Session ohne Top-3-Risiken und Experiment Backlog.
Im Feld steht „KMU“, „Mittelstand“ oder „alle E-Commerce-Shops“.
Auf eine konkrete Early-Adopter-Subgruppe verengen: Branche, Größe, Tool-Stack, aktueller Schmerzpunkt. Wenn unklar, ist das selbst die erste Hypothese.
Solution-Box ist die erste mit Inhalt, Problem wird daraus rückwärts konstruiert.
Reihenfolge erzwingen: Problem und Customer Segments zuerst, Solution erst nach UVP. Bei Wiederholung leere Solution-Box bis Phase 2.
UVP enthält „revolutionär“, „nahtlos“, „intelligent“, ohne konkretes Outcome.
UVP-Test: Lässt sich der Satz vor einem Konkurrenten so unterschreiben? Wenn ja, ist er austauschbar. Konkrete Zahl, Zeit oder Outcome ergänzen.
Canvas wird einmal erstellt und nie wieder angefasst, obwohl Interviews neue Daten liefern.
Feste Iterations-Cadence (z. B. alle 2 Wochen) mit Re-Score der Risiko-Boxen. Letzte Version mit Datum sichtbar im Team-Wiki halten.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.