strivestudio

Berlin · Hamburg

Journal

Wie ein Builder-Team entscheidet, was es baut

Ein funktionierender Prototyp kostet Stunden, nicht Wochen. Damit verschiebt sich der Engpass vom Bauen zum Entscheiden: vier Phasen von der Value-Hypothese bis zur Produktionsentscheidung — mit einem echten Workshop-Case.

In einem zweitägigen Workshop bei einem großen Versicherungsunternehmen arbeiteten mehr als 20 Personen in sechs Gruppen an sechs internen Problemen. Mit vorbereiteter Infrastruktur und Dummy-Daten entstand pro Gruppe ein eigener Full-Stack-Prototyp: echtes Frontend, echtes Backend, Code, der als Ausgangspunkt wiederverwendbar ist.

Das waren keine Produktionsanwendungen. Security, Support, Integration und Ownership waren bewusst noch offen. Aber es waren auch keine Click-Dummys. Menschen konnten den Flow bedienen, an dem sie sonst täglich manuell arbeiten.

Vor zwei Jahren wäre das ein Quartalsprogramm gewesen. Heute ist es ein Workshop-Ergebnis.

Genau da beginnt das eigentliche Problem: sechs funktionierende Prototypen — und welcher verdient den nächsten Build?

Der Engpass ist nicht mehr das Bauen

Klassische Portfolio-Prozesse gehen davon aus, dass ein realistischer Build teuer ist. Deshalb wird viel abgestimmt, bevor gebaut wird.

Diese Annahme kippt. Kostet ein funktionierender Ausschnitt weniger als die nächste Abstimmungsrunde, ist Coding nicht mehr der Engpass. Knapp werden Nutzerzugang, Review, Security-Urteil und Ownership.

Billiger Output ohne Entscheidungsdisziplin erzeugt allerdings nur mehr Demos, nicht mehr Evidenz. Was es braucht, ist ein Betriebsmodell für den einzelnen Use Case: qualifizieren, einen Evidence Loop durchlaufen, eine begrenzte Version in den Workflow bringen, dann die Produktionsentscheidung treffen.

Vier Phasen. In jeder aktualisiert das Team, was es über Value, Desire, Feasibility sowie Betrieb und Verantwortung weiß.

Phase 1: Den Case qualifizieren

Am Anfang stehen fünf konkrete Dinge:

  1. Ein benannter Workflow-Owner und die Personen, die die Arbeit erledigen und den Build testen werden.
  2. Ein wiederkehrender Schmerz in diesem Workflow — nicht nur ein Feature-Wunsch ohne Bezug zur Arbeit.
  3. Eine Business-Value-Hypothese: Was soll schneller, sicherer, günstiger oder verlässlicher werden?
  4. Ein beobachtbares Erfolgssignal: Welches Verhalten würde zeigen, dass der Case besser geworden ist?
  5. Ein Fatal-Blocker-Screen für kritische Daten, Regulierung, Berechtigungen und Integrationen.

Business Value beginnt als Hypothese. Desire ist meist der erste empirische Test: Nutzen Menschen einen greifbaren Flow? Tiefere Feasibility folgt erst, wenn dieses Signal sie rechtfertigt. Ein harter technischer oder regulatorischer Blocker kann früher einen Technical Spike nötig machen — einen engen Build, der nur eine Feasibility-Frage beantwortet.

Phase 2: Den Evidence Loop durchlaufen

Der Loop hat fünf Schritte:

Frame → Slice → Build → Show → Re-score

Zuerst wird die riskanteste Annahme formuliert. Dann wird der kleinste nützliche Flow geschnitten, der sie sichtbar macht. Für echtes Verhalten bauen, ihn den Menschen zeigen, die die Arbeit erledigen, den Case neu bewerten — und die nächste Unsicherheit auswählen.

Für den ersten realistischen Prototypen sind 1–2 Stunden ein Operating Target: ein Happy Path, synthetische oder freigegebene Daten, keine Produktionsauthentifizierung. Ist die Integration selbst die Unsicherheit, gehört sie in den Slice. Die Zeitbox ist ein Zwang zur Klarheit, kein Benchmark. Braucht der Ausschnitt eine Woche, müssen entweder seine Annahmen kleiner werden — oder die Arbeit heißt Technical Spike.

Ein Beispiel: Ein interner Proposal Checker muss nicht mit CRM-Integration, Rollen und Reporting starten. Vielleicht nimmt er zunächst einen Antrag an, prüft ihn gegen drei vereinbarte Kriterien und gibt eine Review-Queue zurück. Das reicht, um Vertrauen, Overrides und fehlenden Kontext zu beobachten.

Jeder AI-generierte Ausschnitt muss klein genug bleiben, um ihn zu verstehen, zu reviewen und zu testen. Kann niemand Datenpfad und wahrscheinlichen Fehlermodus erklären, hat Geschwindigkeit nur Risiko versteckt.

Jeder Loop endet mit einer Entscheidung: stoppen, neu framen, einen Technical Spike durchführen oder den nächsten fokussierten Ausschnitt bauen. Ein Prototyp, der keine Annahme, Bewertung oder nächste Aktion verändert, ist nur eine Demo.

Was der Loop testet — und was nicht

Der Evidence Loop kann Problem-Evidenz schärfen, frühes Desire sichtbar machen, fokussierte Feasibility testen und die Value-Hypothese verbessern.

Er kann keinen realisierten ROI, keinen verlässlichen Betrieb, keine Support-Ökonomie, keine vollständige Security und keine IT-Akzeptanz beweisen. Eine polierte Oberfläche kann schwache Berechtigungen, brüchige Daten und manuellen Recovery-Aufwand verdecken.

Deshalb folgt als nächster Schritt keine Roadmap, sondern begrenzte Nutzung mit expliziten Kontrollen. Oder ein Stopp.

Phase 3: Eine begrenzte Version in den Workflow bringen

Ein Small Deployment folgt erst, wenn die Prototyp-Evidenz rechtfertigt, Value im echten Workflow zu testen — und die Exposition begrenzbar ist. „Klein” beschreibt Nutzergruppe, Datenumfang, Integrationen und Schadensradius. Nicht eine unvollständige Experience.

Jetzt werden Adoption und ein Workflow-Outcome gemessen. Edge Cases, Zuverlässigkeit, Support und der notwendige Security-Pfad werden sichtbar. Go-, Stop- und Rollback-Bedingungen stehen vor dem Deployment fest: eine begrenzte Gruppe, freigegebene Daten, gedeckelte Berechtigungen, ein definierter Laufzeitraum, ein Fallback auf den alten Workflow.

Das Endprodukt darf offen bleiben, während ein Owner den eingesetzten Ausschnitt verantwortet.

Phase 4: Die Produktionsentscheidung treffen

Die finale Entscheidung verbindet vier Evidence-Dimensionen:

  • Business Value: schätzen → präzisieren → messen → finanzieren oder stoppen
  • Desire: benannter Schmerz → Verhalten im Prototyp → Adoption → anhaltende Nachfrage
  • Feasibility: Blocker-Screen → kritischer Spike → Zuverlässigkeit in Nutzung → Production Readiness
  • Betrieb und Verantwortung: Workflow-Owner → Review-Pfad → Support-Owner und Fallback → Betriebs-Owner, Budget und IT-Akzeptanz

Die vierte Dimension fehlt in den meisten Frameworks. Sie fragt, was passiert, wenn das Builder-Team den Case verlässt: Wer besitzt Zugriffe, Incidents, User Support, Änderungen und Kosten? Eine Anwendung kann nützlich, gewünscht und technisch solide sein — und trotzdem keine tragfähige Zukunft im Betrieb haben.

Dann wird ein primärer Zug gewählt:

  • Stoppen: Die Evidenz rechtfertigt keine weitere Arbeit.
  • Lokal behalten: Das Tool bleibt bei einem benannten Business-Owner, mit begrenzten Nutzer:innen und gedeckelten Integrationen.
  • Erweitern: Ein weiterer fokussierter Ausschnitt löst eine wesentliche Unsicherheit auf.
  • Richtig finanzieren: Der Value rechtfertigt Produktbudget, Engineering und Härtung.
  • An die IT übergeben: Die IT übernimmt explizit Ownership, Budget und Support. Das kann trotzdem einen Rebuild erfordern.

Dieselbe Schleife wie in Phase A und B

Wer unsere Methode kennt, erkennt den Mechanismus: Hypothese formulieren, kleinsten Test bauen, Verhalten beobachten, entscheiden. In Phase A beantwortet ein Behavioral Prototype die Desire-Frage. In Phase B testet ein MVP, ob das Geschäft trägt. Interne Use Cases ändern nur die Bühne — der Loop bleibt derselbe.

Im Workshop verschoben die funktionierenden Prototypen das Gespräch von Feature-Ideen zu Berechtigungen, Integrationen, Support und Ownership. Die Artefakte machten die nächsten Unsicherheiten sichtbar, solange sie noch günstig zu bearbeiten waren.

Der nächste Build wird nur finanziert, wenn er der günstigste Weg ist, die wichtigste Unsicherheit aufzulösen. Bewertet wird nicht die Zahl der Prototypen, sondern die Qualität der Entscheidungen, die sie ermöglichen.

Quellen