Sujet 5.0 — Travail piloté par le produit

En une phrase : Le travail piloté par le produit finance des équipes durables et habilitées pour posséder un service sur toute sa vie, les tenant responsables de résultats mesurables plutôt que de la livraison d'une liste fixe de fonctionnalités.

Pourquoi c'est important dans la santé et l'action sociale#

La majeure partie de ce que les organisations de santé et d'action sociale numériques exploitent n'est pas une livraison ponctuelle — c'est un service vivant. L'application NHS, un dossier de santé électronique, un dossier de soins partagé, un parcours d'e-référence, un système de gestion de cas d'action sociale : aucun de ceux-ci n'est « terminé ». Ils doivent être continuellement améliorés à mesure que les directives cliniques changent, que les incidents de sécurité émergent, que la demande évolue, et que le parc autour d'eux évolue.

Lorsque vous gérez un service vivant comme une série de projets déconnectés, vous obtenez un échec prévisible : un fournisseur construit selon une spécification, l'argent s'épuise, l'équipe se dissout, et le service est laissé à pourrir jusqu'à la prochaine offre en capital. Les cliniciens contournent les lacunes, les risques de sécurité patient s'accumulent, et l'équité souffre car les personnes les moins capables de tolérer un service maladroit sont celles ayant le plus grand besoin. Le travail piloté par le produit existe pour briser ce cycle. Il garde une équipe stable proche des utilisateurs et des résultats, afin que le service devienne plus sûr, plus utilisable, et plus équitable dans le temps plutôt que de se dégrader entre les tours de financement.

Les enjeux sont aussi financiers et statutaires. L'argent public est mieux protégé par une équipe qui valide continuellement si un service améliore réellement les soins que par un projet qui mesure le succès comme « livré à temps et dans le budget » quel que soit si quelqu'un en a bénéficié. Ce sujet se situe aux côtés du Sujet 5.1 — Travail piloté par le projet et du Sujet 5.2 — Travail piloté par le programme ; les trois sont des outils complémentaires, pas des rivaux, et le Sujet 5.3 — Gestion de portefeuille et projets d'entreprise (EPPM) explique comment les tenir ensemble.

Concepts fondamentaux#

Équipe produit durable. Une équipe transdisciplinaire et de longue durée qui possède un produit ou service à travers tout son cycle de vie. L'équipe persiste ; le travail circule vers elle. C'est l'unité atomique du modèle opérationnel de produit décrit par Marty Cagan et le Silicon Valley Product Group (SVPG) : un groupe stable d'un chef de produit, un designer produit, et des ingénieurs, soutenu par l'expertise clinique et de données dans un contexte de santé.

Équipe habilitée. Cagan trace une ligne nette entre une « équipe de fonctionnalité » à qui l'on remet une feuille de route de choses à construire, et une « équipe habilitée » à qui l'on remet des problèmes à résoudre et des résultats à atteindre, et à qui l'on fait confiance pour trouver la meilleure solution. L'habilitation n'est pas une licence pour faire n'importe quoi ; c'est une responsabilité pour les résultats à l'intérieur d'un cadre stratégique clair.

Résultats plutôt que livrables. Le livrable est ce que vous livrez — une fonctionnalité, une version, un écran. Un résultat est le changement dans le monde qui en résulte — moins de rendez-vous manqués, une sortie plus rapide, moins d'erreurs de médication, une adoption plus équitable. Le travail piloté par le produit mesure les équipes sur les résultats, car livrer une fonctionnalité que personne n'utilise, ou pour laquelle personne n'est plus en sécurité, est du gaspillage déguisé en progrès.

Chef de produit. Le responsable de la gestion de produit, responsable de la valeur et de la viabilité du produit : cela vaut-il la peine d'être construit, les gens l'utiliseront-ils, cela correspond-il à la stratégie, aux réglementations, et aux finances de l'organisation ? Dans la santé et l'action sociale, ce rôle doit s'associer étroitement avec les responsables de sécurité clinique et de gouvernance de l'information, pas se placer au-dessus d'eux.

Modèle opérationnel de produit. SVPG est explicite que c'est un modèle, pas une méthodologie ni un cadre rigide : un ensemble de principes sur comment une entreprise construit et exploite des produits activés par la technologie — équipes habilitées, responsabilité de résultat, découverte continue, et stratégie de produit — plutôt qu'un processus prescrit que vous installez.

Cycle de vie de produit. Découverte (y a-t-il un véritable problème qui vaut la peine d'être résolu ?), livraison (construire en toute sécurité et bien), croissance et optimisation (améliorer l'adoption et les résultats), et éventuellement la fin de vie (retirer ou remplacer avec élégance). Les équipes pilotées par le produit possèdent tout cela, ce qui est pourquoi elles peuvent faire des compromis sensés de vie entière qu'une équipe de projet ne peut pas.

Bonnes pratiques#

1. Financez l'équipe, pas le projet. Déplacez l'argent des budgets de projet limités dans le temps vers des budgets de produit permanents liés à un flux de valeur, comme Mik Kersten l'argumente dans Project to Product. Financez une équipe persistante pour poursuivre des résultats à travers des cycles de planification successifs, et réautorisez le financement basé sur des résultats démontrés, pas sur un plan de jalons convenu des années plus tôt.

2. Donnez aux équipes des problèmes et des résultats, pas des listes de fonctionnalités. Cadrez le mandat comme « réduire les taux de non-présentation en consultations externes » ou « réduire le temps qu'un clinicien passe à trouver un résultat », puis laissez l'équipe habilitée découvrir la meilleure solution. Une feuille de route de fonctionnalités engagées remise d'en haut recrée l'anti-modèle de l'équipe de fonctionnalité contre lequel Cagan met en garde.

3. Rendez les mesures de résultat explicites et cliniquement significatives. Convenez d'un petit ensemble de métriques de résultat en amont, idéalement comme des objectifs et résultats clés (OKR — voir Sujet 7.3). Associez chaque métrique d'efficacité à une métrique de sécurité et d'équité, afin qu'une équipe ne soit jamais récompensée pour la vitesse au coût du préjudice ou de l'élargissement de l'inégalité.

4. Gardez l'équipe proche des véritables utilisateurs. Intégrez la découverte continue : contact régulier avec les cliniciens, travailleurs de soins, administrateurs, et patients. Le NHS Service Manual et le GOV.UK Service Manual font tous deux de la recherche utilisateur une discipline permanente, pas une phase ponctuelle. Une équipe durable rend cela abordable car les relations persistent.

5. Construisez des équipes transdisciplinaires avec la sécurité clinique à l'intérieur. Une équipe produit de santé numérique a besoin, aux côtés du produit/design/ingénierie, d'un responsable de sécurité clinique (DCB0129/DCB0160), de gouvernance de l'information, et d'expertise en données. La sécurité et la gouvernance sont des entrées de conception possédées à l'intérieur de l'équipe, pas des portes ajoutées à la fin.

6. Instrumentez le produit et agissez sur les données. Les équipes durables peuvent investir dans la télémétrie, afin que les décisions soient fondées sur l'usage réel et les résultats réels plutôt que sur l'opinion. Surveillez l'adoption par cohorte pour attraper l'exclusion numérique tôt.

7. Possédez le cycle de vie entier, y compris la fin de vie. Les équipes habilitées planifient un retrait et une migration élégants, pas seulement le lancement. Décider de ne pas continuer à construire, et de consolider sur une plateforme stratégique, est une décision de produit légitime et précieuse.

8. Alignez les équipes via la stratégie, pas la microgestion. L'autonomie sans alignement produit une optimisation locale et le chaos. Une vision et stratégie de produit claires — et, à l'échelle, un cadre de portefeuille et de programme (Sujets 5.2 et 5.3) — sont ce qui vous permet d'habiliter les équipes en toute sécurité.

Questions à discuter avec votre équipe#

1. Lesquels des services que nous exploitons aujourd'hui sont véritablement des services vivants qui méritent une équipe produit durable et financée, et lesquels sont un travail fini que nous prétendons seulement nécessiter cela ? C'est la question de tri fondamentale, et la mal résoudre dans les deux sens est coûteux. Dans une organisation de santé et d'action sociale numérique, le parc est un mélange — un dossier de soins partagé ou l'application orientée patient est un service vivant, mais une sortie de centre de données ponctuelle ou un renouvellement de matériel est véritablement fini — et la réponse honnête exige de nommer chaque système significatif et d'argumenter son cas plutôt que d'appliquer un modèle de financement partout. La tension est que la machinerie financière et de gouvernance pousse habituellement tout vers des offres en capital limitées dans le temps, donc appeler quelque chose un « produit » peut sembler un plaidoyer spécial, tandis qu'appeler un service vivant un « projet » garantit discrètement la dégradation de construction-et-abandon décrite plus tôt dans le sujet. Considérez le coût de vie entier, le taux auquel les directives cliniques et la demande changent autour du service, et si le risque de sécurité patient s'accumule quand personne ne possède l'amélioration continue. Une bonne réponse nomme deux ou trois services où une équipe durable est clairement justifiée, est franche sur ceux qui sont limites, et gare explicitement le travail fini pour le Sujet 5.1 plutôt que de défendre une politique uniforme.

2. Quelles sont les deux ou trois métriques de résultat sur lesquelles nous engagerions réellement le financement d'une équipe, et comment associons-nous chacune à une mesure de sécurité et d'équité afin de ne jamais être récompensés pour la vitesse au coût du préjudice ? Résultats plutôt que livrables est facile à dire et difficile à opérationnaliser, car le moment où une métrique pilote de l'argent, elle commence à déformer le comportement. Une équipe de santé numérique chargée de « réduire les taux de non-présentation » peut atteindre le chiffre en poussant les patients les plus confiants numériquement tout en élargissant discrètement l'écart pour les cohortes plus âgées ou plus défavorisées — donc le débat doit faire émerger quelle métrique d'efficacité unique chaque équipe pourrait sur-optimiser, et ce que le garde-fou apparié de sécurité et d'équité mesure réellement. Apportez des candidats concrets à la table (erreurs de médication réduites, sortie plus rapide, adoption par localité ou proxy d'accès numérique) et testez si elles sont cliniquement significatives ou simplement faciles à instrumenter. Considérez qui possède chaque métrique, quelle est la base, et à quelle fréquence elle est révisée, car un résultat non possédé ou sans base est de la décoration. Une réponse honnête accepte que certains résultats qui nous importent sont lents ou difficiles à mesurer, résiste à l'attraction vers des chiffres d'adoption de vanité, et s'engage à publier la mesure d'équité aux côtés de celle d'efficacité afin que le compromis reste visible.

3. Combien de véritable autorité sommes-nous préparés à donner à une équipe habilitée pour changer de direction, et quel cadre stratégique empêche cette autonomie de se fragmenter en optimisation locale ? L'habilitation est le nœud du modèle opérationnel de produit et aussi sa contrefaçon la plus courante, car les organisations rebaptisent les équipes « équipes produit » tout en continuant à remettre une feuille de route fixe et à mesurer la livraison. La véritable question est où se situe la frontière : une équipe peut-elle pivoter d'une fonctionnalité sponsorisée par le conseil d'administration vers une solution différente quand la découverte montre qu'elle réalisera mieux le résultat, ou la gouvernance clinique, la gouvernance de l'information, et les contrats fournisseurs existants opposeront-ils leur veto en pratique ? La tension est que l'autonomie sans alignement produit de la duplication et une dérive à travers un ICS, tandis que l'alignement appliqué comme microgestion recrée l'usine de fonctionnalités — donc la réponse réside dans une vision et stratégie de produit explicite, et à l'échelle un cadre de portefeuille, qui contraint sans dicter. Considérez une décision récente où une équipe voulait changer de cap et demandez honnêtement si le système l'a permis. Une bonne réponse définit les décisions qu'une équipe peut prendre seule versus celles nécessitant une escalade, nomme le document de stratégie qui fournit le cadre, et est franche sur où l'organisation confond actuellement contrôle et alignement.

4. Comment finançons-nous et défendons-nous une équipe durable à travers le cycle budgétaire annuel, et que ferons-nous réellement quand les finances nous demanderont de justifier un « produit » qui n'a pas de date de fin fixe ? Le travail piloté par le produit tient ou tombe sur l'argent, et la machinerie financière du NHS et du secteur public est construite pour des offres en capital limitées dans le temps, pas un financement de revenu continu lié à un flux de valeur — donc cette question force le détail opérationnel inconfortable derrière « financer l'équipe, pas le projet ». La tension est qu'une équipe durable a besoin d'une stabilité pluriannuelle pour retenir des personnes cliniques, produit, et d'ingénierie rares, pourtant le règlement dont elle dépend est rebattu chaque année contre des schémas en capital qui montrent un début et une fin nets. Apportez les véritables chiffres : quel est le coût permanent de l'équipe, à quel flux de valeur correspond-elle, et quelle preuve de résultats démontrés justifierait une réautorisation versus un plan de jalons convenu il y a des années. Considérez comment les règles de comptabilité capital-versus-revenu, les cycles d'achat, et les contrats fournisseurs aident ou combattent le modèle dans votre organisation. Une réponse honnête nomme qui valide le budget continu, ce qui arrive à l'équipe dans une mauvaise année de règlement, et si l'organisation est préparée à convertir un véritable service en une ligne de produit plutôt que de le faire discrètement revenir par défaut vers des offres de projet.

5. Lorsque le travail piloté par le produit rencontre nos obligations de sécurité clinique et de gouvernance de l'information, la sécurité et la gouvernance sont-elles véritablement à l'intérieur de l'équipe comme entrées de conception, ou sont-elles encore des portes que l'équipe court vers et négocie autour ? Une équipe durable et habilitée qui livre continuellement change le tableau de risque, car chaque itération est un événement potentiel de sécurité clinique et de protection des données plutôt qu'une seule validation à la fin d'un projet — donc le travail de danger DCB0129/DCB0160 et les DPIA doivent vivre à l'intérieur de la cadence de l'équipe, pas s'ajouter à une porte de version. La tension est réelle : intégrer un responsable de sécurité clinique et un responsable de gouvernance de l'information dans chaque équipe produit est coûteux et ces compétences sont rares, donc les organisations sont tentées de les partager finement ou de traiter l'assurance comme une approbation que l'équipe cherche tard. Cette tentation est exactement ce qui recrée l'échec de construction-et-abandon pour la sécurité, car une équipe optimisant une métrique de résultat sous pression de livraison découvrira, sans voix de sécurité interne, le préjudice seulement après qu'il atteigne les patients. Considérez comment le dossier de sécurité est gardé vivant à travers de nombreuses petites versions, qui possède le registre des dangers, et si les collègues de gouvernance ont une véritable influence sur la découverte et la priorisation ou simplement un veto à la fin. Une bonne réponse est franche sur où la sécurité est actuellement une porte plutôt qu'une entrée de conception, et s'engage à la dotation en personnel et à la cadence qui rendent l'assurance continue abordable.

6. Comment garderons-nous une équipe durable véritablement proche des utilisateurs sous-desservis afin que l'amélioration continue réduise plutôt qu'élargisse l'exclusion numérique ? Le travail piloté par le produit promet l'équité comme un résultat de premier ordre, mais une équipe stable instrumentant son propre produit entendra naturellement le plus fort de la part des utilisateurs qui s'engagent déjà — les confiants numériquement, les connectés, ceux qui apparaissent dans la télémétrie — donc la proximité aux utilisateurs peut discrètement devenir la proximité aux utilisateurs faciles. La tension est que les cohortes les plus à risque d'exclusion (patients plus âgés, personnes dans des localités défavorisées, ceux avec un faible accès numérique ou des barrières linguistiques) sont les plus difficiles et coûteuses à atteindre via la découverte continue, pourtant ce sont précisément les personnes qu'un service de santé publique existe pour servir. Apportez une pratique concrète à la table : quelles cohortes sont délibérément recrutées dans la recherche, comment l'adoption est surveillée par localité et proxy d'accès numérique, et quel repli non numérique existe quand la voie numérique laisse quelqu'un de côté. Considérez si la métrique d'équité de l'équipe change réellement les décisions ou est simplement rapportée. Une réponse honnête admet où le pool de recherche actuel penche vers les faciles à atteindre, nomme les groupes sous-desservis dont elle n'entend pas encore parler, et décrit l'investissement spécifique — sensibilisation, numérique assisté, repli téléphonique — qui empêche l'amélioration de composer l'avantage.

En pratique : un exemple de santé et d'action sociale#

Un integrated care system (ICS) exploite une application de gestion de rendez-vous orientée patient utilisée à travers plusieurs trusts. Historiquement, chaque amélioration était un projet séparé : un fournisseur était engagé pour « ajouter des rappels SMS », l'a livré, et est parti. Six mois plus tard, les rappels tiraient mal, personne ne possédait le correctif, et une offre en capital était nécessaire pour rouvrir le contrat.

L'ICS passe à un modèle piloté par le produit. Il met en place une équipe produit durable — un chef de produit, un designer, quatre ingénieurs, un responsable de sécurité clinique, et un responsable de gouvernance de l'information — financée sur une base continue et mandatée avec un résultat, pas une liste de fonctionnalités : réduire le taux de non-présentation (DNA) et améliorer l'équité d'accès à travers la population.

L'équipe mène une découverte continue avec les patients et les planificateurs de consultations externes. Ils apprennent que les rappels aident, mais le facteur plus important de DNA dans une localité défavorisée est que les patients ne peuvent pas facilement reréserver, donc ils manquent simplement le créneau. Parce que l'équipe possède le résultat plutôt qu'une spécification, ils pivotent l'investissement d'une fonctionnalité de notifications tape-à-l'œil vers un flux simple de reréservation en libre-service, et ils instrumentent l'adoption par localité et par proxy d'accès numérique.

Sur trois cycles de planification, le taux de DNA baisse, et — de manière cruciale — l'équipe surveille la métrique d'équité et repère que l'adoption traîne chez les patients plus âgés, motivant un parcours de repli téléphonique afin que la voie numérique n'élargisse pas l'inégalité. Le financement continue car les résultats sont démontrables. Aucune fonctionnalité n'a jamais été « validée et abandonnée » ; le service continue simplement de s'améliorer. Lorsqu'une plateforme nationale offre plus tard la même capacité, la même équipe exécute la migration et retire son propre composant — une décision de vie entière qu'une équipe de projet n'aurait jamais été positionnée à prendre.

Angles sectoriels#

Startup#

Dans une petite entreprise de santé numérique, le travail piloté par le produit est le mode par défaut — souvent le seul — : une seule équipe habilitée, parfois l'entreprise entière, possède le produit de bout en bout. Le financement est la contrainte contraignante, car la piste de décollage de l'investisseur ou l'argent de subvention signifie que l'équipe doit montrer une traction de résultat (adoption, rétention, un signal clinique précoce) assez vite pour justifier le prochain tour, donc la découverte continue et l'instrumentation sont des outils de survie plutôt que des luxes. L'appétit pour le risque est élevé et la responsabilité s'exerce envers les fondateurs et investisseurs, pas un conseil d'administration ou le public, donc l'équipe peut pivoter en quelques jours. Le piège est de traiter la sécurité clinique et la gouvernance de l'information (DCB0129, DPIA) comme une charge d'entreprise à reporter — dans la santé, cette discipline est non négociable même au stade de graine, et les acheteurs du NHS exigeront une preuve DTAC avant de vous laisser approcher des données patient.

Petite entreprise#

Pour un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite ou une agence de soins à domicile, une clinique monosite, ou un petit fournisseur de health-tech ayant dépassé le stade de la startup — le travail piloté par le produit signifie rarement mettre en place une équipe transdisciplinaire dédiée, car il n'y a pas de chef de produit, designer, ou ingénieur de réserve à financer. Ici, « l'équipe durable » est souvent le gestionnaire de cabinet ou gestionnaire agréé plus un fournisseur de confiance, donc la discipline qui compte est de tenir quiconque configure et maintient le système aux résultats — moins de rendez-vous manqués, une réconciliation de médicaments plus sûre, un meilleur accès pour les résidents les plus fragiles — plutôt qu'à une installation ponctuelle. La trésorerie est serrée et continue, pas limitée par une piste de décollage, donc le mouvement sensé est d'acheter dans des produits que d'autres gardent vivants (la feuille de route d'un fournisseur bien géré, un dossier de soins partagé, une plateforme ICS) plutôt que de commander des constructions sur mesure que personne ne maintiendra. La sécurité clinique et la gouvernance de l'information mordent toujours pleinement — les mêmes obligations de déploiement DCB0160 et obligations DPIA qu'un grand trust — mais sans aucune de la capacité interne, ce qui fait du choix de fournisseurs qui possèdent leur dossier de sécurité une véritable décision de produit. L'angle d'équité est proche de la maison : un petit prestataire sert souvent exactement les patients plus âgés ou plus défavorisés les plus exposés à l'exclusion numérique, donc garder un repli non numérique n'est pas optionnel.

Entreprise#

Dans un grand trust du NHS, un integrated care system (ICS), ou une entreprise de health-tech, le modèle d'équipe durable entre en collision avec la budgétisation en capital annuelle et une machine financière en forme de projet. Le travail central est de convertir les services permanents — l'équipe d'optimisation EPR, l'équipe de dossier de soins partagé — de projets stop-start en équipes produit financées avec des budgets continus liés à des flux de valeur, ce qui est un changement de finance et de gouvernance autant qu'un changement d'organigramme. La responsabilité est en couches à travers la gouvernance clinique, la gouvernance de l'information, l'assurance du conseil d'administration, et les contrats fournisseurs, donc l'habilitation doit être associée à une stratégie de produit explicite et un alignement de portefeuille (voir Sujet 5.3 — Gestion de portefeuille et projets d'entreprise) pour arrêter des dizaines d'équipes autonomes optimisant localement. L'échelle est l'ennemie de la proximité aux utilisateurs, donc l'investissement délibéré dans la recherche intégrée est ce qui garde honnêtes les équipes d'une grande organisation.

Gouvernement#

À l'échelle nationale — NHS England, DHSC, UKHSA — le travail piloté par le produit finance des plateformes de longue durée (l'application NHS, NHS login, les API d'interopérabilité nationales) comme des produits plutôt que des programmes, tenues au GDS et au NHS Service Standard et leurs évaluations de service. Le financement circule via des règlements de revue de dépenses et des dossiers commerciaux, donc la partie difficile est de soutenir des équipes stables à travers les années fiscales et les cycles politiques quand la machinerie autour d'elles est construite pour des projets limités dans le temps. La responsabilité est envers les ministres, le Parlement, et le public via le National Audit Office, et l'obligation d'équité est statutaire, donc les métriques de résultat doivent être associées à des mesures d'équité au niveau de la population publiées. Le prix est la portée : une seule amélioration de produit peut toucher des dizaines de millions d'utilisateurs à la fois, ce qui élève à la fois le bénéfice et le coût de se tromper.

Modes d'échec courants#

• Piloté par le produit en nom seulement (« usine à fonctionnalités »). L'organisation rebaptise les équipes de projet « équipes produit » mais leur remet toujours une feuille de route fixe et les mesure sur la livraison. Correctif : changer le mandat et les métriques, pas seulement les titres de poste.
• Résultats sans garde-fou de sécurité ou d'équité. Optimiser une seule métrique d'efficacité peut cacher le préjudice ou élargir l'exclusion. Correctif : chaque métrique de résultat est associée à une mesure de sécurité et d'équité.
• « Habilitation » sans stratégie. Les équipes laissées à inventer leur propre direction dérivent et dupliquent. Correctif : forte vision et stratégie de produit, et alignement au niveau du portefeuille (Sujet 5.3).
• Appliquer le pilotage par produit à un travail véritablement fini. Une migration ponctuelle de centre de données ou un déploiement de matériel n'a pas besoin d'une équipe perpétuelle. Correctif : utiliser le travail piloté par le projet (Sujet 5.1) là où le périmètre est réellement fixe.
• Financement qui revient aux offres de projet annuelles. Une équipe durable sur un budget stop-start ne peut pas planifier ni retenir les gens. Correctif : financement continu et révisé par résultat pour le flux de valeur.
• Chef de produit comme rédacteur de tickets. Réduire le rôle à l'administration du carnet le gaspille. Correctif : tenir le chef de produit responsable de la valeur, la viabilité, et les résultats.

Modèle de maturité#

Liste de contrôle#

• Est-ce véritablement un service continu (pas un travail fini) qui convient à une équipe durable ?
• Une équipe stable et transdisciplinaire possède-t-elle le produit à travers tout son cycle de vie ?
• L'équipe est-elle mandatée avec des problèmes et résultats, pas une liste de fonctionnalités fixe ?
• Les métriques de résultat sont-elles convenues — chacune associée à une mesure de sécurité et d'équité ?
• La sécurité clinique (DCB0129/DCB0160) et la gouvernance de l'information sont-elles à l'intérieur de l'équipe ?
• L'équipe est-elle financée sur une base continue et réautorisée sur des résultats démontrés ?
• La recherche utilisateur et la découverte continues sont-elles une pratique permanente ?
• Le produit est-il instrumenté, avec l'adoption surveillée par cohorte pour attraper l'exclusion ?
• Y a-t-il une stratégie de produit claire alignant l'autonomie sur les objectifs organisationnels ?
• La fin de vie/migration élégante est-elle planifiée comme une étape explicite de cycle de vie ?

Sources clés#

• Silicon Valley Product Group (SVPG), Marty Cagan — The Product Operating Model: An Introduction and Empowered Product Teams (svpg.com); books Inspired, Empowered, and 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 and the NHS Digital Service Standard.
• GOV.UK — Government Digital Service (GDS) Service Manual and Service Standard.
• NHS Digital Clinical Safety standards DCB0129 (manufacture) and DCB0160 (deployment) of health IT systems.
• John Doerr — Measure What Matters (OKRs), for outcome-based goal setting.

Références#

1. Product management — Wikipédia — https://en.wikipedia.org/wiki/Product_management
2. Product lifecycle — Wikipédia — https://en.wikipedia.org/wiki/Product_lifecycle
3. Cross-functional team — Wikipédia — https://en.wikipedia.org/wiki/Cross-functional_team
4. Value stream — Wikipédia — https://en.wikipedia.org/wiki/Value_stream
5. Objectives and key results (OKR) — Wikipédia — https://en.wikipedia.org/wiki/OKR
6. Electronic health record — Wikipédia — https://en.wikipedia.org/wiki/Electronic_health_record
7. NHS App — Wikipédia — https://en.wikipedia.org/wiki/NHS_App
8. Digital divide — Wikipédia — 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/