Tema 5.0 — Trabajo liderado por producto

En una frase: El trabajo liderado por producto financia equipos duraderos y facultados para poseer un servicio a lo largo de toda su vida, haciéndolos responsables de resultados medibles en lugar de la entrega de una lista fija de funciones.

Por qué esto importa en la salud y la atención#

La mayor parte de lo que operan las organizaciones de salud digital y atención no es una entrega única —es un servicio vivo. La NHS App, una historia clínica electrónica, un registro de atención compartido, una vía de derivación electrónica, un sistema de gestión de casos de atención social: ninguno de estos está "terminado". Deben mejorarse continuamente a medida que cambia la orientación clínica, surgen incidentes de seguridad, la demanda cambia, y el patrimonio a su alrededor evoluciona.

Cuando gestionas un servicio vivo como una serie de proyectos desconectados, obtienes un fallo predecible: un proveedor construye según una especificación, el dinero se acaba, el equipo se disuelve, y el servicio se deja pudrir hasta la próxima solicitud de capital. Los clínicos evitan las brechas, los riesgos de seguridad del paciente se acumulan, y la equidad sufre porque las personas menos capaces de tolerar un servicio torpe son las que tienen mayor necesidad. El trabajo liderado por producto existe para romper ese ciclo. Mantiene a un equipo estable cerca de los usuarios y de los resultados, para que el servicio se vuelva más seguro, más usable, y más equitativo con el tiempo en lugar de degradarse entre rondas de financiación.

Lo que está en juego también es financiero y estatutario. El dinero público está mejor protegido por un equipo que valida continuamente si un servicio realmente mejora la atención que por un proyecto que mide el éxito como "entregado a tiempo y dentro del presupuesto" independientemente de si alguien se benefició. Este tema se sitúa junto al Tema 5.1 — Trabajo liderado por proyecto y el Tema 5.2 — Trabajo liderado por programa; los tres son herramientas complementarias, no rivales, y el Tema 5.3 — Gestión de cartera y proyectos empresariales (EPPM) explica cómo mantenerlos unidos.

Conceptos clave#

Equipo de producto duradero. Un equipo multifuncional y de larga duración que posee un producto o servicio a través de todo su ciclo de vida. El equipo persiste; el trabajo fluye hacia él. Esta es la unidad atómica del modelo operativo de producto descrito por Marty Cagan y el Silicon Valley Product Group (SVPG): un grupo estable de un gerente de producto, un diseñador de producto, e ingenieros, apoyado por experiencia clínica y de datos en un contexto de salud.

Equipo facultado. Cagan traza una línea clara entre un "equipo de funciones" al que se le entrega una hoja de ruta de cosas que construir, y un "equipo facultado" al que se le entregan problemas por resolver y resultados por lograr, y en quien se confía para encontrar la mejor solución. La facultad no es una licencia para hacer cualquier cosa; es responsabilidad por los resultados dentro de un marco estratégico claro.

Resultados sobre productos entregables. El producto entregable es lo que envías —una función, una versión, una pantalla. Un resultado es el cambio en el mundo que resulta —menos citas perdidas, alta más rápida, menos errores de medicación, adopción más equitativa. El trabajo liderado por producto mide a los equipos por resultados, porque enviar una función que nadie usa, o que no hace que nadie esté más seguro, es desperdicio disfrazado de progreso.

Gerente de producto. El líder de gestión de producto, responsable del valor y la viabilidad del producto: ¿vale la pena construir esto, la gente lo usará, encaja con la estrategia, regulaciones, y finanzas de la organización? En la salud y la atención este rol debe asociarse estrechamente con los líderes de seguridad clínica y gobernanza de la información, no situarse por encima de ellos.

Modelo operativo de producto. SVPG es explícito en que esto es un modelo, no una metodología o un marco rígido: un conjunto de principios sobre cómo una empresa construye y opera productos habilitados por tecnología —equipos facultados, responsabilidad por resultados, descubrimiento continuo, y estrategia de producto— en lugar de un proceso prescrito que instalas.

Ciclo de vida del producto. Descubrimiento (¿hay un problema real que vale la pena resolver?), entrega (constrúyelo de forma segura y bien), crecimiento y optimización (mejorar la adopción y los resultados), y eventualmente retiro (retirar o reemplazar con elegancia). Los equipos liderados por producto poseen todo esto, por lo que pueden hacer disyuntivas sensatas de toda la vida que un equipo de proyecto no puede.

Buenas prácticas#

1. Financiar al equipo, no al proyecto. Traslada el dinero de presupuestos de proyecto con límite de tiempo a presupuestos de producto permanentes vinculados a un flujo de valor, como argumenta Mik Kersten en Project to Product. Financia a un equipo persistente para perseguir resultados a través de ciclos de planificación sucesivos, y reautoriza la financiación en base a resultados demostrados, no a un plan de hitos acordado años antes.

2. Dar a los equipos problemas y resultados, no listas de funciones. Enmarca el mandato como "reducir las tasas de inasistencia en ambulatorios" o "reducir el tiempo que un clínico pasa buscando un resultado", luego deja que el equipo facultado descubra la mejor solución. Una hoja de ruta de funciones comprometidas entregada desde arriba recrea el antipatrón de equipo de funciones contra el que advierte Cagan.

3. Hacer explícitas y clínicamente significativas las medidas de resultado. Acuerda un pequeño conjunto de métricas de resultado por adelantado, idealmente como objetivos y resultados clave (OKR — véase el Tema 7.3). Empareja cada métrica de eficiencia con una métrica de seguridad y una de equidad, para que un equipo nunca sea recompensado por la velocidad a costa del daño o de ampliar la desigualdad.

4. Mantener al equipo cerca de usuarios reales. Incorpora el descubrimiento continuo: contacto regular con clínicos, trabajadores de atención, administradores, y pacientes. Tanto el NHS Service Manual como el GOV.UK Service Manual hacen de la investigación de usuarios una disciplina permanente, no una fase única. Un equipo duradero hace esto asequible porque las relaciones persisten.

5. Construir equipos multidisciplinarios con seguridad clínica dentro de ellos. Un equipo de producto de salud digital necesita, junto al producto/diseño/ingeniería, un oficial de seguridad clínica (DCB0129/DCB0160), gobernanza de la información, y experiencia en datos. La seguridad y la gobernanza son entradas de diseño poseídas dentro del equipo, no puertas añadidas al final.

6. Instrumentar el producto y actuar sobre los datos. Los equipos duraderos pueden invertir en telemetría, para que las decisiones se fundamenten en el uso real y resultados reales en lugar de opinión. Vigila la adopción por cohorte para detectar la exclusión digital temprano.

7. Poseer todo el ciclo de vida, incluyendo el retiro. Los equipos facultados planifican para un retiro y migración elegantes, no solo el lanzamiento. Decidir no seguir construyendo, y consolidar en una plataforma estratégica, es una decisión de producto legítima y valiosa.

8. Alinear a los equipos a través de la estrategia, no la microgestión. La autonomía sin alineación produce optimización local y caos. Una visión y estrategia de producto claras —y, a escala, un marco de cartera y programa (Temas 5.2 y 5.3)— es lo que te permite facultar a los equipos de forma segura.

Preguntas para debatir con tu equipo#

1. ¿Cuáles de los servicios que operamos hoy son genuinamente servicios vivos que merecen un equipo de producto duradero y financiado, y cuáles son trabajo finito que solo pretendemos que necesita uno? Esta es la pregunta de clasificación fundamental, y equivocarla en cualquier dirección es costoso. En una organización de salud digital y atención el patrimonio es una mezcla —un registro de atención compartido o la aplicación orientada al paciente es un servicio vivo, pero una salida única de centro de datos o una renovación de hardware es genuinamente finita— y la respuesta honesta requiere nombrar cada sistema significativo y argumentar su caso en lugar de aplicar un modelo de financiación en todas partes. La tensión es que la maquinaria de finanzas y gobernanza generalmente empuja todo hacia solicitudes de capital con límite de tiempo, así que llamar "producto" a algo puede sentirse como un alegato especial, mientras que llamar "proyecto" a un servicio vivo garantiza silenciosamente la decadencia de construir-y-abandonar descrita anteriormente en el tema. Considera el coste de toda la vida, la tasa a la que cambian la orientación clínica y la demanda alrededor del servicio, y si el riesgo de seguridad del paciente se acumula cuando nadie posee la mejora continua. Una buena respuesta nombra dos o tres servicios donde un equipo duradero está claramente justificado, es franca sobre los que son límite, y explícitamente reserva el trabajo finito para el Tema 5.1 en lugar de defender una política uniforme.

2. ¿Cuáles son las dos o tres métricas de resultado sobre las que realmente apostaríamos la financiación de un equipo, y cómo emparejamos cada una con una medida de seguridad y equidad para que nunca seamos recompensados por la velocidad a costa del daño? Resultados sobre productos entregables es fácil de decir y difícil de operacionalizar, porque en el momento en que una métrica impulsa el dinero comienza a distorsionar el comportamiento. A un equipo de salud digital al que se le dice que "reduzca las tasas de inasistencia" puede alcanzar la cifra empujando a los pacientes más seguros digitalmente mientras amplía silenciosamente la brecha para cohortes mayores o más desfavorecidas —así que el debate tiene que sacar a la luz qué métrica única de eficiencia podría sobreoptimizar cada equipo, y qué mide realmente la barrera de seguridad y equidad emparejada. Trae candidatos concretos a la mesa (errores de medicación reducidos, alta más rápida, adopción por localidad o proxy de acceso digital) y pon a prueba si son clínicamente significativos o meramente fáciles de instrumentar. Considera quién posee cada métrica, cuál es la línea base, y con qué frecuencia se revisa, porque un resultado sin propietario o sin línea base es decoración. Una respuesta honesta acepta que algunos resultados que nos importan son lentos o difíciles de medir, resiste la atracción hacia números de adopción de vanidad, y se compromete a publicar la medida de equidad junto a la de eficiencia para que la disyuntiva permanezca visible.

3. ¿Cuánta autoridad real estamos preparados para dar a un equipo facultado para cambiar de dirección, y qué marco estratégico evita que esa autonomía se fragmente en optimización local? La facultad es el eje del modelo operativo de producto y también su falsificación más común, porque las organizaciones reetiquetan equipos como "equipos de producto" mientras siguen entregando una hoja de ruta fija y midiendo la entrega. La pregunta genuina es dónde se sitúa el límite: ¿puede un equipo pivotar de una función patrocinada por la junta directiva a una solución diferente cuando el descubrimiento muestra que logrará mejor el resultado, o la gobernanza clínica, la gobernanza de la información, y los contratos de proveedores existentes vetarán eso en la práctica? La tensión es que la autonomía sin alineación produce duplicación y deriva a través de un ICS, mientras que la alineación aplicada como microgestión recrea la fábrica de funciones —así que la respuesta está en una visión y estrategia de producto explícita, y a escala un marco de cartera, que restringe sin dictar. Mira una decisión reciente donde un equipo quiso cambiar de rumbo y pregunta honestamente si el sistema lo permitió. Una buena respuesta define las decisiones que un equipo puede tomar solo frente a las que necesitan escalación, nombra el documento de estrategia que proporciona el marco, y es franca sobre dónde la organización actualmente confunde control con alineación.

4. ¿Cómo financiamos y defendemos a un equipo duradero a través del ciclo de presupuesto anual, y qué haremos realmente cuando finanzas nos pida justificar un "producto" que no tiene fecha de finalización fija? El trabajo liderado por producto se sostiene o cae según el dinero, y la maquinaria de finanzas del NHS y el sector público está construida para solicitudes de capital con límite de tiempo, no financiación de ingresos continua vinculada a un flujo de valor —así que esta pregunta fuerza el detalle operativo incómodo detrás de "financiar al equipo, no al proyecto". La tensión es que un equipo duradero necesita estabilidad de varios años para retener a personas clínicas, de producto, e ingeniería escasas, sin embargo el acuerdo del que depende se renegocia cada año contra esquemas de capital que muestran un inicio y fin ordenados. Trae los números reales: cuál es el coste permanente del equipo, a qué flujo de valor se mapea, y qué evidencia de resultados demostrados justificaría la reautorización frente a un plan de hitos acordado años antes. Considera cómo las reglas de contabilidad de capital versus ingresos, los ciclos de contratación, y los contratos de proveedores ayudan o luchan contra el modelo en tu organización. Una respuesta honesta nombra quién aprueba el presupuesto continuo, qué pasa con el equipo en un mal año de acuerdo, y si la organización está preparada para convertir un servicio genuino en una línea de producto en lugar de silenciosamente hacer que vuelva por defecto a solicitudes de proyecto.

5. Cuando el trabajo liderado por producto se encuentra con nuestros deberes de seguridad clínica y gobernanza de la información, ¿la seguridad y la gobernanza están genuinamente dentro del equipo como entradas de diseño, o siguen siendo puertas hacia las que el equipo corre y negocia? Un equipo duradero y facultado que envía continuamente cambia el panorama de riesgo, porque cada iteración es un potencial evento de seguridad clínica y protección de datos en lugar de una sola aprobación al final de un proyecto —así que el trabajo de peligros DCB0129/DCB0160 y las DPIA tienen que vivir dentro del ritmo del equipo, no añadirse en una puerta de lanzamiento. La tensión es real: incorporar a un oficial de seguridad clínica y un líder de gobernanza de la información en cada equipo de producto es caro y esas habilidades son escasas, así que las organizaciones se sienten tentadas a compartirlas delgadamente o tratar el aseguramiento como una aprobación que el equipo busca tarde. Esa tentación es exactamente lo que recrea el fallo de construir-y-abandonar para la seguridad, porque un equipo que optimiza una métrica de resultado bajo presión de entrega descubrirá el daño, sin una voz de seguridad interna, solo después de que alcance a los pacientes. Considera cómo se mantiene vivo el caso de seguridad a través de muchas versiones pequeñas, quién posee el registro de peligros, y si los colegas de gobernanza tienen influencia real en el descubrimiento y priorización o meramente un veto al final. Una buena respuesta es franca sobre dónde la seguridad es actualmente una puerta en lugar de una entrada de diseño, y se compromete al personal y ritmo que hacen asequible el aseguramiento continuo.

6. ¿Cómo mantendremos a un equipo duradero genuinamente cerca de usuarios desatendidos para que la mejora continua reduzca en lugar de ampliar la exclusión digital? El trabajo liderado por producto promete la equidad como un resultado de primera clase, pero un equipo estable que instrumenta su propio producto naturalmente escuchará más fuerte a los usuarios que ya participan —los seguros digitalmente, los conectados, los que aparecen en la telemetría— así que la proximidad a los usuarios puede convertirse silenciosamente en proximidad a los usuarios fáciles. La tensión es que las cohortes con mayor riesgo de exclusión (pacientes mayores, personas en localidades desfavorecidas, aquellos con bajo acceso digital o barreras de idioma) son las más difíciles y costosas de alcanzar a través del descubrimiento continuo, sin embargo son precisamente las personas para las que existe un servicio de salud público. Trae práctica concreta a la mesa: qué cohortes se reclutan deliberadamente en la investigación, cómo se vigila la adopción por localidad y proxy de acceso digital, y qué alternativa no digital existe cuando la ruta digital deja a alguien atrás. Considera si la métrica de equidad del equipo realmente cambia decisiones o meramente se reporta. Una respuesta honesta admite dónde el grupo de investigación actual se inclina hacia los fáciles de alcanzar, nombra los grupos desatendidos de los que todavía no escucha, y describe la inversión específica —alcance, digital asistido, alternativa telefónica— que evita que la mejora componga la ventaja.

En la práctica: un ejemplo de salud y atención#

Un sistema de atención integrada (ICS) opera una aplicación orientada al paciente de gestión de citas usada a través de varios fideicomisos. Históricamente cada mejora era un proyecto separado: se contrataba a un proveedor para "añadir recordatorios SMS", lo entregaba, y se marchaba. Seis meses después los recordatorios funcionaban mal, nadie poseía la corrección, y se necesitaba una solicitud de capital para reabrir el contrato.

El ICS cambia a un modelo liderado por producto. Establece un equipo de producto duradero —un gerente de producto, un diseñador, cuatro ingenieros, un oficial de seguridad clínica, y un líder de gobernanza de la información— financiado sobre una base continua y con mandato de un resultado, no una lista de funciones: reducir la tasa de inasistencia (DNA) y mejorar la equidad de acceso a través de la población.

El equipo ejecuta descubrimiento continuo con pacientes y programadores ambulatorios. Aprenden que los recordatorios ayudan, pero el mayor impulsor de las DNA en una localidad desfavorecida es que los pacientes no pueden reprogramar fácilmente, así que simplemente pierden la cita. Porque el equipo posee el resultado en lugar de una especificación, pivotan la inversión de una función llamativa de notificaciones a un flujo simple de auto-reprogramación, e instrumentan la adopción por localidad y por proxy de acceso digital.

A través de tres ciclos de planificación la tasa de DNA cae, y —crucialmente— el equipo monitorea la métrica de equidad y detecta que la adopción se retrasa entre pacientes mayores, impulsando una vía alternativa telefónica para que la ruta digital no amplíe la desigualdad. La financiación continúa porque los resultados son demostrables. Ninguna función fue jamás "aprobada y abandonada"; el servicio simplemente sigue mejorando. Cuando una plataforma nacional más tarde ofrece la misma capacidad, el mismo equipo ejecuta la migración y retira su propio componente —una decisión de toda la vida que un equipo de proyecto nunca habría estado posicionado para tomar.

Perspectivas sectoriales#

Startup#

En una pequeña empresa de salud digital, el trabajo liderado por producto es el modo predeterminado —a menudo el único: un solo equipo facultado, a veces toda la empresa, posee el producto de principio a fin. La financiación es la restricción vinculante, porque el margen de tiempo del inversor o el dinero de subvención significa que el equipo debe mostrar tracción de resultado (adopción, retención, una señal clínica temprana) suficientemente rápido para justificar la siguiente ronda, así que el descubrimiento continuo y la instrumentación son herramientas de supervivencia en lugar de lujos. El apetito de riesgo es alto y la responsabilidad recae en los fundadores e inversores, no una junta directiva o el público, así que el equipo puede pivotar en días. La trampa es tratar la seguridad clínica y la gobernanza de la información (DCB0129, DPIA) como gastos generales empresariales a diferir —en la salud esa disciplina no es negociable incluso en la etapa semilla, y los compradores del NHS exigirán evidencia DTAC antes de dejarte cerca de datos de pacientes.

Pequeña empresa#

Para un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados o agencia de atención domiciliaria, una clínica de un solo emplazamiento, o un pequeño proveedor de tecnología de salud pasada la etapa de startup— el trabajo liderado por producto raramente significa establecer un equipo multifuncional dedicado, porque no hay un gerente de producto, diseñador, o ingeniero de sobra para financiar. Aquí el "equipo duradero" a menudo es el gerente de la consulta o gerente registrado más un proveedor de confianza, así que la disciplina que importa es responsabilizar a quien configura y mantiene el sistema por resultados —menos citas perdidas, conciliación de medicamentos más segura, mejor acceso para los residentes más frágiles— en lugar de una instalación única. El dinero es ajustado y continuo, no limitado por margen, así que el movimiento sensato es comprar en productos que otros mantienen vivos (la hoja de ruta de un proveedor bien operado, un registro de atención compartido, una plataforma ICS) en lugar de encargar construcciones a medida que nadie mantendrá. La seguridad clínica y la gobernanza de la información todavía muerden en su totalidad —los mismos deberes de despliegue DCB0160 y obligaciones DPIA que un gran fideicomiso— pero sin nada de la capacidad interna, lo que hace de elegir proveedores que poseen su caso de seguridad una decisión de producto genuina. El ángulo de equidad está cerca de casa: un pequeño proveedor a menudo sirve exactamente a los pacientes mayores o más desfavorecidos más expuestos a la exclusión digital, así que mantener una alternativa no digital no es opcional.

Gran organización#

En un gran fideicomiso del NHS, sistema de atención integrada (ICS), o empresa de tecnología de salud, el modelo de equipo duradero choca con el presupuesto de capital anual y una maquinaria de finanzas con forma de proyecto. El trabajo central es convertir servicios permanentes —el equipo de optimización de EPR, el equipo de registro de atención compartido— de proyectos de arranque-y-parada a equipos de producto financiados con presupuestos continuos vinculados a flujos de valor, que es un cambio de finanzas y gobernanza tanto como uno de organigrama. La responsabilidad está en capas a través de la gobernanza clínica, la gobernanza de la información, el aseguramiento de la junta directiva, y los contratos de proveedores, así que la facultad tiene que emparejarse con una estrategia de producto explícita y alineación de cartera (véase el Tema 5.3 — Gestión de cartera y proyectos empresariales) para detener docenas de equipos autónomos optimizando localmente. La escala es el enemigo de la proximidad a los usuarios, así que la inversión deliberada en investigación incorporada es lo que mantiene honestos a los equipos de una gran organización.

Gobierno#

A escala nacional —NHS England, DHSC, UKHSA— el trabajo liderado por producto financia plataformas de larga duración (la NHS App, NHS login, las API de interoperabilidad nacionales) como productos en lugar de programas, sujetas al GDS y NHS Service Standard y sus evaluaciones de servicio. La financiación fluye a través de acuerdos de Spending Review y casos de negocio, así que la parte difícil es sostener equipos estables a través de años fiscales y ciclos políticos cuando la maquinaria a su alrededor está construida para proyectos con límite de tiempo. La responsabilidad es ante ministros, el Parlamento, y el público vía la National Audit Office, y el deber de equidad es estatutario, así que las métricas de resultado deben emparejarse con medidas de equidad a nivel de población publicadas. El premio es alcance: una sola mejora de producto puede tocar a decenas de millones de usuarios a la vez, lo que eleva tanto el beneficio como el coste de equivocarse.

Modos de fallo comunes#

• Liderado por producto solo de nombre ("fábrica de funciones"). La organización reetiqueta equipos de proyecto como "equipos de producto" pero sigue entregándoles una hoja de ruta fija y midiéndolos por la entrega. Corrección: cambia el mandato y las métricas, no solo los títulos de trabajo.
• Resultados sin barrera de seguridad o equidad. Optimizar una sola métrica de eficiencia puede ocultar daño o ampliar la exclusión. Corrección: cada métrica de resultado se empareja con una medida de seguridad y equidad.
• "Facultad" sin estrategia. Los equipos dejados a inventar su propia dirección derivan y duplican. Corrección: visión y estrategia de producto fuertes, y alineación a nivel de cartera (Tema 5.3).
• Aplicar liderado por producto a trabajo genuinamente finito. Una migración de centro de datos única o un despliegue de hardware no necesita un equipo perpetuo. Corrección: usa trabajo liderado por proyecto (Tema 5.1) donde el alcance realmente es fijo.
• Financiación que revierte a solicitudes de proyecto anuales. Un equipo duradero con un presupuesto de arranque-y-parada no puede planificar ni retener personas. Corrección: financiación continua revisada por resultado para el flujo de valor.
• Gerente de producto como escritor de tickets. Reducir el rol a administración de la lista de pendientes lo desperdicia. Corrección: responsabiliza al gerente de producto por el valor, la viabilidad, y los resultados.

Modelo de madurez#

Lista de verificación#

• ¿Es este genuinamente un servicio continuo (no trabajo finito) que se adapta a un equipo duradero?
• ¿Un equipo estable y multifuncional posee el producto a través de todo su ciclo de vida?
• ¿El equipo tiene mandato con problemas y resultados, no una lista fija de funciones?
• ¿Se acuerdan métricas de resultado —cada una emparejada con una medida de seguridad y equidad?
• ¿La seguridad clínica (DCB0129/DCB0160) y la gobernanza de la información están dentro del equipo?
• ¿El equipo está financiado sobre una base continua y reautorizado en resultados demostrados?
• ¿La investigación y descubrimiento continuo de usuarios es una práctica permanente?
• ¿El producto está instrumentado, con la adopción vigilada por cohorte para detectar la exclusión?
• ¿Hay una estrategia de producto clara que alinea la autonomía con los objetivos organizacionales?
• ¿Se planifica el retiro/migración elegante como una etapa explícita del ciclo de vida?

Fuentes clave#

• Silicon Valley Product Group (SVPG), Marty Cagan — The Product Operating Model: An Introduction y Empowered Product Teams (svpg.com); libros Inspired, Empowered, y 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 y el NHS Digital Service Standard.
• GOV.UK — Government Digital Service (GDS) Service Manual y Service Standard.
• NHS Digital Clinical Safety standards DCB0129 (fabricación) y DCB0160 (despliegue) de sistemas de TI de salud.
• John Doerr — Measure What Matters (OKR), para el establecimiento de objetivos basado en resultados.

Referencias#

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/