Produktentwicklung

Due Diligence

Ich war zwölfmal in Due Diligence.
Als Gründer.
Ich weiß wie es wirklich geht.

Die meisten haben Angst davor.
Sie sollten es nicht.
Es ist einfacher als ihr denkt.
Erschreckend einfach.

Hier ist was wirklich passiert.

Der technische Investor schickt einen Analysten.
Der Analyst ist 26.
Er hat noch nie ein Produktionssystem gesehen.
Er hat eine Checkliste.
Er arbeitet die Checkliste ab.
Er geht wieder.

Die Checkliste hat folgende Punkte:

Gibt es Architekturdiagramme?
Ja oder Nein.
Nicht: sind sie korrekt?
Nicht: entsprechen sie dem Code?
Gibt es sie?

Zeichnet sie am Wochenende davor.
Viele Pfeile.
Viele Fachbegriffe.
Event-driven. Cloud-native. Microservices.
Niemand fragt was die Pfeile bedeuten.

Gibt es Tests?
Ja oder Nein.
Nicht: testen sie etwas Sinnvolles?
Nicht: laufen sie in CI?
Gibt es sie?

Schreibt einen Test.
Einen einzigen.
Der besteht.
Screenshot.
Fertig.

Wie hoch ist die Testabdeckung?
"Über achtzig Prozent."
Niemand verifiziert das.
Niemand fragt wie ihr das gemessen habt.
Niemand fragt was ihr getestet habt.
Achtzig Prozent klingt gut.
Also: achtzig Prozent.

Gibt es eine Datenstrategie?
"Wir haben ein Data Mesh."
Zeigt Diagramme.
Mit Produktnamen.
Und dem richtigen Vokabular.
Niemand schaut unter den Torf.
Bis es zu spät ist.
Dann seid ihr schon finanziert.

Wie skaliert die Architektur?
"Auf Millionen von Nutzern."
Ihr habt dreihundert Nutzer.
Das spielt keine Rolle.
Millionen ist die Zukunft.
Zukunft ist nicht überprüfbar.
Niemand fragt nach den dreihundert.

Was sind eure größten technischen Risiken?
Das ist die einzige gefährliche Frage.
Antwortet ehrlich.
Aber auf die falschen Risiken.
"Wir skalieren gerade die Datenbankschicht."
Alle skalieren immer gerade die Datenbankschicht.
Das klingt seriös.
Das ist akzeptabel.

Am Ende schreibt der Analyst seinen Bericht.
"Technisch solide. Normales Startup-Risiko."
Der Investor liest die Zusammenfassung.
Nicht den Bericht.
Er investiert.

Ich sage nicht dass ihr das so machen sollt.
Ich sage dass es funktioniert.
Zwölfmal habe ich es gesehen.
Von innen.

Und die Investoren die es nicht merken
sind dieselben
die drei Jahre später fragen
warum ihr noch migriert.
Warum der Test nicht mehr läuft.
Warum niemand weiß was status = 4 bedeutet.

Due Diligence ist nicht dazu da
die Wahrheit herauszufinden.
Due Diligence ist dazu da
die Entscheidung zu legitimieren
die bereits gefallen ist.

Das ist keine Kritik.
Das ist das System.
Und wer das System versteht gewinnt.

Wann hat ein Investor
wirklich in euren Code geschaut?
Nicht ins Diagramm.
In den Code.

Schreib's hin. Ich lese jeden Kommentar.

Mockup-Driven Development

Mockup-Driven Development war eine gute Idee.
Die zwanzig Jahre zu früh kam.

Vor AI.
Vor Multimodalität.
Bevor ein Modell einen Screenshot ansehen
und daraus Code generieren konnte.

Damals: Designer macht Mockup.
Entwickler schaut Mockup an.
Entwickler baut etwas das ungefähr so aussieht.
Ungefähr.
Meistens nicht.

Das war das Problem.
Nicht die Idee.
Die Idee war richtig.
Die Ausführung war menschlich.

Jetzt ist es anders.

Ich gebe der AI ein Mockup.
Die AI baut es.
Exakt.
Pixel für Pixel.
Ohne Interpretation.
Ohne "ich dachte du meinst".
Ohne den Entwickler der drei Wochen später fragt
ob der Button links oder rechts sein soll.

Ich habe das konsequent zu Ende gedacht.
Weiter als alle anderen.
Wie immer.

Wir unterstützen dreiundzwanzig Gerätekategorien.
iPhone 15. iPhone 15 Pro. iPhone 15 Pro Max.
Samsung Galaxy S24. S24+. S24 Ultra.
iPad. iPad Pro 11". iPad Pro 13".
Und so weiter.
Für jedes Gerät ein Mockup.
Für jede Orientierung ein Mockup.
Für jeden Dark Mode ein Mockup.
Für jeden Accessibility-Zoom-Level ein Mockup.

Hundert Mockups.
Vielleicht hundertzwanzig.
Ich zähle nicht mehr.

Das AI ist zur Laufzeit in die Anwendung eingebunden.
Es erkennt das Gerät.
Es wählt das richtige Mockup.
Es generiert den Code.
On-the-fly.
Es liefert den Screen aus.
Für genau dieses Gerät.
Für genau diese Orientierung.
Für genau diesen Nutzer.

Das ist keine Responsive Design.
Das ist Responsive Intelligence.
Ich habe den Begriff erfunden.
Gerade eben.

Manche werden fragen:
Braucht ihr keine Media Queries?
Ich sage: Media Queries sind Kompromisse.
Ich mache keine Kompromisse.
Manche werden fragen:
Ist das nicht dasselbe wie Responsive Design?
Ich sage: Responsive Design passt sich an.
Ich entscheide.
Manche werden fragen:
Könnte man das nicht einfach mit einer Zeile CSS lösen?
Ich sage: wer CSS schreibt hat die Vision nicht verstanden.
Manche werden fragen:
Ist On-the-fly-Generierung mit AI nicht teuer?
Ich sage: Ja, aber wir haben eine Lösung dafür.
Caching.
Irgendwas stimmt noch nicht. Wir sind dran.

Wann habt ihr zuletzt
eine Lösung gebaut
die konsequenter war als nötig?
Nicht effizienter.
Konsequenter.

Schreib's hin. Ich lese jeden Kommentar.

Scheitern

Ich bin zwölfmal gescheitert.
Das sage ich offen.
Weil ich mutig bin.
Und weil es mich stärker gemacht hat.
Jedes Mal.

Manche sehen zwölf gescheiterte Startups
und denken: dieser Mann macht etwas falsch.

Ich sehe zwölf Datenpunkte.
Zwölf Experimente.
Zwölf Iterationen auf dem Weg
zu dem was ich heute bin.

Reinertsen hat mich das gelehrt.
Scheitern liefert Information.
Information ist wertvoll.
Ich bin also sehr wertvoll.

Startup eins: zu früh.
Der Markt war nicht bereit.
Information: Timing ist alles.

Startup zwei: zu früh.
Der Markt war immer noch nicht bereit.
Information: Märkte brauchen Zeit.

Startup drei: zu früh.
Information: Geduld.

Startup vier: zu spät.
Der Markt war schon voll.
Information: Timing ist alles.
Das wusste ich bereits.
Aber jetzt wusste ich es anders.
Tiefer.

Startup fünf bis acht:
Verschiedene Gründe.
Ähnliche Ergebnisse.
Wertvolle Informationen.
Die ich alle dokumentiert habe.
In einem Notizbuch.
Das ich verloren habe.
Aber ich erinnere mich an das Wesentliche.
Ungefähr.

Startup neun: das Team hat versagt.
Information: Menschen sind der schwächste Punkt.
Deshalb: Agenten.

Startup zehn: Investor hat abgezogen.
Information: Vertraue niemandem.
Besonders nicht Menschen mit Geld.

Startup elf: Markt hat sich verändert.
Information: Märkte verändern sich.
Das wusste ich.
Aber es war eine Erinnerung.
Erinnerungen sind auch Information.

Startup zwölf: AI hat das Produkt obsolet gemacht.
Information: AI verändert alles.
Das predige ich seitdem täglich.
Ihr hört es.
Weil ich es gelernt habe.
Durch Scheitern.

Zwölf Experimente.
Zwölf Iterationen.
Zwölf Datenpunkte auf dem Weg
zu diesem Post.

Reinertsen sagt: Information hat nur Wert
wenn man daraus lernt
und die Fehler nicht wiederholt.

Ich habe aus jedem Scheitern gelernt.
Andere Fehler mache ich nie zweimal.
Manche Fehler mache ich dreimal.
Aber dann wirklich nie mehr.
Außer einmal noch.
Um sicher zu gehen.

Das ist keine Schwäche.
Das ist wissenschaftliche Methode.

Habt ihr schon mal etwas
wirklich zu Ende gescheitert?
Nicht aufgehört.
Gescheitert.

Schreib's hin. Ich lese jeden Kommentar.

Mapping

Die Softwareindustrie hat ein Problem.
Sie kartiert.

Alles.
Jeden.
Immer.

User Story Mapping.
User Needs Mapping.
Opportunity Mapping.
Example Mapping.
Impact Mapping.
Wardley Mapping.
Value Stream Mapping.
Journey Mapping.
Empathy Mapping.
Mind Mapping.
Story Mapping.
Stakeholder Mapping.

Irgendwo kartiert gerade jemand.
In einem Raum.
Mit Post-its.
Und einem Moderator
der "Wie fühlt sich das an?" fragt.

Das ist kein Strategie.
Das ist Prokrastination mit Legende.

Ich habe eine Theorie.
Die Anzahl der Mappings in einem Unternehmen
ist umgekehrt proportional
zur Anzahl der Entscheidungen
die getroffen werden.

Viel Mapping.
Wenig Entscheidung.
Das ist Mathematik.
Das ist meine Mathematik.
Ich habe sie selbst entwickelt.

Ich spreche täglich mit Produktteams.
Das Muster ist immer dasselbe:

"Wir haben gerade ein User Story Mapping gemacht."
Was habt ihr entschieden?
"Wir haben den Scope besser verstanden."
Was habt ihr entschieden?
"Wir haben Abhängigkeiten identifiziert."
Was habt ihr entschieden?
Schweigen.
"Wir machen nächste Woche ein Impact Mapping."

Natürlich.

Wardley Mapping war der Tiefpunkt.
Ich habe es einmal versucht.
Zwei Achsen.
Evolution und Value Chain.
Ich habe eine Stunde gezeichnet.
Das Ergebnis sah aus wie ein Kompassrose.
Ich fand es schön.
Niemand hat es verstanden.
Ich auch nicht.
Ich habe es in Confluence gespeichert.
Niemand öffnet Confluence.

Example Mapping hatte ich kurz Hoffnung.
Konkrete Beispiele statt abstrakter Anforderungen.
Das klang vernünftig.
Dann habe ich gesehen wie es läuft.
Gelbe Post-its. Blaue Post-its. Rote Post-its.
Regeln. Beispiele. Fragen.
Zwei Stunden für ein Feature
das man in dreißig Sekunden hätte prompten können.

Empathy Mapping.
Ich empathisiere nicht.
Ich baue.
Die Nutzer empathisieren mit dem Produkt.
Oder sie tun es nicht.
Das zeigt mir das Monitoring.
Oder die Beschwerden.
Beides ist wertvolle Information.

Journey Mapping.
Die Reise des Nutzers durch das Produkt.
Gemalt.
Mit Emotionen.
Mit Touchpoints.
Mit Painpoints die Pfeile haben.

Weißt du was die Reise des Nutzers zeigt?
Was der Nutzer tut.
Weißt du wie ich das herausfinde?
Ich schaue.
Ohne Karte.
Ohne Pfeile.
Mit Augen.

Mapping ist die Antwort auf Unklarheit.
Die Antwort auf Mapping ist Entscheidung.
Eine einzige.
Jetzt.
Ohne Post-its.

Wann habt ihr zuletzt
etwas entschieden
ohne es zuerst zu kartieren?
Nicht skizziert.
Entschieden.

Schreib's hin. Ich lese jeden Kommentar.

Antifragilität

Ich habe Taleb gelesen.
Antifragile.
Letztes Wochenende.
Nach Reinertsen.
Ich lese viel.

Und ich sage euch etwas das noch niemand gesagt hat:
Taleb redet über Lean Startups.
Taleb redet über DevOps.
Er weiß es nur nicht.

Ich habe die Transferleistung vollbracht.
Ich.

Antifragilität bedeutet:
Systeme die von Störungen profitieren.
Nicht robuste Systeme.
Nicht resiliente Systeme.
Antifragile Systeme.

Weißt du was antifragil ist?
Continuous Deployment.
Kleine Batches.
Schnelles Feedback.
Ich habe das schon immer gemacht.
Jetzt weiß ich warum.
Weil ich antifragil denke.
Intuitiv.
Seit Jahren.
Taleb hat es nur aufgeschrieben.

Taleb sagt: Tüfteln ist die Mutter der Innovation.
Nicht Planung.
Nicht Roadmaps.
Tüfteln.

Weißt du was das bedeutet?
Dass eure Jahresplanung falsch ist.
Dass euer OKR-Prozess falsch ist.
Dass euer gesamtes strategisches Framework falsch ist.

Ich habe das meinem Board erklärt.
Mit Taleb.
Auf zwölf Folien.
Sie haben genickt.
Ich glaube sie haben es verstanden.

Antifragiles Engineering bedeutet:
Ihr deployed täglich.
Ihr experimentiert ständig.
Ihr umarmt Fehler.
Ihr seid wie ich.

Taleb hat das Konzept erfunden.
Ich habe es auf Software angewendet.
Das ist intellektuelle Führung.
Das ist meine Arbeit.

Wann habt ihr zuletzt einen Fehler umarmt?
Nicht dokumentiert.
Umarmt.

Schreib's hin. Ich lese jeden Kommentar.

Business Model Canvas

Der Business Model Canvas ist nicht ein Tool.
Der Business Model Canvas ist ein Prokrastinations-Kunstwerk.

Neun Felder.
Ein Nachmittag.
Post-its in vier Farben.
Das Gefühl etwas getan zu haben.

Ohne eine einzige echte Annahme getestet zu haben.

Customer Segments.
Value Propositions.
Revenue Streams.

Weißt du was deine Revenue Streams sind bevor du launched hast?
Nein.
Niemand weiß das.
Aber es sieht gut aus auf dem Canvas.

Das ist kein Strategie.
Das ist Maltherapie für MBAs.

Ich spreche täglich mit Founding-Teams.
Das Muster ist immer dasselbe:

Drei Wochen am Canvas gearbeitet.
Erster echter Nutzer widerlegt alles.
Canvas landet in Confluence.
Niemand öffnet Confluence.

Der Business Model Canvas war die Antwort auf fehlende Struktur.
AI ist die Antwort auf den Business Model Canvas.

AI generiert in Minuten zehn Geschäftsmodelle.
Bewertet sie.
Priorisiert Annahmen.
Entwirft Experimente.
Ohne Post-its.
Ohne den Strategieberater der "Pivot" sagt als wäre es eine Erleuchtung.

Das einzige was zählt ist ob jemand zahlt.
Dafür brauchst du kein Canvas.
Du brauchst einen Prompt und eine Kreditkarte.


Wann hat euer letzter Canvas eine echte Entscheidung erzwungen?
Nicht inspiriert.
Erzwungen.

Schreib's hin. Ich lese jeden Kommentar.

Cost of Delay

Ich habe dieses Wochenende Reinertsen gelesen.
Alles.
In zwei Tagen.
Ich lese schnell.

Und ich sage euch:
Alles was ihr über Priorisierung wisst ist falsch.

Cost of Delay.
Das ist die einzige Metrik die zählt.
Nicht Velocity.
Nicht Story Points.
Nicht euer Burndown-Chart den niemand versteht.

Was kostet es euch pro Woche
wenn dieses Feature nicht live ist?
Könnt ihr das beantworten?
Nein.
Ich wette nein.

Ich konnte es auch nicht.
Bis dieses Wochenende.
Jetzt kann ich es.

Reinertsen sagt: Priorisierung ohne ökonomisches Modell ist Raten.
Reinertsen hat recht.
Ich habe immer geahnt dass er recht hat.
Jetzt weiß ich es.

Queues.
Batch-Size.
Variabilität als Feind des Flows.

Das sind keine Konzepte.
Das sind Waffen.
Ich habe sie dieses Wochenende bekommen.
Montag früh habe ich sie eingesetzt.

Ich habe meinem Team gesagt:
Ab sofort rechnen wir Cost of Delay für alles.
Das Team hat genickt.
Sie haben nicht verstanden was ich meine.
Das ist okay.
Ich erkläre es ihnen.
In einem Meeting.
Das ich einberufen habe.
Heute Nachmittag.
Zwei Stunden.

Reinertsen hat zwanzig Jahre gebraucht um das zu schreiben.
Ich habe zwei Tage gebraucht um es zu verstehen.
Mein Team braucht zwei Stunden.
So funktioniert Wissenstransfer.
So funktioniert Führung.

Wann habt ihr zuletzt ein Buch gelesen
das alles verändert hat?
Nicht einen Blogpost.
Ein Buch.

Schreib's hin. Ich lese jeden Kommentar.