Wir entwickeln digitale Produkte in drei klar getrennten Phasen — jede mit eigener Frage, eigenem
Lerninstrument, eigenem Ausgang. Nicht linear, sondern iterativ: wenn eine Annahme bricht,
gehen wir einen Schritt zurück, nicht das ganze Programm. Wir bauen, um zu lernen — und
lernen, um das Richtige zu bauen.
Übersicht
Die Karte.
Ein Blick auf das ganze Programm — drei Phasen, je vier (bzw. drei) Schritte, eine Schleife,
die sich in jeder Phase wiederholt. Jeder Schritt ist eine Frage, kein Deliverable.
„Wir glauben, dass [Zielgruppe] ein Problem mit [X] hat."
→
Phase B
Produktzielbild
„Wir bauen [Produkt] für [validierte Zielgruppe], weil [Mechanismus]."
→
Phase C
Marktzielbild
„Welche Märkte? Welches Team? Welche Routinen tragen das Produkt?"
Prinzip: Nicht linear — jede Phase enthält Schleifen. Das Zielbild darf nie weiter ausgereift sein als die Evidenz es trägt.
Belief
Bauen ist günstiger als Forschen geworden.
Die Kosten für einen testbaren, funktionalen Prototyp sind um rund 90%
gefallen. Was früher Monate kostete, dauert heute Tage. Damit kippt eine Grundannahme
klassischer Produktentwicklung: Es ist inzwischen billiger, etwas zu bauen und in echtem
Nutzerverhalten zu testen, als vorab extensiv zu forschen.
Das verändert nicht nur das Tempo. Es verändert, was als Evidenz zählt. Statt Aussagen
darüber, was Menschen tun würden, bekommen wir Daten darüber, was sie
tatsächlich tun. Unsere Methode ist die operative Antwort auf diese Inversion.
„Eine Fokusgruppe sagt dir, was Menschen tun würden. Ein Behavioral Prototype zeigt dir,
was sie tatsächlich tun."
Zyklus
Eine Schleife, die in jeder Phase greift.
Jede der drei Phasen folgt derselben fünfschrittigen Schleife. Nicht als Ritual, sondern als
Disziplin: Wir wissen vorher, was wir testen, und wir wissen nachher, was wir gelernt haben.
01
Vorbereiten
Kontext, Daten, Rahmen.
02
Hypothesen formulieren
Explizit, falsifizierbar, dokumentiert.
03
Testen
Im Markt oder im kontrollierten Versuchsaufbau.
04
Erkenntnisse ableiten
Verhalten lesen, nicht Meinungen sammeln.
05
Iterieren oder weiter
Schleife schließen oder Phase wechseln. ↺
Phase A
A · Desirability — Will jemand das?
Ziel: Verstehen, ob das Problem real ist, für wen es relevant ist, und ob
der Ansatz trägt. Fokus auf Lernen, nicht auf Auslieferung. In dieser Phase
verschmelzen Idee, Prototyp und Test — wir nennen das Design Doing: das
Bauen selbst ist die Forschungsmethode.
A1 · Discovery
Rahmen, Markt, Technologie und Ziele aufnehmen. AI Research liefert Breite: Reddit, Foren, Reviews, Tickets, Social. Interviews liefern Tiefe und erklären das Warum hinter den Mustern.
A2 · Hypothesen
Kompakter Arbeitsblock, nicht Wochen-Workshop. Wir formulieren Problem Statement, Value Proposition, ICP und ein dokumentiertes Hypothesen-Log. Schwelle für den nächsten Schritt: Confidence Threshold 30–40%. Darunter sind wir blind. Darüber kaufen wir Sicherheit, die nur echtes Verhalten liefern kann.
A3 · Behavioral Prototype
Funktionale Software, an echte Nutzer ausgespielt und so gebaut, dass sie Verhaltensdaten erzeugt — nicht bleibt. Klickbarer Flow, prozessualer Prototyp oder kurzlebige Anwendung. Der Code ist Wegwerfware, die Verhaltensdaten sind es nicht. Iterationen in Tagen, nicht Monaten.
A4 · Test & Lernen
Bewusster Versuchsaufbau. Wir beobachten Verhalten, nicht Selbstauskunft: Wer benutzt was wie oft, wo bricht es ab, was reizt zur Wiederkehr. Ergebnis: validierte oder falsifizierte Hypothesen, geschärftes Problem-Verständnis, klare Entscheidung — vertiefen, schärfen oder weiter nach B.
Phase B
B · Feasibility — Trägt das als Geschäft?
Ziel: Aus der validierten Idee ein minimal marktfähiges Produkt machen, das
echte Marktreaktionen erzeugt. Wir wechseln von qualitativem Lernen zu quantitativer
Marktvalidierung — von „Wollen sie es?" zu „Bezahlen sie es?".
B1 · Geschäftsannahmen
Preis, Marktvolumen, Zahlungsbereitschaft, erste Unit Economics, Signale für Product-Market-Fit. Jede Annahme dokumentiert und prüfbar formuliert — sonst bleibt der MVP Bauchgefühl mit Roadmap.
B2 · MVP bauen
Die kleinste sinnvolle Version für den echten Markt. Kein Wegwerf-Code mehr, aber auch keine Enterprise-Architektur für ein Produkt, das noch Fit sucht. Bewusster Architektur-Tradeoff: schnell genug für jetzt, offen genug für morgen — nicht overengineert für ein Zielbild, das noch nicht validiert ist.
B3 · Markttest
Bewusst breiter testen als in Phase A — über Early Adopters hinaus, durch verschiedene Segmente. Stimmen Preis, Nutzung, Konversion? Trägt das Signal in den Mainstream? Reale Zahlen aus realen Kanälen, nicht aus dem Convenience Sample.
B4 · Ableitungen
Tragfähig genug für den Geschäftsmodell-Aufbau — oder zurück. Pivot der Zielgruppe? Einzelne Annahmen korrigieren? Problem richtig, Umsetzung falsch? Wir treffen die Entscheidung explizit, nicht durch Schweigen.
Phase C
C · Go-to-Market — Wie skalieren wir tragfähig?
Ziel: Validiertes Produkt schrittweise in den Markt bringen und
organisatorisch absichern. Der Fokus verschiebt sich von „Funktioniert es?" zu „Wie wachsen
wir kontrolliert und systematisch besser?". Strives Kernarbeit ist A + B; Phase C begleiten
wir, wo Kunden den Übergang in die operative Skalierung nicht alleine gehen wollen.
C1 · Planung & Zielbild
Erste Roadmap, Prioritäten, Zielbild für Produkt und Organisation. Annahmen für die Markteinführung explizit machen — nicht nur Produktfragen, sondern auch wer was wann übernimmt.
C2 · Launch & Learn
Kein Big Bang. Kleine Releases, kleine Experimente, klare Retention- und Churn-Metriken. Auch in der Skalierungsphase bleibt das System lernend: wir prüfen Ziele, schärfen Produktdetails und verstehen, warum Nutzer zurückkommen — oder nicht.
C3 · Kontinuierliche Iteration
Aus Experimenten werden belastbare Routinen. Teams lernen den Zyklus selbst zu fahren, Rollen und Entscheidungswege werden geklärt. Am Ende übergeben wir eine Organisation, die ohne uns weiter testen, lernen und entscheiden kann.
Begriffe
Was wir bauen — und warum es nicht „MVP" heißt.
Zwei Begriffspaare, die in unserer Methode tragend sind. Die Begriffe klingen nach Wortklauberei,
machen aber den Unterschied zwischen einem Prototyp, der eine Frage beantwortet, und einem
Produkt, das ein Geschäft prüft.
Behavioral Prototype vs. MVP
Behavioral Prototype (Phase A)
funktionale Software, gebaut um Verhalten zu erzeugen und Hypothesen zu falsifizieren. Wegwerfware per Design. Frage: Will jemand das?
MVP (Phase B)
minimal marktfähiges Produkt, gebaut um Geschäftsannahmen unter realen Marktbedingungen zu testen. Frage: Trägt das als Geschäft?
Design Thinking vs. Design Doing
Design Thinking
validiert mit Prototypen, die simulieren. Reaktionen in kontrollierten Settings, hypothetische Präferenz.
Design Doing
validiert mit Prototypen, die funktionieren. Verhalten in echten Kontexten, Revealed Preference. Das ist der Unterschied zwischen „Ich würde das definitiv nutzen" im Interview — und Stille nach dem Launch.
Recap
Auf einen Blick.
PhaseFokusKernfrageLieferobjekt
A — DesirabilityProblem-FitWill jemand das? Ist das Problem real?Behavioral Prototype (→ wegwerfen)
B — FeasibilityMVP-FitTrägt das als Geschäft?MVP (→ weiterentwickeln oder pivoten)
C — Go-to-MarketMarket-FitWie skalieren wir kontrolliert?Produkt + Organisation
Nächster Schritt
Lass uns Phase A prüfen.
Ein Phase-A-Start beginnt mit einer kurzen Discovery: Wo steht ihr, welche Hypothesen
liegen offen, was lässt sich in den nächsten Wochen testen? Ein Erstgespräch dauert
30 Minuten. Danach wissen wir beide, ob Phase A sinnvoll ist.
