Thema 5.0 — Produktgeführte Arbeit

In einem Satz: Produktgeführte Arbeit finanziert dauerhafte, befähigte Teams, die einen Dienst über sein ganzes Leben verantworten und für messbare Ergebnisse rechenschaftspflichtig sind statt dafür, eine feste Liste von Funktionen zu liefern.

Warum das in Gesundheit und Pflege wichtig ist#

Das Meiste, was Organisationen der digitalen Gesundheit und Pflege betreiben, ist keine einmalige Lieferung – es ist ein lebender Dienst. Die NHS App, eine elektronische Patientenakte, eine gemeinsame Patientenakte, ein E-Überweisungspfad, ein Fallmanagementsystem der Sozialpflege: Nichts davon ist „fertig“. Sie müssen fortlaufend verbessert werden, wenn sich klinische Leitlinien ändern, Sicherheitsvorfälle auftauchen, sich die Nachfrage verschiebt und sich die Landschaft um sie herum weiterentwickelt.

Wenn Sie einen lebenden Dienst als Reihe unverbundener Projekte führen, erhalten Sie einen vorhersehbaren Fehler: Ein Lieferant baut nach einer Spezifikation, das Geld geht aus, das Team löst sich auf, und der Dienst wird bis zum nächsten Kapitalantrag dem Verfall überlassen. Klinikpersonal umgeht die Lücken, Risiken für die Patientensicherheit häufen sich, und Gleichstellung leidet, weil die Menschen, die einen klobigen Dienst am wenigsten ertragen können, jene mit dem größten Bedarf sind. Produktgeführte Arbeit existiert, um diesen Kreislauf zu durchbrechen. Sie hält ein stabiles Team nah an Nutzenden und an Ergebnissen, sodass der Dienst mit der Zeit sicherer, nutzbarer und gerechter wird, statt zwischen Finanzierungsrunden zu verfallen.

Der Einsatz ist auch finanziell und gesetzlich. Öffentliches Geld ist besser geschützt durch ein Team, das fortlaufend prüft, ob ein Dienst die Versorgung tatsächlich verbessert, als durch ein Projekt, das Erfolg als „pünktlich und im Budget geliefert“ misst, unabhängig davon, ob jemand profitierte. Dieses Thema steht neben Thema 5.1 — Projektgeführte Arbeit und Thema 5.2 — Programmgeführte Arbeit; die drei sind ergänzende Werkzeuge, keine Rivalen, und Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM) erklärt, wie man sie zusammenhält.

Kernkonzepte#

Dauerhaftes Produktteam. Ein funktionsübergreifendes, langlebiges Team, das ein Produkt oder einen Dienst über seinen gesamten Lebenszyklus verantwortet. Das Team bleibt bestehen; die Arbeit fließt zu ihm. Das ist die atomare Einheit des Produktbetriebsmodells, das Marty Cagan und die Silicon Valley Product Group (SVPG) beschreiben: eine stabile Gruppe aus einer Produktmanagerin, einem Produktdesigner und Entwicklerinnen, im Gesundheitskontext von klinischer und Datenexpertise unterstützt.

Befähigtes Team. Cagan zieht eine scharfe Linie zwischen einem „Feature-Team“, dem eine Roadmap mit zu bauenden Dingen übergeben wird, und einem „befähigten Team“, dem zu lösende Probleme und zu erreichende Ergebnisse übergeben werden und dem man zutraut, die beste Lösung zu finden. Befähigung ist keine Lizenz, alles zu tun; sie ist Rechenschaftspflicht für Ergebnisse innerhalb eines klaren strategischen Rahmens.

Ergebnisse statt Outputs. Output ist, was Sie ausliefern – ein Feature, ein Release, ein Bildschirm. Ein Ergebnis (Outcome) ist die daraus folgende Veränderung in der Welt – weniger versäumte Termine, schnellere Entlassung, weniger Medikationsfehler, gerechtere Inanspruchnahme. Produktgeführte Arbeit misst Teams an Ergebnissen, denn ein Feature auszuliefern, das niemand nutzt oder durch das niemand sicherer wird, ist als Fortschritt verkleidete Verschwendung.

Produktmanagerin. Die Leitung des Produktmanagements, rechenschaftspflichtig für Wert und Tragfähigkeit des Produkts: Lohnt es sich zu bauen, werden Menschen es nutzen, passt es zu Strategie, Regulierung und Finanzen der Organisation? In Gesundheit und Pflege muss diese Rolle eng mit den Verantwortlichen für klinische Sicherheit und Informationsgovernance zusammenarbeiten, nicht über ihnen sitzen.

Produktbetriebsmodell. SVPG stellt klar, dass dies ein Modell ist, keine Methodik oder starres Framework: ein Satz von Prinzipien dazu, wie ein Unternehmen technologiegestützte Produkte baut und betreibt – befähigte Teams, Verantwortung für Ergebnisse, kontinuierliche Discovery und Produktstrategie –, statt eines vorgeschriebenen Prozesses, den man installiert.

Produktlebenszyklus. Discovery (gibt es ein echtes Problem, das zu lösen sich lohnt?), Lieferung (sicher und gut bauen), Wachstum und Optimierung (Annahme und Ergebnisse verbessern) und schließlich Auslauf (elegant stilllegen oder ersetzen). Produktgeführte Teams verantworten alles davon, weshalb sie sinnvolle Abwägungen über das ganze Leben treffen können, die ein Projektteam nicht treffen kann.

Bewährte Praktiken#

1. Finanzieren Sie das Team, nicht das Projekt. Verlagern Sie Geld von befristeten Projektbudgets zu ständigen Produktbudgets, die an einen Wertstrom gebunden sind, wie Mik Kersten in Project to Product argumentiert. Finanzieren Sie ein dauerhaftes Team, das über aufeinanderfolgende Planungszyklen Ergebnisse verfolgt, und geben Sie die Finanzierung anhand nachgewiesener Resultate neu frei, nicht anhand eines Meilensteinplans, der Jahre zuvor vereinbart wurde.

2. Geben Sie Teams Probleme und Ergebnisse, keine Funktionslisten. Formulieren Sie das Mandat als „die Nichterscheinensrate in der Ambulanz senken“ oder „die Zeit verkürzen, die Klinikpersonal mit der Suche nach einem Ergebnis verbringt“, und lassen Sie das befähigte Team die beste Lösung entdecken. Eine von oben herabgereichte Roadmap zugesagter Funktionen stellt das Feature-Team-Antimuster wieder her, vor dem Cagan warnt.

3. Machen Sie Ergebnismaße explizit und klinisch bedeutsam. Vereinbaren Sie vorab einen kleinen Satz von Ergebniskennzahlen, idealerweise als Objectives and Key Results (OKRs – siehe Thema 7.3). Koppeln Sie jede Effizienzkennzahl mit einer Sicherheits- und einer Gleichstellungskennzahl, damit ein Team nie für Tempo auf Kosten von Schaden oder wachsender Ungleichheit belohnt wird.

4. Halten Sie das Team nah an realen Nutzenden. Verankern Sie kontinuierliche Discovery: regelmäßiger Kontakt mit Klinikpersonal, Pflegekräften, Verwaltungsmitarbeitenden und Patientinnen. Das NHS Service Manual und das GOV.UK Service Manual machen beide Nutzerforschung zu einer ständigen Disziplin, nicht zu einer einmaligen Phase. Ein dauerhaftes Team macht das bezahlbar, weil die Beziehungen bestehen bleiben.

5. Bauen Sie multidisziplinäre Teams mit klinischer Sicherheit in ihrem Inneren. Ein digitales Gesundheitsproduktteam braucht neben Produkt/Design/Entwicklung eine klinische Sicherheitsbeauftragte (DCB0129/DCB0160), Informationsgovernance und Datenexpertise. Sicherheit und Governance sind Designeingaben, die im Team verantwortet werden, keine am Ende aufgesetzten Tore.

6. Versehen Sie das Produkt mit Messpunkten und handeln Sie nach den Daten. Dauerhafte Teams können in Telemetrie investieren, sodass Entscheidungen auf realer Nutzung und realen Ergebnissen beruhen statt auf Meinung. Beobachten Sie die Annahme nach Kohorte, um digitale Ausgrenzung früh zu erkennen.

7. Verantworten Sie den gesamten Lebenszyklus, einschließlich des Auslaufs. Befähigte Teams planen elegante Stilllegung und Migration, nicht nur den Start. Zu entscheiden, nicht weiterzubauen und sich auf eine strategische Plattform zu konsolidieren, ist eine legitime und wertvolle Produktentscheidung.

8. Richten Sie Teams durch Strategie aus, nicht durch Mikromanagement. Autonomie ohne Ausrichtung erzeugt lokale Optimierung und Chaos. Eine klare Produktvision und -strategie – und im großen Maßstab ein Portfolio- und Programmrahmen (Themen 5.2 und 5.3) – ist das, was Sie Teams sicher befähigen lässt.

Fragen zur Diskussion im Team#

1. Welche der Dienste, die wir heute betreiben, sind wirklich lebende Dienste, die ein dauerhaftes, finanziertes Produktteam verdienen, und welche sind endliche Arbeit, für die wir nur vorgeben, sie brauche eines? Das ist die grundlegende Sortierfrage, und sie in eine der beiden Richtungen falsch zu beantworten ist teuer. In einer Organisation der digitalen Gesundheit und Pflege ist der Bestand eine Mischung – eine gemeinsame Patientenakte oder die patientenorientierte App ist ein lebender Dienst, ein einmaliger Rechenzentrumsausstieg oder ein Hardwaretausch ist wirklich endlich –, und die ehrliche Antwort verlangt, jedes bedeutende System zu benennen und seinen Fall zu vertreten, statt überall ein Finanzierungsmodell anzuwenden. Die Spannung ist, dass Finanz- und Governance-Maschinerie meist alles zu befristeten Kapitalanträgen drängt, sodass etwas „Produkt“ zu nennen wie Sonderpleidoyer wirken kann, während ein lebender Dienst als „Projekt“ zu bezeichnen still den zuvor im Thema beschriebenen Verfall nach dem Muster bauen-und-verlassen garantiert. Bedenken Sie die Kosten über das ganze Leben, das Tempo, in dem sich klinische Leitlinien und Nachfrage um den Dienst herum ändern, und ob Risiken für die Patientensicherheit sich häufen, wenn niemand kontinuierliche Verbesserung verantwortet. Eine gute Antwort benennt zwei oder drei Dienste, bei denen ein dauerhaftes Team klar gerechtfertigt ist, ist offen über Grenzfälle und parkt endliche Arbeit ausdrücklich bei Thema 5.1, statt eine pauschale Richtlinie zu verteidigen.

2. Welche zwei oder drei Ergebniskennzahlen würden wir tatsächlich zur Grundlage der Finanzierung eines Teams machen, und wie koppeln wir jede mit einem Sicherheits- und einem Gleichstellungsmaß, damit wir nie für Tempo auf Kosten von Schaden belohnt werden? Ergebnisse statt Outputs ist leicht gesagt und schwer umzusetzen, denn in dem Moment, in dem eine Kennzahl Geld steuert, beginnt sie Verhalten zu verzerren. Ein Team der digitalen Gesundheit, dem gesagt wird, „die Nichterscheinensrate senken“, kann die Zahl erreichen, indem es die digital selbstsichersten Patientinnen anstößt und die Lücke für ältere oder ärmere Kohorten still vergrößert – die Debatte muss also ans Licht bringen, welche einzelne Effizienzkennzahl jedes Team übermäßig optimieren könnte und was die gekoppelte Sicherheits- und Gleichstellungsleitplanke tatsächlich misst. Bringen Sie konkrete Kandidaten auf den Tisch (weniger Medikationsfehler, schnellere Entlassung, Inanspruchnahme nach Ort oder digitalem Zugangs-Proxy) und prüfen Sie hart, ob sie klinisch bedeutsam oder nur leicht zu instrumentieren sind. Bedenken Sie, wem jede Kennzahl gehört, was die Baseline ist und wie oft sie überprüft wird, denn ein unverantwortetes oder ohne Baseline geführtes Ergebnis ist Dekoration. Eine ehrliche Antwort akzeptiert, dass manche Ergebnisse, die uns wichtig sind, langsam oder schwer zu messen sind, widersteht dem Sog zu Eitelkeits-Annahmezahlen und verpflichtet sich, das Gleichstellungsmaß neben dem Effizienzmaß zu veröffentlichen, damit der Zielkonflikt sichtbar bleibt.

3. Wie viel echte Befugnis sind wir bereit, einem befähigten Team zu geben, die Richtung zu ändern, und welcher strategische Rahmen verhindert, dass diese Autonomie in lokale Optimierung zerfällt? Befähigung ist der Kern des Produktbetriebsmodells und zugleich seine häufigste Fälschung, denn Organisationen etikettieren Teams als „Produktteams“ um und reichen ihnen weiter eine feste Roadmap herab und messen Lieferung. Die eigentliche Frage ist, wo die Grenze liegt: Kann ein Team von einem vom Vorstand geförderten Feature zu einer anderen Lösung wechseln, wenn die Discovery zeigt, dass sie das Ergebnis besser realisiert, oder werden klinische Governance, Informationsgovernance und bestehende Lieferantenverträge das in der Praxis vetieren? Die Spannung ist, dass Autonomie ohne Ausrichtung über ein ICS hinweg Duplikation und Drift erzeugt, während als Mikromanagement durchgesetzte Ausrichtung die Feature-Fabrik wiederherstellt – die Antwort liegt also in einer expliziten Produktvision und -strategie und im großen Maßstab einem Portfolio-Rahmen, der begrenzt, ohne zu diktieren. Bedenken Sie eine jüngste Entscheidung, bei der ein Team den Kurs ändern wollte, und fragen Sie ehrlich, ob das System es zuließ. Eine gute Antwort definiert die Entscheidungen, die ein Team allein treffen darf, gegenüber denen, die Eskalation brauchen, benennt das Strategiedokument, das den Rahmen liefert, und ist offen, wo die Organisation derzeit Kontrolle mit Ausrichtung verwechselt.

4. Wie finanzieren und verteidigen wir ein dauerhaftes Team durch den jährlichen Haushaltszyklus, und was werden wir tatsächlich tun, wenn die Finanzabteilung von uns verlangt, ein „Produkt“ ohne festes Enddatum zu rechtfertigen? Produktgeführte Arbeit steht und fällt mit Geld, und die Maschinerie der NHS- und öffentlichen Finanzen ist auf befristete Kapitalanträge gebaut, nicht auf rollierende Betriebsfinanzierung, die an einen Wertstrom gebunden ist – diese Frage erzwingt daher das unbequeme operative Detail hinter „das Team finanzieren, nicht das Projekt“. Die Spannung ist, dass ein dauerhaftes Team mehrjährige Stabilität braucht, um knappe klinische, Produkt- und Entwicklungsfachleute zu halten, die Zuweisung, von der es abhängt, aber jedes Jahr neu erkämpft wird gegen Kapitalvorhaben, die einen ordentlichen Anfang und ein ordentliches Ende zeigen. Bringen Sie die realen Zahlen: was die ständigen Kosten des Teams sind, welchem Wertstrom es zugeordnet ist und welche Evidenz nachgewiesener Ergebnisse eine Neufreigabe gegenüber einem Jahre zuvor vereinbarten Meilensteinplan rechtfertigen würde. Bedenken Sie, wie Regeln der Kapital-versus-Betriebskosten-Bilanzierung, Beschaffungszyklen und Lieferantenverträge das Modell in Ihrer Organisation entweder unterstützen oder bekämpfen. Eine ehrliche Antwort benennt, wer das rollierende Budget abzeichnet, was in einem schlechten Haushaltsjahr mit dem Team geschieht und ob die Organisation bereit ist, einen echten Dienst in eine Produktlinie umzuwandeln, statt ihn still wieder zu Projektanträgen zurückfallen zu lassen.

5. Wenn produktgeführte Arbeit auf unsere Pflichten zu klinischer Sicherheit und Informationsgovernance trifft, sind Sicherheit und Governance wirklich als Designeingaben im Team, oder sind sie noch Tore, auf die das Team zurast und um die es herum verhandelt? Ein dauerhaftes, befähigtes Team, das kontinuierlich ausliefert, verändert das Risikobild, denn jede Iteration ist ein potenzielles Ereignis der klinischen Sicherheit und des Datenschutzes statt einer einzelnen Freigabe am Ende eines Projekts – DCB0129/DCB0160-Gefährdungsarbeit und DPIAs müssen daher im Takt des Teams leben, nicht an einem Release-Tor aufgesetzt werden. Die Spannung ist real: Eine klinische Sicherheitsbeauftragte und eine IG-Leitung in jedem Produktteam zu verankern ist teuer, und diese Fähigkeiten sind knapp, sodass Organisationen versucht sind, sie dünn zu teilen oder Assurance als Genehmigung zu behandeln, die das Team spät einholt. Genau diese Versuchung stellt das Versagen nach dem Muster bauen-und-verlassen für die Sicherheit wieder her, denn ein Team, das unter Lieferdruck eine Ergebniskennzahl optimiert, wird ohne interne Sicherheitsstimme Schaden erst entdecken, nachdem er Patientinnen erreicht hat. Bedenken Sie, wie der Sicherheitsfall über viele kleine Releases lebendig gehalten wird, wem das Gefährdungsprotokoll gehört und ob Governance-Kolleginnen echten Einfluss auf Discovery und Priorisierung haben oder nur ein Veto am Ende. Eine gute Antwort ist offen, wo Sicherheit derzeit ein Tor statt einer Designeingabe ist, und verpflichtet sich zu der Besetzung und dem Takt, die kontinuierliche Assurance bezahlbar machen.

6. Wie halten wir ein dauerhaftes Team wirklich nah an unterversorgten Nutzenden, sodass kontinuierliche Verbesserung digitale Ausgrenzung verringert statt vergrößert? Produktgeführte Arbeit verspricht Gleichstellung als erstklassiges Ergebnis, doch ein stabiles Team, das sein eigenes Produkt mit Messpunkten versieht, hört naturgemäß am lautesten von den Nutzenden, die ohnehin teilnehmen – den digital Selbstsicheren, den Vernetzten, denen, die in der Telemetrie auftauchen –, sodass Nähe zu Nutzenden still zu Nähe zu den leichten Nutzenden werden kann. Die Spannung ist, dass die am stärksten von Ausgrenzung bedrohten Kohorten (ältere Patientinnen, Menschen in benachteiligten Orten, solche mit geringem digitalem Zugang oder Sprachbarrieren) durch kontinuierliche Discovery am schwersten und teuersten zu erreichen sind, obwohl sie genau die Menschen sind, denen ein öffentlicher Gesundheitsdienst dient. Bringen Sie konkrete Praxis auf den Tisch: welche Kohorten gezielt in die Forschung rekrutiert werden, wie Annahme nach Ort und digitalem Zugangs-Proxy beobachtet wird und welcher nicht digitale Rückfall existiert, wenn der digitale Weg jemanden zurücklässt. Bedenken Sie, ob die Gleichstellungskennzahl des Teams tatsächlich Entscheidungen verändert oder nur berichtet wird. Eine ehrliche Antwort räumt ein, wo der aktuelle Forschungspool zu den leicht Erreichbaren neigt, benennt die unterversorgten Gruppen, von denen es noch nicht hört, und beschreibt die konkrete Investition – Outreach, assistierte digitale Nutzung, telefonischer Rückfall –, die verhindert, dass Verbesserung Vorteile potenziert.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) betreibt eine patientenorientierte Terminmanagement-App, die über mehrere Trusts hinweg genutzt wird. Historisch war jede Verbesserung ein eigenes Projekt: Ein Lieferant wurde beauftragt, „SMS-Erinnerungen hinzuzufügen“, lieferte sie und ging. Sechs Monate später lösten die Erinnerungen falsch aus, niemand verantwortete die Korrektur, und ein Kapitalantrag war nötig, um den Vertrag wieder zu öffnen.

Das ICS wechselt zu einem produktgeführten Modell. Es richtet ein dauerhaftes Produktteam ein – eine Produktmanagerin, einen Designer, vier Entwicklerinnen, eine klinische Sicherheitsbeauftragte und eine IG-Leitung –, rollierend finanziert und mit einem Ergebnis statt einer Funktionsliste mandatiert: die Nichterscheinensrate (Did-Not-Attend, DNA) senken und die Gleichheit des Zugangs über die Bevölkerung verbessern.

Das Team führt kontinuierliche Discovery mit Patientinnen und Terminplanern der Ambulanz durch. Es lernt, dass Erinnerungen helfen, der größere Treiber von DNAs in einem benachteiligten Ort aber ist, dass Patientinnen nicht leicht umbuchen können und den Termin daher schlicht verpassen. Weil das Team das Ergebnis verantwortet statt einer Spezifikation, verlagert es die Investition von einem glänzenden Benachrichtigungs-Feature zu einem einfachen Selbst-Umbuchungsablauf, und es versieht die Annahme mit Messpunkten nach Ort und digitalem Zugangs-Proxy.

Über drei Planungszyklen sinkt die DNA-Rate, und – entscheidend – das Team überwacht die Gleichstellungskennzahl und bemerkt, dass die Annahme bei älteren Patientinnen hinterherhinkt, was einen telefonischen Rückfallweg auslöst, damit der digitale Weg Ungleichheit nicht vergrößert. Die Finanzierung geht weiter, weil die Ergebnisse nachweisbar sind. Kein Feature wurde je „abgenommen und verlassen“; der Dienst verbessert sich einfach weiter. Als eine nationale Plattform später dieselbe Fähigkeit anbietet, führt dasselbe Team die Migration durch und lässt seine eigene Komponente auslaufen – eine Entscheidung über das ganze Leben, für die ein Projektteam nie in der Position gewesen wäre.

Sektorperspektiven#

Startup#

In einem kleinen Unternehmen der digitalen Gesundheit ist produktgeführte Arbeit der Standardmodus – oft der einzige: Ein einziges befähigtes Team, manchmal das ganze Unternehmen, verantwortet das Produkt von Anfang bis Ende. Finanzierung ist die bindende Beschränkung, denn Investoren-Runway oder Fördergeld bedeuten, dass das Team schnell genug Ergebnis-Traktion (Annahme, Bindung, ein frühes klinisches Signal) zeigen muss, um die nächste Runde zu rechtfertigen; kontinuierliche Discovery und Messpunkte sind daher Überlebenswerkzeuge, kein Luxus. Die Risikobereitschaft ist hoch, und die Rechenschaft läuft zu Gründerinnen und Investoren, nicht zu einem Vorstand oder der Öffentlichkeit, sodass das Team in Tagen schwenken kann. Die Falle ist, klinische Sicherheit und Informationsgovernance (DCB0129, DPIA) als Unternehmens-Overhead zu behandeln, den man aufschiebt – in der Gesundheit ist diese Disziplin selbst in der Seed-Phase nicht verhandelbar, und NHS-Käufer verlangen DTAC-Nachweise, bevor sie Sie an Patientendaten lassen.

Kleines Unternehmen#

Für einen etablierten kleinen Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder einen Anbieter häuslicher Pflege, eine Einzelstandort-Klinik oder einen kleinen Health-Tech-Lieferanten jenseits der Startup-Phase – bedeutet produktgeführte Arbeit selten, ein dediziertes funktionsübergreifendes Team aufzustellen, denn es gibt keine übrige Produktmanagerin, keinen Designer oder Entwickler zu finanzieren. Hier ist das „dauerhafte Team“ oft die Praxismanagerin oder die eingetragene Leiterin plus ein vertrauenswürdiger Lieferant, sodass die Disziplin, auf die es ankommt, darin besteht, wer auch immer das System konfiguriert und pflegt, an Ergebnissen zu messen – weniger versäumte Termine, sicherer Medikationsabgleich, besserer Zugang für die gebrechlichsten Bewohnerinnen – statt an einer einmaligen Installation. Das Geld ist knapp und laufend, nicht durch Runway begrenzt; der vernünftige Schritt ist daher, in Produkte einzusteigen, die andere am Leben halten (die Roadmap eines gut geführten Lieferanten, eine gemeinsame Patientenakte, eine ICS-Plattform), statt maßgeschneiderte Bauten zu beauftragen, die niemand pflegen wird. Klinische Sicherheit und Informationsgovernance gelten voll – dieselben DCB0160-Einsatzpflichten und DPIA-Verpflichtungen wie bei einem großen Trust –, aber ohne hauseigene Fähigkeit, was die Wahl von Lieferanten, die ihren Sicherheitsfall verantworten, zu einer echten Produktentscheidung macht. Die Gleichstellungsperspektive liegt nah: Ein kleiner Anbieter versorgt oft genau die älteren oder ärmeren Patientinnen, die am stärksten digitaler Ausgrenzung ausgesetzt sind; ein nicht digitaler Rückfall ist also nicht optional.

Großunternehmen#

In einem großen NHS Trust, einem Integrated Care System (ICS) oder einem Health-Tech-Unternehmen stößt das Modell dauerhafter Teams mit jährlicher Kapitalbudgetierung und einer projektförmigen Finanzmaschine zusammen. Die Kernarbeit ist, ständige Dienste – das EPR-Optimierungsteam, das Team der gemeinsamen Patientenakte – von Stop-and-go-Projekten in finanzierte Produktteams mit rollierenden, an Wertströme gebundenen Budgets zu verwandeln, was ebenso eine Änderung von Finanzen und Governance ist wie des Organigramms. Rechenschaft ist über klinische Governance, Informationsgovernance, Vorstands-Assurance und Lieferantenverträge geschichtet, sodass Befähigung mit einer expliziten Produktstrategie und Portfolio-Ausrichtung gekoppelt werden muss (siehe Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM)), um zu verhindern, dass Dutzende autonomer Teams lokal optimieren. Größe ist der Feind der Nähe zu Nutzenden; gezielte Investition in eingebettete Forschung hält daher die Teams einer großen Organisation ehrlich.

Regierung#

Im nationalen Maßstab – NHS England, DHSC, UKHSA – finanziert produktgeführte Arbeit langlebige Plattformen (die NHS App, NHS login, nationale Interoperabilitäts-APIs) als Produkte statt als Programme, gemessen am GDS und NHS Service Standard und ihren Service-Assessments. Finanzierung fließt über Spending-Review-Zuweisungen und Business Cases, sodass das Schwierige ist, stabile Teams über Haushaltsjahre und politische Zyklen hinweg zu erhalten, wenn die Maschinerie um sie herum auf befristete Projekte gebaut ist. Rechenschaft besteht gegenüber Ministern, Parlament und Öffentlichkeit über das National Audit Office, und die Gleichstellungspflicht ist gesetzlich, sodass Ergebniskennzahlen mit veröffentlichten Gleichstellungsmaßen auf Bevölkerungsebene gekoppelt werden müssen. Der Gewinn ist Reichweite: Eine einzelne Produktverbesserung kann Dutzende Millionen Nutzende auf einmal berühren, was sowohl den Nutzen als auch die Kosten eines Fehlers erhöht.

Häufige Fehlermuster#

• Produktgeführt nur dem Namen nach („Feature-Fabrik“). Die Organisation etikettiert Projektteams als „Produktteams“ um, reicht ihnen aber weiter eine feste Roadmap herab und misst sie an Lieferung. Abhilfe: Ändern Sie Mandat und Kennzahlen, nicht nur Stellentitel.
• Ergebnisse ohne Sicherheits- oder Gleichstellungsleitplanke. Die Optimierung einer einzelnen Effizienzkennzahl kann Schaden verbergen oder Ausgrenzung vergrößern. Abhilfe: Jede Ergebniskennzahl wird mit einem Sicherheits- und einem Gleichstellungsmaß gekoppelt.
• „Befähigung“ ohne Strategie. Teams, die ihre Richtung selbst erfinden sollen, driften und duplizieren. Abhilfe: starke Produktvision und -strategie sowie Ausrichtung auf Portfolio-Ebene (Thema 5.3).
• Produktgeführt auf wirklich endliche Arbeit angewandt. Eine einmalige Rechenzentrumsmigration oder ein Hardware-Rollout braucht kein Dauerteam. Abhilfe: projektgeführte Arbeit (Thema 5.1) nutzen, wo der Umfang wirklich fest ist.
• Finanzierung, die zu jährlichen Projektanträgen zurückfällt. Ein dauerhaftes Team auf Stop-and-go-Budget kann weder planen noch Menschen halten. Abhilfe: rollierende, nach Ergebnissen überprüfte Finanzierung für den Wertstrom.
• Produktmanagerin als Ticketschreiberin. Die Rolle auf Backlog-Verwaltung zu reduzieren verschwendet sie. Abhilfe: die Produktmanagerin für Wert, Tragfähigkeit und Ergebnisse rechenschaftspflichtig halten.

Reifegradmodell#

Checkliste#

• Ist dies wirklich ein laufender Dienst (keine endliche Arbeit), der zu einem dauerhaften Team passt?
• Verantwortet ein stabiles, funktionsübergreifendes Team das Produkt über seinen gesamten Lebenszyklus?
• Ist das Team mit Problemen und Ergebnissen mandatiert, nicht mit einer festen Funktionsliste?
• Sind Ergebniskennzahlen vereinbart – jede mit einem Sicherheits- und einem Gleichstellungsmaß gekoppelt?
• Sind klinische Sicherheit (DCB0129/DCB0160) und Informationsgovernance im Team?
• Wird das Team rollierend finanziert und anhand nachgewiesener Ergebnisse neu freigegeben?
• Sind kontinuierliche Nutzerforschung und Discovery ständige Praxis?
• Ist das Produkt mit Messpunkten versehen, und wird die Annahme nach Kohorte beobachtet, um Ausgrenzung zu erkennen?
• Gibt es eine klare Produktstrategie, die Autonomie auf Organisationsziele ausrichtet?
• Sind eleganter Auslauf/Migration als ausdrückliche Lebenszyklusphase eingeplant?

Zentrale Quellen#

• Silicon Valley Product Group (SVPG), Marty Cagan — The Product Operating Model: An Introduction und Empowered Product Teams (svpg.com); Bücher Inspired, Empowered und Transformed.
• Mik Kersten — Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework (IT Revolution, 2018).
• NHS England — NHS Service Manual und der NHS Digital Service Standard.
• GOV.UK — Service Manual und Service Standard des Government Digital Service (GDS).
• NHS-Digital-Standards der klinischen Sicherheit DCB0129 (Herstellung) und DCB0160 (Einsatz) von Gesundheits-IT-Systemen.
• John Doerr — Measure What Matters (OKRs), für ergebnisbasierte Zielsetzung.

Referenzen#

1. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
2. Product lifecycle — Wikipedia — https://en.wikipedia.org/wiki/Product_lifecycle
3. Cross-functional team — Wikipedia — https://en.wikipedia.org/wiki/Cross-functional_team
4. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
5. Objectives and key results (OKR) — Wikipedia — https://en.wikipedia.org/wiki/OKR
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. NHS App — Wikipedia — https://en.wikipedia.org/wiki/NHS_App
8. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
9. The Product Operating Model / Inspired, Empowered, Transformed — Marty Cagan, Silicon Valley Product Group — https://www.svpg.com/
10. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/
11. NHS service manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/
12. GOV.UK Service Manual and Service Standard — Government Digital Service — https://www.gov.uk/service-manual
13. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
14. Measure What Matters — John Doerr — https://www.whatmatters.com/