Onderwerp 5.0 — Productgestuurd werken

In één zin: Productgestuurd werken financiert duurzame, bevoegde teams om een dienst over haar hele leven te bezitten en houdt hen verantwoordelijk voor meetbare uitkomsten in plaats van voor het opleveren van een vaste lijst functies.

Waarom dit ertoe doet in gezondheid en zorg#

Het meeste wat organisaties in digitale gezondheid en zorg draaien is geen eenmalige oplevering — het is een levende dienst. De NHS App, een elektronisch patiëntendossier, een gedeeld zorgdossier, een traject voor elektronische verwijzing, een casemanagementsysteem voor de sociale zorg: geen van deze is “af”. Ze moeten voortdurend worden verbeterd naarmate klinische richtlijnen veranderen, veiligheidsincidenten opduiken, de vraag verschuift en het landschap om hen heen evolueert.

Wanneer u een levende dienst beheert als een reeks losse projecten, krijgt u een voorspelbaar falen: een leverancier bouwt naar een specificatie, het geld raakt op, het team gaat uiteen en de dienst wordt overgelaten aan verval tot het volgende kapitaalvoorstel. Clinici werken om de gaten heen, risico’s voor patiëntveiligheid stapelen zich op en billijkheid lijdt, omdat de mensen die een onhandige dienst het minst kunnen verdragen degenen zijn met de grootste behoefte. Productgestuurd werken bestaat om die cyclus te doorbreken. Het houdt een stabiel team dicht bij gebruikers en bij uitkomsten, zodat de dienst in de loop van de tijd veiliger, bruikbaarder en billijker wordt in plaats van tussen financieringsrondes te verslechteren.

De inzet is ook financieel en wettelijk. Publiek geld wordt beter beschermd door een team dat voortdurend toetst of een dienst de zorg werkelijk verbetert dan door een project dat succes meet als “op tijd en binnen budget opgeleverd”, ongeacht of iemand er baat bij had. Dit onderwerp staat naast Onderwerp 5.1 — Projectgestuurd werken en Onderwerp 5.2 — Programmagestuurd werken; de drie zijn complementaire instrumenten, geen rivalen, en Onderwerp 5.3 — Enterprise-projectportfoliomanagement (EPPM) legt uit hoe u ze bijeenhoudt.

Kernbegrippen#

Duurzaam productteam. Een multidisciplinair, langlevend team dat een product of dienst over haar hele levenscyclus bezit. Het team blijft bestaan; het werk stroomt naar het team toe. Dit is de atomaire eenheid van het productoperatiemodel zoals beschreven door Marty Cagan en de Silicon Valley Product Group (SVPG): een stabiele groep van een productmanager, een productontwerper en engineers, in een gezondheidscontext ondersteund door klinische en data-expertise.

Bevoegd team. Cagan trekt een scherpe lijn tussen een “featureteam” dat een roadmap van te bouwen dingen krijgt aangereikt en een “bevoegd team” (empowered team) dat problemen om op te lossen en uitkomsten om te bereiken krijgt en het vertrouwen heeft de beste oplossing te vinden. Bevoegdheid is geen vrijbrief om alles te doen; het is verantwoording voor resultaten binnen een duidelijk strategisch kader.

Uitkomsten boven opbrengsten. Een opbrengst (output) is wat u oplevert — een functie, een release, een scherm. Een uitkomst (outcome) is de verandering in de wereld die daaruit volgt — minder gemiste afspraken, snellere ontslagen, minder medicatiefouten, billijker gebruik. Productgestuurd werken meet teams op uitkomsten, omdat een functie opleveren die niemand gebruikt, of waardoor niemand veiliger is, verspilling is vermomd als voortgang.

Productmanager. De leider van productmanagement, verantwoordelijk voor de waarde en haalbaarheid van het product: is dit het bouwen waard, zullen mensen het gebruiken, past het bij de strategie, regelgeving en financiën van de organisatie? In gezondheid en zorg moet deze rol nauw samenwerken met leiders voor klinische veiligheid en informatiebeheer en niet boven hen staan.

Productoperatiemodel. SVPG is expliciet dat dit een model is, geen methodologie of rigide kader: een reeks beginselen over hoe een bedrijf technologiegedreven producten bouwt en runt — bevoegde teams, verantwoording voor uitkomsten, continue discovery en productstrategie — en geen voorgeschreven proces dat u installeert.

Productlevenscyclus. Discovery (is er een echt probleem dat het oplossen waard is?), levering (bouw het veilig en goed), groei en optimalisatie (verbeter adoptie en uitkomsten) en uiteindelijk uitfasering (sunset: schaf af of vervang soepel). Productgestuurde teams bezitten alles daarvan, daarom kunnen zij verstandige afwegingen over het hele leven kunnen maken die een projectteam niet kan.

Beste praktijken#

1. Financier het team, niet het project. Verplaats geld van tijdgebonden projectbudgetten naar vaste productbudgetten gekoppeld aan een waardestroom, zoals Mik Kersten bepleit in Project to Product. Financier een blijvend team om uitkomsten na te streven over opeenvolgende planningscycli en autoriseer de financiering opnieuw op grond van aangetoonde resultaten, niet op een mijlpalenplan dat jaren eerder werd afgesproken.

2. Geef teams problemen en uitkomsten, geen lijsten met functies. Formuleer het mandaat als “verlaag het percentage no-shows (did-not-attend) in poliklinieken” of “verkort de tijd die een clinicus besteedt aan het vinden van een uitslag” en laat het bevoegde team dan de beste oplossing ontdekken. Een roadmap van vastgelegde functies van bovenaf aangereikt herschept het anti-patroon van het featureteam waarvoor Cagan waarschuwt.

3. Maak uitkomstmaten expliciet en klinisch betekenisvol. Spreek vooraf een kleine set uitkomstmaten af, bij voorkeur als doelstellingen en kernresultaten (OKR’s — zie Onderwerp 7.3). Koppel elke efficiëntiemaat aan een veiligheidsmaat en een billijkheidsmaat, zodat een team nooit wordt beloond voor snelheid ten koste van schade of van vergrote ongelijkheid.

4. Houd het team dicht bij echte gebruikers. Bouw continue discovery in: regelmatig contact met clinici, zorgmedewerkers, administratief personeel en patiënten. De NHS Service Manual en de GOV.UK Service Manual maken gebruikersonderzoek beide tot een vaste discipline, niet tot een eenmalige fase. Een duurzaam team maakt dit betaalbaar omdat de relaties blijven bestaan.

5. Bouw multidisciplinaire teams met klinische veiligheid erbinnen. Een productteam in digitale gezondheid heeft, naast product/ontwerp/engineering, een klinischeveiligheidsfunctionaris (DCB0129/DCB0160), informatiebeheer en data-expertise nodig. Veiligheid en bestuur zijn ontwerpinvoer die binnen het team wordt bezeten, geen poorten die aan het eind worden aangebracht.

6. Instrumenteer het product en handel op de data. Duurzame teams kunnen investeren in telemetrie, zodat beslissingen berusten op echt gebruik en echte uitkomsten in plaats van op mening. Volg adoptie per cohort om digitale uitsluiting vroeg te vangen.

7. Bezit de hele levenscyclus, inclusief uitfasering. Bevoegde teams plannen voor soepele afschaffing en migratie, niet alleen voor de lancering. Besluiten niet door te bouwen en te consolideren op een strategisch platform is een legitieme en waardevolle productbeslissing.

8. Stem teams af via strategie, niet via micromanagement. Autonomie zonder afstemming leidt tot lokale optimalisatie en chaos. Een duidelijke productvisie en -strategie — en op schaal een kader van portfolio en programma (Onderwerpen 5.2 en 5.3) — is wat u in staat stelt teams veilig bevoegd te maken.

Vragen om met uw team te bespreken#

1. Welke van de diensten die wij vandaag runnen zijn werkelijk levende diensten die een duurzaam, gefinancierd productteam verdienen, en welke zijn eindig werk waarvan wij alleen doen alsof het er een nodig heeft? Dit is de fundamentele sorteervraag, en het fout doen in beide richtingen is duur. In een organisatie in digitale gezondheid en zorg is het landschap een mengeling — een gedeeld zorgdossier of de app voor patiënten is een levende dienst, maar het verlaten van een datacentrum of een vervanging van hardware is werkelijk eindig — en het eerlijke antwoord vereist dat u elk belangrijk systeem noemt en zijn zaak bepleit in plaats van overal één financieringsmodel toe te passen. De spanning is dat financiën en bestuur gewoonlijk alles richting tijdgebonden kapitaalvoorstellen duwen, zodat iets “product” noemen als pleiten voor een uitzondering kan voelen, terwijl een levende dienst “project” noemen stilletjes het eerder in dit onderwerp beschreven verval van bouwen-en-verlaten garandeert. Overweeg de kosten over het hele leven, het tempo waarin klinische richtlijnen en vraag rond de dienst veranderen en of risico voor patiëntveiligheid zich opstapelt wanneer niemand voortdurende verbetering bezit. Een goed antwoord noemt twee of drie diensten waarvoor een duurzaam team duidelijk gerechtvaardigd is, is openhartig over de grensgevallen en parkeert het eindige werk uitdrukkelijk bij Onderwerp 5.1 in plaats van een algemeen beleid te verdedigen.

2. Welke twee of drie uitkomstmaten zouden wij werkelijk als inzet voor de financiering van een team nemen, en hoe koppelen wij elk aan een veiligheids- en billijkheidsmaat zodat wij nooit worden beloond voor snelheid ten koste van schade? Uitkomsten boven opbrengsten is gemakkelijk gezegd en moeilijk te operationaliseren, omdat een maat vanaf het moment dat zij geld stuurt gedrag gaat vervormen. Een team in digitale gezondheid dat opdracht krijgt “het percentage no-shows te verlagen” kan het getal halen door de meest digitaal zelfverzekerde patiënten aan te sporen terwijl de kloof voor oudere of kansarmere cohorten stilletjes groeit — dus het debat moet aan het licht brengen welke enkele efficiëntiemaat elk team kan overoptimaliseren en wat de gekoppelde veiligheids- en billijkheidsvangrail werkelijk meet. Breng concrete kandidaten aan tafel (minder medicatiefouten, sneller ontslag, gebruik per locatie of proxy voor digitale toegang) en toets of zij klinisch betekenisvol zijn of louter gemakkelijk te instrumenteren. Overweeg wie elke maat bezit, wat de nulmeting is en hoe vaak zij wordt getoetst, want een uitkomst zonder eigenaar of nulmeting is decoratie. Een eerlijk antwoord aanvaardt dat sommige uitkomsten waar wij om geven traag of moeilijk te meten zijn, weerstaat de trek naar ijdele adoptiecijfers en verbindt zich ertoe de billijkheidsmaat naast de efficiëntiemaat te publiceren zodat de afweging zichtbaar blijft.

3. Hoeveel werkelijk gezag zijn wij bereid een bevoegd team te geven om van richting te veranderen, en welk strategisch kader houdt die autonomie van uiteenvallen in lokale optimalisatie? Bevoegdheid is de kern van het productoperatiemodel en ook zijn meest voorkomende namaak, omdat organisaties teams “productteams” herdopen terwijl zij nog steeds een vaste roadmap aanreiken en op oplevering meten. De echte vraag is waar de grens ligt: kan een team omschakelen van een functie die door het bestuur wordt gesponsord naar een andere oplossing wanneer discovery toont dat die de uitkomst beter realiseert, of zullen klinisch bestuur, informatiebeheer en bestaande leverancierscontracten dat in de praktijk een veto geven? De spanning is dat autonomie zonder afstemming duplicatie en drift over een ICS veroorzaakt, terwijl afstemming afgedwongen als micromanagement de featurefabriek herschept — dus het antwoord ligt in een expliciete productvisie en -strategie, en op schaal een portfoliokader, dat begrenst zonder te dicteren. Overweeg een recente beslissing waarbij een team van koers wilde veranderen en vraag eerlijk of het systeem dat toeliet. Een goed antwoord definieert de beslissingen die een team alleen mag nemen tegenover die welke escalatie vragen, noemt het strategiedocument dat het kader levert en is openhartig over waar de organisatie nu controle met afstemming verwart.

4. Hoe financieren en verdedigen wij een duurzaam team door de jaarlijkse begrotingscyclus, en wat zullen wij werkelijk doen wanneer financiën ons vraagt een “product” te rechtvaardigen dat geen vaste einddatum heeft? Productgestuurd werken staat of valt met geld, en het apparaat van NHS- en overheidsfinanciën is gebouwd voor tijdgebonden kapitaalvoorstellen, niet voor doorlopende exploitatiefinanciering gekoppeld aan een waardestroom — dus deze vraag dwingt het ongemakkelijke operationele detail achter “financier het team, niet het project”. De spanning is dat een duurzaam team stabiliteit over meerdere jaren nodig heeft om schaars klinisch, product- en engineeringpersoneel te behouden, terwijl de begrotingsafspraak waarvan het afhangt elk jaar opnieuw wordt bevochten tegen kapitaalregelingen met een nette start en eind. Breng de echte getallen: wat zijn de vaste kosten van het team, aan welke waardestroom is het gekoppeld en welk bewijs van aangetoonde uitkomsten zou herautorisatie rechtvaardigen tegenover een mijlpalenplan van jaren geleden. Overweeg hoe regels voor kapitaal- versus exploitatieboekhouding, inkoopcycli en leverancierscontracten het model in uw organisatie helpen of tegenwerken. Een eerlijk antwoord noemt wie de doorlopende begroting goedkeurt, wat er met het team gebeurt in een slecht begrotingsjaar en of de organisatie bereid is een echte dienst om te zetten in een productlijn in plaats van haar stilletjes terug te laten vallen op projectvoorstellen.

5. Wanneer productgestuurd werken onze plichten voor klinische veiligheid en informatiebeheer ontmoet, zitten veiligheid en bestuur dan werkelijk binnen het team als ontwerpinvoer, of zijn het nog poorten waar het team naartoe rent en omheen onderhandelt? Een duurzaam, bevoegd team dat continu oplevert verandert het risicobeeld, omdat elke iteratie een potentiële gebeurtenis voor klinische veiligheid en gegevensbescherming is in plaats van één enkele goedkeuring aan het eind van een project — dus gevarenwerk onder DCB0129/DCB0160 en DPIA’s moeten binnen het ritme van het team leven en niet aan een releasepoort worden vastgemaakt. De spanning is echt: een klinischeveiligheidsfunctionaris en een leider informatiebeheer in elk productteam inbedden is duur en die vaardigheden zijn schaars, dus organisaties zijn verleid ze dun te verdelen of zekerheid te behandelen als een goedkeuring die het team laat zoekt. Die verleiding herschept juist het bouwen-en-verlaten voor veiligheid, omdat een team dat een uitkomstmaat optimaliseert onder leveringsdruk zonder interne veiligheidsstem schade pas zal ontdekken nadat zij patiënten heeft bereikt. Overweeg hoe het veiligheidsdossier over veel kleine releases actueel wordt gehouden, wie het gevarenlogboek bezit en of collega’s van bestuur echte invloed hebben op discovery en prioritering of slechts een veto aan het eind. Een goed antwoord is openhartig over waar veiligheid nu een poort is en geen ontwerpinvoer, en verbindt zich aan de bezetting en het ritme die continue zekerheid betaalbaar maken.

6. Hoe houden wij een duurzaam team werkelijk dicht bij onderbediende gebruikers zodat voortdurende verbetering digitale uitsluiting verkleint in plaats van vergroot? Productgestuurd werken belooft billijkheid als eersteklas uitkomst, maar een stabiel team dat zijn eigen product instrumenteert zal van nature het luidst horen van de gebruikers die al betrokken zijn — de digitaal zelfverzekerden, de verbondenen, degenen die in de telemetrie verschijnen — zodat nabijheid tot gebruikers stilletjes nabijheid tot de gemakkelijke gebruikers kan worden. De spanning is dat de cohorten met het grootste risico op uitsluiting (oudere patiënten, mensen in kansarme gebieden, mensen met weinig digitale toegang of taalbarrières) het moeilijkst en duurst te bereiken zijn via continue discovery, en toch precies de mensen zijn die een publieke gezondheidsdienst moet dienen. Breng concrete praktijk aan tafel: welke cohorten worden bewust in onderzoek geworven, hoe adoptie wordt gevolgd per locatie en proxy voor digitale toegang en welk niet-digitaal vangnet bestaat wanneer de digitale route iemand achterlaat. Overweeg of de billijkheidsmaat van het team beslissingen werkelijk verandert of louter wordt gerapporteerd. Een eerlijk antwoord geeft toe waar de huidige onderzoekspool naar het gemakkelijk bereikbare overhelt, noemt de onderbediende groepen die het nog niet hoort en beschrijft de specifieke investering — outreach, ondersteund digitaal, telefonisch vangnet — die voorkomt dat verbetering voordeel opstapelt.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een integrated care system (ICS) draait een app voor patiënten voor afsprakenbeheer die over verscheidene ziekenhuizen wordt gebruikt. Historisch was elke verbetering een afzonderlijk project: een leverancier werd ingeschakeld om “sms-herinneringen toe te voegen”, leverde ze op en vertrok. Zes maanden later liepen de herinneringen mis, bezat niemand de oplossing en was een kapitaalvoorstel nodig om het contract te heropenen.

Het ICS schakelt over op een productgestuurd model. Het zet een duurzaam productteam op — een productmanager, een ontwerper, vier engineers, een klinischeveiligheidsfunctionaris en een leider informatiebeheer — doorlopend gefinancierd en met een mandaat voor een uitkomst, niet voor een lijst functies: verlaag het percentage no-shows (DNA) en verbeter de billijkheid van toegang over de bevolking.

Het team voert continue discovery uit met patiënten en planners van poliklinieken. Zij leren dat herinneringen helpen, maar dat de grotere drijver van no-shows in één kansarm gebied is dat patiënten niet gemakkelijk kunnen herboeken, zodat zij de plek simpelweg missen. Omdat het team de uitkomst bezit en geen specificatie, verlegt het zijn investering van een opzichtige functie voor meldingen naar een eenvoudige stroom voor zelf herboeken, en instrumenteert het het gebruik per locatie en per proxy voor digitale toegang.

Over drie planningscycli daalt het percentage no-shows, en — cruciaal — het team monitort de billijkheidsmaat en ziet dat het gebruik achterblijft bij oudere patiënten, wat een telefonisch vangnet uitlokt zodat de digitale route de ongelijkheid niet vergroot. De financiering gaat door omdat de uitkomsten aantoonbaar zijn. Geen functie werd ooit “goedgekeurd en verlaten”; de dienst blijft gewoon verbeteren. Wanneer een nationaal platform later hetzelfde vermogen aanbiedt, voert hetzelfde team de migratie uit en faseert het zijn eigen component uit — een beslissing over het hele leven die een projectteam nooit in staat zou zijn geweest te nemen.

Sectorperspectieven#

Startup#

In een klein bedrijf voor digitale gezondheid is productgestuurd werken de standaard — vaak de enige — wijze: één bevoegd team, soms het hele bedrijf, bezit het product van begin tot eind. Financiering is de bindende beperking, omdat de looptijd van investeerders of subsidiegeld betekent dat het team snel genoeg aantoonbare vooruitgang in uitkomsten moet tonen (adoptie, retentie, een vroeg klinisch signaal) om de volgende ronde te rechtvaardigen, dus continue discovery en instrumentatie zijn overlevingsmiddelen en geen luxe. De risicobereidheid is hoog en verantwoording loopt naar oprichters en investeerders, niet naar een bestuur of het publiek, dus het team kan in dagen omschakelen. De valkuil is klinische veiligheid en informatiebeheer (DCB0129, DPIA) behandelen als overhead van een grote onderneming die kan wachten — in gezondheid is die discipline niet onderhandelbaar, zelfs in de seedfase, en NHS-kopers zullen DTAC-bewijs eisen voordat zij u in de buurt van patiëntdata laten komen.

Klein bedrijf#

Voor een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of thuiszorgorganisatie, een kliniek met één vestiging of een kleine leverancier van health-tech voorbij de startupfase — betekent productgestuurd werken zelden dat er een toegewijd multidisciplinair team komt, omdat er geen overtollige productmanager, ontwerper of engineer is om te financieren. Het “duurzame team” is hier vaak de praktijkmanager of geregistreerde manager plus een vertrouwde leverancier, dus de discipline die telt is wie het systeem configureert en onderhoudt aanspreken op uitkomsten — minder gemiste afspraken, veiligere medicatieverificatie, betere toegang voor de meest kwetsbare bewoners — in plaats van op een eenmalige installatie. Geld is krap en doorlopend, niet beperkt door looptijd, dus de verstandige zet is in te kopen in producten die anderen in leven houden (de roadmap van een goed gerunde leverancier, een gedeeld zorgdossier, een ICS-platform) in plaats van maatwerk te bestellen dat niemand onderhoudt. Klinische veiligheid en informatiebeheer wegen volledig door — dezelfde plichten voor inzet onder DCB0160 en verplichtingen voor DPIA’s als een groot ziekenhuis — maar zonder het interne vermogen, wat het kiezen van leveranciers die hun eigen veiligheidsdossier bezitten tot een echte productbeslissing maakt. De invalshoek van billijkheid ligt dichtbij: een kleine aanbieder bedient vaak precies de oudere of kansarmere patiënten die het meest zijn blootgesteld aan digitale uitsluiting, dus een niet-digitaal vangnet houden is niet optioneel.

Grote onderneming#

In een groot NHS-ziekenhuis, een integrated care system (ICS) of een bedrijf in health-tech botst het model van het duurzame team met jaarlijkse kapitaalbegroting en een financieel apparaat in projectvorm. Het kernwerk is bestaande diensten — het team voor EPD-optimalisatie, het team voor het gedeelde zorgdossier — om te zetten van stop-startprojecten in gefinancierde productteams met doorlopende budgetten gekoppeld aan waardestromen, wat evenzeer een verandering in financiën en bestuur is als in het organigram. Verantwoording is gelaagd over klinisch bestuur, informatiebeheer, zekerheid voor het bestuur en leverancierscontracten, dus bevoegdheid moet worden gekoppeld aan een expliciete productstrategie en afstemming op het portfolio (zie Onderwerp 5.3 — Enterprise-projectportfoliomanagement (EPPM)) om te voorkomen dat tientallen autonome teams lokaal optimaliseren. Schaal is de vijand van nabijheid tot gebruikers, dus bewuste investering in ingebed onderzoek houdt de teams van een grote organisatie eerlijk.

Overheid#

Op nationale schaal — NHS England, DHSC, UKHSA — financiert productgestuurd werken langlevende platforms (de NHS App, NHS login, nationale API’s voor interoperabiliteit) als producten in plaats van programma’s, gehouden aan de GDS- en NHS Service Standard en hun serviceassessments. Financiering loopt via begrotingsafspraken en businesscases, dus het moeilijke deel is stabiele teams over begrotingsjaren en politieke cycli te behouden terwijl het apparaat eromheen is gebouwd voor tijdgebonden projecten. Verantwoording loopt naar ministers, het Parlement en het publiek via de National Audit Office, en de plicht tot billijkheid is wettelijk, dus uitkomstmaten moeten worden gekoppeld aan gepubliceerde billijkheidsmaten op bevolkingsniveau. De winst is bereik: één productverbetering kan tientallen miljoenen gebruikers tegelijk raken, wat zowel het voordeel als de kosten van het fout doen vergroot.

Veelvoorkomende faalpatronen#

• Alleen in naam productgestuurd (“featurefabriek”). De organisatie herdoopt projectteams tot “productteams” maar reikt nog steeds een vaste roadmap aan en meet hen op oplevering. Oplossing: verander het mandaat en de maten, niet alleen de functietitels.
• Uitkomsten zonder vangrail voor veiligheid of billijkheid. Eén efficiëntiemaat optimaliseren kan schade verbergen of uitsluiting vergroten. Oplossing: elke uitkomstmaat wordt gekoppeld aan een veiligheids- en billijkheidsmaat.
• “Bevoegdheid” zonder strategie. Teams die hun eigen richting moeten bedenken driften af en dupliceren. Oplossing: sterke productvisie en -strategie, en afstemming op portfolioniveau (Onderwerp 5.3).
• Productgestuurd werken toepassen op werkelijk eindig werk. Een eenmalige migratie van een datacentrum of een uitrol van hardware heeft geen eeuwigdurend team nodig. Oplossing: gebruik projectgestuurd werk (Onderwerp 5.1) waar de reikwijdte werkelijk vaststaat.
• Financiering die terugvalt op jaarlijkse projectvoorstellen. Een duurzaam team op een stop-startbudget kan niet plannen of mensen behouden. Oplossing: doorlopende, op uitkomsten getoetste financiering voor de waardestroom.
• Productmanager als ticketschrijver. De rol terugbrengen tot beheer van de backlog verspilt haar. Oplossing: spreek de productmanager aan op waarde, haalbaarheid en uitkomsten.

Volwassenheidsmodel#

Checklist#

• Is dit werkelijk een doorlopende dienst (geen eindig werk) die bij een duurzaam team past?
• Bezit een stabiel, multidisciplinair team het product over zijn hele levenscyclus?
• Heeft het team een mandaat met problemen en uitkomsten, niet een vaste lijst functies?
• Zijn uitkomstmaten afgesproken — elk gekoppeld aan een veiligheids- en billijkheidsmaat?
• Zitten klinische veiligheid (DCB0129/DCB0160) en informatiebeheer binnen het team?
• Wordt het team doorlopend gefinancierd en opnieuw geautoriseerd op aangetoonde uitkomsten?
• Is continu gebruikersonderzoek en discovery een vaste praktijk?
• Is het product geïnstrumenteerd, met adoptie per cohort gevolgd om uitsluiting te vangen?
• Is er een duidelijke productstrategie die autonomie afstemt op de doelen van de organisatie?
• Is soepele uitfasering/migratie gepland als expliciete fase van de levenscyclus?

Belangrijkste bronnen#

• Silicon Valley Product Group (SVPG), Marty Cagan — The Product Operating Model: An Introduction en Empowered Product Teams (svpg.com); boeken Inspired, Empowered en 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 en de NHS Digital Service Standard.
• GOV.UK — Service Manual en Service Standard van de Government Digital Service (GDS).
• Normen voor klinische veiligheid van NHS Digital, DCB0129 (fabricage) en DCB0160 (inzet) van IT-systemen in de gezondheidszorg.
• John Doerr — Measure What Matters (OKR’s), voor het stellen van doelen op basis van uitkomsten.

Referenties#

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/