Viele Produkttexte gehen immer noch davon aus, dass die besten Lehren aus Skalierung, Finanzierung und gut ausgestatteten Teams stammen.

Ich halte das nicht für richtig.

Einige der nützlichsten Produktlektionen, die ich gelernt habe, entstanden beim Aufbau unter sehr wenig Fehlertoleranz: knappe Budgets, verschobene Fristen, überall manuelle Prozesse und Folgen, die schnell sichtbar wurden, wenn die Reihenfolge falsch war.

Das war das Umfeld, in dem ich an einer Plattform für Hochschulverwaltung in Nigeria gearbeitet habe.

Dabei handelte es sich nicht um ein Produkt, bei dem eine verfehlte Priorität nur ein etwas schwächeres Quartal oder ein verzögertes Feature bedeutete. Wenn Zulassungen nicht rechtzeitig bearbeitet wurden, konnten Studierende ihren Platz verlieren. Wenn die Gebühreneinzug nicht sauber konzipiert war, versickerte Umsatz. Wenn Reporting erst später ergänzt wurde, musste das Management auf Basis unvollständiger Sicht entscheiden.

Und als COVID den Präsenzbetrieb störte, war die eigentliche Prüfung nicht, ob die Plattform elegant war. Entscheidend war, ob sie schnell genug mitwachsen konnte, um die Institution am Laufen zu halten.

Aus dieser Erfahrung entstand das CAPE-Modell: Crisis-first priorisation, Architecture as incentive, Parallel data infrastructure und Extensibility by design.

Es ist keine universelle Methode und keine perfekte Formel. CAPE ist ein pragmatischer Ansatz für Teams unter Druck, bei dem die richtige Reihenfolge der Entscheidungen wichtiger ist als ein perfekter Plan.

C – Crisis-First Prioritisation

Die meisten Teams geben an, nach Wert und Aufwand zu priorisieren, was bis zu einem gewissen Grad funktioniert. Doch diese Logik gerät ins Wanken, wenn ein einzelner ungelöster Fehler alles andere irrelevant machen kann.

Das war bei den Zulassungen die Realität.

Damals erfolgte das Onboarding neuer Studierender größtenteils manuell. Sie mussten Zulassung und Registrierung mit Papierformularen, verstreuten Prüfungen und Unterstützung durch Mitarbeitende an nahezu jeder Station durchlaufen. Einige reisten weit an, viele standen unter engen Fristen. Wenn das System diesem Druck nicht standhielt, blieben Studierende außen vor. Deshalb stand das Onboarding zuerst.

Nicht, weil es der innovativste Teil der Plattform war. Nicht, weil es auf einer Roadmap am besten aussah. Sondern weil es der Punkt mit dem größten Ausfallrisiko war. Wenn dieser Prozess scheiterte, war der Rest der Plattform unerheblich.

Das ist das erste CAPE-Prinzip: nicht mit der größten Chance beginnen. Beginnen Sie mit dem Fehler, der den größten Schaden anrichten würde, wenn er nicht sofort behoben wird.

Das klingt einfach. In der Praxis fühlt es sich selten einfach an. Teams sind oft versucht, Aufwand auf mehrere sichtbare Bedürfnisse zu verteilen, besonders wenn Stakeholder in unterschiedliche Richtungen ziehen. Unter Restriktionen kann diese Verteilung von Aufmerksamkeit jedoch zu einer getarnten Form des Ausweichens werden. Es wirkt ausgewogen. Meist schwächt es die Lieferung.

Die Restriktion zwang zu einer unbequemeren Frage: Wenn wir zuerst nur eine Sache richtig lösen, was muss das sein?

Diese Frage bleibt auch in besser finanzierten Umfeldern wichtig. Die Teams, die sie ehrlich beantworten, bauen meist stärkere erste Releases. Die anderen landen häufig mit breiteren Roadmaps und schwächeren Fundamenten.

Wenn der erste Release den teuersten Ausfall nicht stabilisiert, ist er wahrscheinlich der falsche erste Release.

A – Architecture as Incentive

Eines der hartnäckigsten Probleme der Universität war die Nichtbefolgung der Gebührenzahlung, was ein zentrales Designproblem darstellte.

Anstatt Zahlung als administrative Aufgabe neben der akademischen Laufbahn zu behandeln, machten wir sie strukturell. Zahlung schaltete die Registrierung frei. Registrierung schaltete die Prüfungsberechtigung frei. Keine Zahlung, kein Fortschritt.

Einfach. Aber tragend.

Diese Entscheidung veränderte die Logik der Plattform. Der Fokus verschob sich von der Aufforderung zur Befolgung hin zum Systemfluss. Dieser Unterschied ist wichtiger, als viele Teams erkennen.

Viele Produktentscheidungen rund um Verhalten werden weiterhin als Messaging-Problem behandelt. Doch wenn das Verhalten geschäftskritisch ist, leistet die Architektur meist mehr als Überzeugung je könnte.

Das meine ich mit Architecture as Incentive. Das System so gestalten, dass das richtige Verhalten in die Abfolge eingebaut ist.

Die Einhaltung der Gebührenzahlung verbesserte sich deutlich, nachdem diese Abhängigkeit in die Plattform integriert worden war. Die größere Lehre war jedoch: Wenn ein Produkt von einem bestimmten Verhalten abhängt, sollte die Architektur einen Teil dieser Last tragen.

Wenn Verhalten wichtig ist, entfernen Sie Wahlmöglichkeiten, bevor Sie Erinnerungen hinzufügen.

P – Parallel Data Infrastructure

Hier lassen viele Produkte das Management im Stich. Der Workflow funktioniert, Nutzer erledigen ihre Aufgaben, und Transaktionen laufen durch. Doch die Institution sieht trotzdem nicht, was wirklich geschieht.

Genau das war hier der Fall. Die Stakeholder hatten keinen einheitlichen Blick auf den gesamten Prozess.

Unter Lieferdruck ist es leicht, zuerst den Workflow auszurollen und Reporting auf später zu verschieben. Es wirkt effizient. Ist es nicht. Die dadurch entstehenden blinden Flecken kosten mehr, als sie an Zeit sparen.

Also bauten wir Reporting parallel zu den Workflows.

Das veränderte die Entscheidungsfindung. Das Management konnte die Umsatzlage klarer sehen. Es konnte Registrierungen nach Studiengang und Level sehen. Es konnte erkennen, wo sich Zahlungs- und Einschreibungsmuster verschoben, bevor diese Verschiebungen zu operativen Problemen wurden.

Das ist das dritte CAPE-Prinzip: Wenn ein Workflow operativ wichtig ist, sollte er zugleich analytisch wichtig sein.

Ein Produkt, das während des Betriebs nicht sauber beobachtet werden kann, erzeugt ein Risiko zweiter Ordnung. Entscheidungen werden dann auf Basis verzögerter Annahmen statt aktueller Evidenz getroffen. Anschließend verbringen Teams Monate damit, Sichtbarkeit auszugleichen, die sie von Anfang an hätten einbauen sollen.

Ein Workflow ohne Instrumentierung ist operativ live, aber strategisch blind.

Bauen Sie Workflow und Sichtbarkeitsmodell gemeinsam. Bitten Sie das Management nicht, blind zu steuern, und versprechen Sie das Dashboard später.

E – Extensibility by Design

Mit der Zeit bauten wir die Plattform mit robuster Funktionalität weiter aus, sodass sie zentrale Universitätsaufgaben wie Zulassung, Gebührenzahlungen, Registrierung, Prüfungen und Transkripte abdecken konnte.

Dann kam COVID.

Über Nacht änderte sich alles. Fragen rund um Registrierung, Prüfungen, Gebühren und verwandte Prozesse traten in den Hintergrund, denn wenn Studierende nicht lernten, brauchten sie diese Funktionen nicht. Unser Fokus verlagerte sich darauf, ob die Plattform sich schnell genug anpassen konnte, um den Betrieb aufrechtzuerhalten, als Präsenzunterricht und Betrieb stoppten.

Die Plattform unterstützte Zulassung, Gebührenzahlungen, Prüfungen und Transkripte, aber es gab keine Lernfunktion. Diese Lücke wurde unser Schwerpunkt. Die Frage war sofort da: Lernfunktion von Grund auf neu entwickeln oder ein LMS schnell genug integrieren, um die Universität am Laufen zu halten?

Die Studierenden waren zu Hause. Der Unterricht war zum Erliegen gekommen. Die Einnahmen waren gesunken. Die Institution brauchte nicht die perfekte Antwort. Sie brauchte die schnellste tragfähige Lösung.

Wir entschieden uns für Integration wegen einer früheren Architekturentscheidung: Wir hatten mit genug Modularität gebaut, um neue Funktionen aufnehmen zu können, ohne alles neu aufzubauen. Keine unendliche Flexibilität. Nur genug Offenheit, um den nächsten Schritt möglich zu machen.

Das ist Extensibility in der Praxis.

Es bedeutet nicht, für jede mögliche Zukunft zu bauen; das führt zu Überengineering. Extensibility by design bedeutet, genug Raum für die nächste reale Veränderung zu lassen, ohne bei jeder Änderung den Kern neu aufbauen zu müssen.

Das ist wichtig, weil Produktteams Erweiterbarkeit oft als optional behandeln, bis der Tag kommt, an dem sie dringend wird. Dann ist sie teuer.

Die LMS-Integration wurde in vier Monaten geliefert. Die akademische Kontinuität wurde wiederhergestellt. Die Einnahmen erholten sich innerhalb desselben Zyklus deutlich. Die größere Lehre war jedoch architektonisch: Die Systeme, die externe Schocks überstehen, sind nicht immer die, die sie vorausgesehen haben. Es sind die, die nicht zu starr gebaut wurden, um reagieren zu können.

Bauen Sie für die nächste reale Herausforderung, nicht für jedes mögliche Szenario.

CAPE ist nicht deshalb wertvoll, weil es sich gut anhört. Es ist wertvoll, weil die Reihenfolge trägt.

Jedes schnell wachsende Produkt trifft auf seine eigene Version der Zulassung: ein einzelner Ausfallpunkt, der die Roadmap zu Fall bringt, wenn er nicht zuerst gelöst wird, und alles danach ist im Vergleich verhandelbar. Jedes Produkt mit einem umsatzkritischen Verhalten trifft auf seine eigene Version des Zahlungstors: etwas, von dem das Geschäft abhängt, das entweder in die Architektur eingebaut wird oder endlos mit Erinnerungen verfolgt wird.

Jedes Team trifft auf seine eigene Version des Reporting-Problems: Das Management fliegt blind, weil Sichtbarkeit zugunsten des Ausrollens des Workflows verschoben wurde. Und jedes Produkt erlebt irgendwann sein eigenes COVID: den nicht geplanten Schock, der prüft, ob das Gebaute sich biegen kann oder bricht.

Darum ist CAPE übertragbar. Restriktion hat nicht wirklich mit Budget zu tun. Es geht um das Verhältnis zwischen dem, was wahr sein muss, und dem, was Sie sich leisten können, falsch zu machen. Dieses Verhältnis zeigt sich bei einer engen Finanzierungsrunde, einer harten regulatorischen Frist, einem schlanken internen Tool-Team oder einem Startup mit sechs Monaten Runway. Unterschiedlicher Druck. Gleiche Disziplin erforderlich.

Wenn ich ehrlich bin, ist das am schwersten umzusetzende Prinzip Architecture as Incentive. Crisis-first prioritisation ist eine Entscheidung, die man einmal zu Beginn trifft. Extensibility ist eine Gewohnheit, die man über Zeit in seine Standards einbauen kann. Architecture as incentive verlangt etwas Schwierigeres: genug Überzeugung, um ein Verhalten im Produkt selbst unverhandelbar zu machen, statt es downstream mit einem Hinweis oder einer Kampagne zu lösen.

Das ist ein schwieriges Gespräch mit Stakeholdern, denen es leichter fällt, Nutzer höflich zu bitten, als ihnen Optionen zu nehmen. Es ist auch das Prinzip, das in einem Design Review am ehesten verwässert wird, weil „lassen Sie uns einfach eine Erinnerung hinzufügen“ immer die bequemere Wahl zu sein scheint. Meist ist es nicht die richtige.

Wenn Sie bereits lean bauen, in Lagos, in Westafrika, in einem Markt, in dem „wir hatten nicht das Budget, es anders zu machen“ kein Talking Point, sondern ein Dienstag ist, dann sage ich Ihnen nicht, dass Restriktion gut für Sie ist. Das wissen Sie bereits.

Was ich behaupte, ist enger gefasst und meines Erachtens nützlicher. Restriktion allein erzeugt keine Disziplin. Sie erzeugt Druck. Was Sie mit diesem Druck tun, ist eine andere Frage, und es ist durchaus möglich, unter echter Restriktion zu bauen und dennoch die Reihenfolge falsch zu wählen, weil die meisten Ratschläge für schlanke Teams nicht für schlanke Teams geschrieben wurden. Sie wurden von Menschen mit Puffer für Menschen mit Puffer geschrieben.

„Schnell shippen, Compliance später hinzufügen“ ist kein schlechter Rat. Es ist ein Rat für jemanden, der sich die späteren Kosten leisten kann. Verschiebt dieselbe Entscheidung ohne eine Finanzierungsrunde im Rücken, bedeutet später meist nie – oder einen Notfall, der zehnmal so teuer ist wie die Entscheidung beim ersten Mal gewesen wäre.

Jede in diesem Text verschobene Entscheidung – Zahlung als optional behandeln, Reporting später bauen, die für Erweiterbarkeit nötige Modularität auslassen – ist genau diese Art von übernommener Empfehlung. Sie klingt effizient, bis es kein späteres Budget mehr gibt, das die Kosten der Verschiebung auffängt.

CAPE ist mein bewusster Versuch, das zu benennen, was die meisten von uns unter Termindruck zufällig lernen. Nicht die Behauptung, dass Restriktion Charakter bildet. Sondern eine Möglichkeit, vor dem Ausrollen zu prüfen, ob man stillschweigend eine Reihenfolgeentscheidung übernommen hat, die nur für die Bilanz eines anderen Sinn ergibt.

Diese Disziplin ist es wert, auch dann beizubehalten, wenn die Restriktion nachlässt. Die meisten von uns versuchen nicht, Restriktion loszuwerden, um endlich so nicht mehr denken zu müssen. Wenn die Finanzierung kommt, geht es nicht darum, die Instinkte zu verlieren, die einen bis hierher gebracht haben.

Siehe auch: FUTA ehrt einen vom Absolventen zum Cybersecurity-Unternehmer gewordenen Alumni, während die Universität eine wegweisende internationale Computing-Konferenz ausrichtet