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.
Produktidee validieren
Ein Behavioral Prototype macht eine Idee testbar.
Ein Behavioral Prototype ist funktionale Software, die eine falsifizierbare Produktannahme
mit echten Nutzer:innen testet — bevor daraus ein MVP wird.
Der Payoff: Statt auf Zustimmung zu Konzepten zu bauen, entscheiden wir auf Basis von
beobachtetem Verhalten. So wird früh sichtbar, ob eine Idee geschärft, verworfen oder
weiterentwickelt werden sollte.
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 kann Forschung ergänzen.
Bei Strive nutzen wir digitale Prototypen als begrenzte Lernschleife: Wir bauen etwas
Testbares, beobachten Verhalten und entscheiden dann, ob eine Annahme geschärft, verworfen
oder weiterentwickelt werden sollte.
Der Wert liegt nicht im Tempo allein, sondern in der Art der Evidenz. Statt Aussagen darüber,
was Menschen tun würden, kann ein Behavioral Prototype Daten darüber liefern, was
sie tatsächlich tun. Unsere Methode macht diese Beobachtung zur nächsten Entscheidung.
„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. Strives Arbeitsheuristik für den nächsten Schritt: ein Confidence Threshold von 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
Häufige Fragen
Was Teams vor dem ersten Prototyp wissen wollen.
Was ist ein Behavioral Prototype?
Ein Behavioral Prototype ist funktionale Software, die eine falsifizierbare Produktannahme mit echten Nutzer:innen testet. Er wird gebaut, um eine Frage zu beantworten, und danach weggeworfen. Der Code ist Wegwerfware, die Verhaltensdaten sind es nicht.
Was unterscheidet einen Behavioral Prototype von einem MVP?
Der Behavioral Prototype gehört in Phase A und beantwortet: Will jemand das? Der MVP gehört in Phase B und beantwortet: Trägt das als Geschäft? Wer beides verwechselt, optimiert Code, der weggeworfen werden soll — oder verwirft Produkte, die verfeinert werden sollten.
Was ist Design Doing?
Design Doing validiert mit Prototypen, die funktionieren, statt mit Prototypen, die simulieren. Wir lesen Revealed Preference — was Menschen im echten Kontext tun — statt hypothetischer Präferenz im Interview. Das Bauen selbst ist die Forschungsmethode.
Wann lohnt sich ein Behavioral Prototype — und wann nicht?
Wir arbeiten mit einem Confidence Threshold von 30 bis 40 Prozent. Darunter sind wir blind, und ein Test muss das Verständnis erst liefern. Darüber kaufen wir Sicherheit, die nur echtes Verhalten liefern kann — dann gehört die Idee nicht in einen weiteren Workshop, sondern in den Markt.
Was passiert, wenn eine Hypothese nicht trägt?
Dann ist das Ergebnis eine Entscheidung, kein Scheitern. Phase A endet mit validierten oder falsifizierten Hypothesen und einer expliziten Wahl: vertiefen, schärfen oder in Phase B überführen. Wir treffen sie ausgesprochen, nicht durch Schweigen.
Begleitet ihr auch Phase C?
Unsere Kernarbeit ist Phase A und B. Phase C begleiten wir dort, wo Teams den Übergang in die operative Skalierung nicht alleine gehen wollen. Am Ende steht eine Organisation, die ohne uns weiter testen, lernen und entscheiden kann.
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.
