Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Lange Zeit war Technologie ein echter Unterschied.
Wer sich eine große Oracle-Datenbank, leistungsstarke Server, eine solide Infrastruktur und die Teams leisten konnte, diese zu betreiben, hatte einen echten Wettbewerbsvorteil. Die Einstiegshürde war hoch. Die Technologie selbst war ein Teil des Moats.
Dann kam die Cloud.
Mit AWS, Google Cloud, Azure und den anderen wurden dieselben technologischen Bausteine für alle zugänglich. Man muss nicht mehr stark im Voraus investieren: Man kann on demand mieten. Man muss nicht mehr schon groß sein, um sich wie ein Großer auszustatten.
Ergebnis: Die Technologie hat sich weitgehend normalisiert.
Natürlich gibt es immer noch Unterschiede in der Ausführung. Manche bauen besser als andere. Manche betreiben besser, sichern besser, entwerfen bessere Architekturen. Aber der bloße Besitz von „der Technologie" ist für sich allein kein dauerhafter Unterschied mehr.
Und mit KI machen wir einen weiteren Schritt.
Wir werden schneller produzieren können:
- mehr Funktionalitäten,
- mehr Screens,
- mehr Varianten,
- mehr Inhalte,
- mehr Code.
Die Produktionskosten von Software werden weiter sinken. Und damit wird die Anzahl der Akteure, die einen Markt angreifen können, weiter steigen.
Aber wenn alle schnell und gut produzieren können, dann reicht schnell und gut produzieren nicht mehr.
Features am laufenden Band zu liefern wird kein Vorteil mehr sein. Es wird einfach das Minimum sein.
Deshalb bin ich immer überzeugter, dass der echte Unterschied für Softwareanbieter sich anderswo verlagern wird: zum Verstehen des Kontexts.
Was zählen wird, ist Verstehen vor dem Bauen
Wenn Technologie zur Ware wird und die Produktionskapazität im Überfluss vorhanden ist, verändert sich, wo Seltenheit liegt.
Sie liegt nicht mehr im „Machen". Sie liegt im „Verstehen".
Den Kontext zu verstehen bedeutet nicht nur, zwei Kunden zuzuhören, drei Interviews zu machen und eine Rahmenkurznotiz zu schreiben. Es bedeutet, alles, was eine Produktchance umrahmt, in der Tiefe zu begreifen.
Zum Beispiel:
- die Branche,
- die Nutzer,
- die Kunden,
- die technischen Einschränkungen,
- die Normen,
- die Feldkultur,
- den Wettbewerb.
Anders gesagt: Die besten Anbieter werden nicht gewinnen, weil sie mehr produzieren. Sie werden gewinnen, weil sie besser verstehen.
Das Business wirklich verstehen
Viele Software-Teams bauen noch immer Funktionalitäten, ohne zu verstehen:
- das Geschäftsmodell des Kunden,
- seine Abwägungen,
- seine Margen,
- seine operativen Einschränkungen,
- seine tatsächlichen Prioritäten,
- und seine Unternehmenskultur.
Diese kulturelle Dimension ist weit davon entfernt, nebensächlich zu sein. Sie ist oft entscheidend, insbesondere bei:
- großen Konzernen,
- internationalen Unternehmen,
- bestimmten stark kodierten Branchen.
Zwei Unternehmen können auf dem Papier denselben scheinbaren Bedarf haben und in Wirklichkeit zwei sehr unterschiedliche Dinge erwarten, einfach weil sie nicht haben:
- dieselbe Entscheidungskultur,
- dasselbe Verhältnis zum Risiko,
- dasselbe Zentralisierungsniveau,
- dasselbe Verhältnis zwischen Zentrale und Feld,
- dieselbe Erwartung an Standardisierung.
Wenn man das nicht versteht, kann man etwas Richtiges bauen… aber am Ziel vorbei.
In einer Welt, in der alle bauen können, wird die eigentliche Frage nicht mehr sein: „Können wir dieses Feature entwickeln?" sondern vielmehr: „Verstehen wir die Situation gut genug, um das Richtige zu bauen?"
Die Nutzer verstehen, nicht die imaginären Nutzer
Oft liegt zwischen dem Nutzer, den man sich in einem Workshop vorstellt, und dem, der tatsächlich im Feld arbeitet, eine ganze Welt.
Was man verstehen muss, sind:
- seine Einschränkungen,
- seine Gewohnheiten,
- seine Abkürzungen,
- seine Widerstände,
- seine mentale Last,
- seine Umgehungslösungen.
Mit KI werden wir sehr schnell Oberflächen generieren können. Aber schnell eine schlechte Antwort auf ein echtes Problem zu generieren bleibt… eine schlechte Antwort.
Der Unterschied liegt in der Qualität des Verständnisses:
- Wissen wir, wie die Leute wirklich arbeiten?
- Verstehen wir, was sie tolerieren, was sie ablehnen, was sie sich nicht zu sagen trauen?
- Erfassen wir die Unterschiede je nach Rolle, Branche, digitaler Reife oder Unternehmensgröße?
Den Kunden verstehen, nicht nur den Nutzer
Im B2B ist der Kunde nicht nur „der Nutzer".
Der Kunde ist oft auch:
- derjenige, der zahlt,
- derjenige, der abwägt,
- derjenige, der das Projekt trägt,
- derjenige, der seine Hierarchie beruhigen muss,
- derjenige, der das Risiko fürchtet,
- derjenige, der sich fragt, ob der Rollout tragbar sein wird.
Ein Produkt kann:
- von Nutzern geschätzt werden und sich trotzdem nicht verkaufen,
- ein echtes Problem lösen und beim Kauf trotzdem blockiert werden,
- gut sein, aber unvereinbar mit den Entscheidungskriterien der Organisation.
Auch hier wird das Verstehen des Kontexts zentral.
Die Technik verstehen, aber anders
Zu sagen, dass Technologie nicht mehr der Hauptunterschied ist, bedeutet nicht, dass sie keine Rolle mehr spielt.
Sie spielt weiterhin eine Rolle, aber anders.
Was den Unterschied ausmachen wird, ist nicht nur der Zugang zum richtigen Stack. Es ist zu verstehen, was im gegebenen Kontext vernünftig, robust und tragbar zu bauen ist.
Mit KI werden wir mehr Code produzieren können. Aber wir werden nicht automatisch haben:
- mehr Architekturkohärenz,
- mehr Zuverlässigkeit,
- mehr Sicherheit,
- noch bessere Integrationen.
Die Frage wird also weniger „Können wir das coden?" sein als:
- Können wir es sauber integrieren?
- Können wir es warten?
- Können wir es absichern?
- Können wir es in der Realität zum Laufen bringen?
Den Wettbewerb, schwache Signale, blinde Flecken verstehen
Die andere Falle ist, sein Produkt im luftleeren Raum zu denken.
Der Markt bewegt sich, während man baut. Wettbewerber verändern sich, Erwartungen verschieben sich, manche Nutzungsweisen werden zum Standard, andere verschwinden, neue Akteure kommen schneller als zuvor.
Mit KI wird dieser Druck noch zunehmen. Es wird mehr Akteure geben, die etwas Glaubwürdiges auf den Markt bringen können.
Also wird man verstehen müssen:
- was die Wettbewerber tun,
- was sie versprechen,
- was sie nicht können,
- wo sich der Markt standardisiert,
- wo es noch echte blinde Flecken gibt.
Normen, Regulierung, Rückverfolgbarkeit: ein immer zentraleres Thema
Ich glaube auch, dass wir noch unterschätzen, wie sehr der regulatorische und normative Kontext in den kommenden Jahren an Wert gewinnen wird.
Man denkt oft an:
- ISO-Normen,
- Branchenbezugsrahmen,
- Prüfungsanforderungen,
- Cybersicherheit,
- Datenschutz,
- sektorale Compliance.
Aber es gibt auch eine sehr konkrete, sehr feldnahe Schicht, die immer wichtiger wird:
- Rückverfolgbarkeit,
- Archivierung,
- Normalisierung,
- Vergleichbarkeit der Daten,
- Begründung von Abweichungen,
- Lesbarkeit für Finanzen oder Controlling.
Sehr oft drückt sich das in einfachen Sätzen aus:
- „Der Controller fragt mich nach diesem Punkt",
- „Wir müssen diese Zahl begründen können",
- „Man muss nachvollziehen können, wer was wann und warum getan hat",
- „Es muss zwischen Standorten vergleichbar sein",
- „Wir brauchen auswertbare Daten für das Audit".
Anders gesagt: Es geht nicht mehr nur darum, ein nützliches Werkzeug zu bauen. Man muss auch ein Werkzeug bauen, das:
- Spuren hinterlässt,
- Informationen strukturiert,
- Entscheidungen lesbar macht,
- einer Audit-Logik standhält,
- einer Steuerungslogik standhält,
- einer Standardisierungslogik standhält.
Und das ist nicht nur Technik. Es ist ein tiefes Verstehen des Kundenkontexts.
Was an Wert gewinnen wird: das Kontextdokument
Konkret glaube ich, dass eines der Ergebnisse, das in den kommenden Jahren am meisten an Wert gewinnen wird, nicht nur die Spezifikation ist, auch nicht die Roadmap.
Es wird ein echtes Kontextdokument für eine gegebene Chance sein.
Ein Dokument, das zwingt, schwarz auf weiß explizit zu machen:
- den Business-Kontext,
- den Produkt-Kontext,
- den Kunden-Kontext,
- den Nutzer-Kontext,
- den technischen Kontext,
- die Branchenregeln,
- die Normen und die Regulierung,
- die Kultur und die Feldpraktiken,
- den Wettbewerb und die Alternativen,
- die Geschichte und die bereits getroffenen Entscheidungen.
Und ein gutes Kontextdokument dient nicht nur dazu, Fakten anzuhäufen. Es dient auch dazu, zu unterscheiden:
- was ich weiß,
- was ich glaube,
- was mich zweifeln lässt,
- was nicht ausgesprochen wird.
Denn morgen, wenn produzieren für alle einfacher sein wird, liegt der Wert nicht nur in der Fähigkeit, eine Lösung zu liefern.
Er liegt in der Fähigkeit:
- das Problem richtig zu rahmen,
- den Kontext zu dokumentieren,
- Risikozonen sichtbar zu machen,
- das Team auf ein tieferes Verständnis der Chance auszurichten.
Tatsächlich wird dieses Kontextdokument fast zu einem strategischen Vermögenswert.
Im Kern verschiebt sich der Wettbewerbsvorteil
Ich glaube, wir treten in eine Phase ein, in der sich der Wettbewerbsvorteil von Softwareanbietern sehr deutlich verschieben wird.
Gestern lag er stark im Zugang zur Technologie. Heute liegt er dort schon weniger. Morgen, mit KI, wird er noch weniger in der Produktion selbst liegen.
Der echte Vorteil liegt in der Qualität des Verständnisses.
Besser als die anderen verstehen:
- die Branche,
- die Nutzer,
- die Kunden,
- die technischen Einschränkungen,
- die Normen,
- die Feldkultur,
- den Wettbewerb,
- und alle schwachen Signale, die die Natur einer Chance verändern.
Wenn alle bauen können, gewinnt nicht derjenige, der am meisten produziert.
Es ist derjenige, der am besten versteht, was zu bauen ist, für wen, in welchem Umfeld, mit welchen Einschränkungen, und um welchen Wert zu schaffen.
Konkretes Beispiel
- 00-context.md
**Status** : Entwurf / In Überprüfung / Validiert
**Verantwortlich** : PM
**Letzte Aktualisierung** : YYYY-MM-DD
# Kontext
## Business-Kontext
_Was sind die geschäftlichen Herausforderungen hinter diesem Thema? Warum existiert es? Welche bekannten geschäftlichen Einschränkungen gibt es? Funktioniert diese Chance für unser Geschäftsmodell, unser Go-to-Market, unsere Strategie?_
_(→ Risiko der geschäftlichen Tragfähigkeit)_
## Produkt-Kontext
_Wie funktioniert es heute? Was sind die aktuellen Grenzen? Was wurde bereits versucht oder erwogen?_
## Kunden-Kontext
_Wer ist der Kunde (wer zahlt, wer entscheidet den Kauf)? Was sind seine Herausforderungen, Entscheidungskriterien, Einschränkungen? Was motiviert oder blockiert den Kauf? Antwortet dieses Thema auf einen Bedarf, den der Kunde zu zahlen bereit ist?_
_(→ Risiko des Werts aus Käufersicht)_
## Nutzer-Kontext
_Wer nutzt das Produkt täglich? Welche Nutzungsweisen heute? Welche bekannten Pain Points? Wird der Nutzer die Lösung verstehen und annehmen? Unterschiede je nach Segmenten oder Rollen?_
_(→ Wertrisiko + Nutzbarkeitsrisiko)_
## Technischer Kontext
_Welche technischen Informationen sind nützlich? Können wir mit unseren Kompetenzen, unserem Stack und unseren Fristen das Vorgesehene bauen? Daten- oder Tracking-Einschränkungen? Wichtige Abhängigkeiten?_
_(→ Machbarkeitsrisiko)_
## Branchenregeln
_Welche Branchenregeln bestehen bereits in unserem CMMS zu diesem Thema? Wie handhaben das unsere Kunden heute in ihren Prozessen? Validierungs-, Berechnungs-, Rechte- und Workflow-Logiken, die bereits vorhanden sind?_
## Normen und Regulierung
_Welche Normen (ISO, EN, NF…) oder regulatorischen Verpflichtungen gelten? Welche Auswirkungen haben sie auf das, was wir bauen können oder müssen? Gibt es Rückverfolgbarkeits-, Compliance- oder Audit-Anforderungen?_
## Kultur und Feldpraktiken
_Wie arbeiten die Feldteams wirklich? Welche Gewohnheiten je nach Branche (Industrie, Dienstleistungen, Gesundheit…) oder Unternehmensgröße? Welche Wahrnehmungen, Widerstände oder spezifischen Erwartungen sind zu berücksichtigen?_
## Wettbewerb und aktuelle Alternativen
_Wie lösen Kunden dieses Problem heute? Welcher Wettbewerber, welches interne Tool, welcher manuelle Prozess (Excel, Papier…)? Was funktioniert oder funktioniert nicht bei diesen Alternativen?_
## Geschichte und Entscheidungen
_Bereits getroffene Entscheidungen zu diesem Thema? Nützliche historische Abwägungen? Punkte, die ohne triftigen Grund nicht wieder geöffnet werden sollten?_
Mehr dazu
Der PM als Kontext-Architekt Wettbewerbsbeobachtung: die Konkurrenz zu kopieren ist keine Strategie KI-Wiki: warum ich eine KI-gepflegte Wissensbasis aufgebaut habe