Tópico 5.0 — Trabalho conduzido por produto

Em uma frase: O trabalho conduzido por produto financia equipes duradouras e empoderadas para serem donas de um serviço durante toda a sua vida, responsabilizando-as por resultados mensuráveis e não pela entrega de uma lista fixa de funcionalidades.

Por que isso importa na saúde e nos cuidados#

A maior parte do que as organizações de saúde digital e de cuidados operam não é uma entrega pontual — é um serviço vivo. O NHS App, um prontuário eletrônico do paciente, um prontuário de cuidados compartilhado, uma via de encaminhamento eletrônico, um sistema de gestão de casos de cuidados sociais: nenhum deles está "terminado". Precisam ser melhorados continuamente à medida que as diretrizes clínicas mudam, que incidentes de segurança surgem, que a demanda se desloca e que o parque tecnológico ao redor evolui.

Quando você gerencia um serviço vivo como uma série de projetos desconexos, obtém uma falha previsível: um fornecedor constrói conforme uma especificação, o dinheiro acaba, a equipe se dissolve e o serviço é deixado a apodrecer até o próximo pedido de capital. Os clínicos contornam as lacunas, os riscos à segurança do paciente se acumulam e a equidade sofre, porque as pessoas menos capazes de tolerar um serviço desajeitado são as de maior necessidade. O trabalho conduzido por produto existe para quebrar esse ciclo. Mantém uma equipe estável perto dos usuários e dos resultados, de modo que o serviço fique mais seguro, mais usável e mais equitativo com o tempo, em vez de se degradar entre rodadas de financiamento.

O que está em jogo também é financeiro e estatutário. O dinheiro público é mais bem protegido por uma equipe que valida continuamente se um serviço realmente melhora o cuidado do que por um projeto que mede o sucesso como "entregue no prazo e dentro do orçamento", independentemente de alguém ter se beneficiado. Este tópico se situa ao lado do Tópico 5.1 — Trabalho conduzido por projeto e do Tópico 5.2 — Trabalho conduzido por programa; os três são ferramentas complementares, e não rivais, e o Tópico 5.3 — Gestão de portfólio corporativo de projetos (EPPM) explica como mantê-los juntos.

Conceitos centrais#

Equipe de produto duradoura. Uma equipe multifuncional e de longa duração, dona de um produto ou serviço durante todo o seu ciclo de vida. A equipe persiste; o trabalho flui até ela. Esta é a unidade atômica do modelo operacional de produto descrito por Marty Cagan e pelo Silicon Valley Product Group (SVPG): um grupo estável de um gerente de produto, um designer de produto e engenheiros, apoiados, num contexto de saúde, por expertise clínica e de dados.

Equipe empoderada. Cagan traça uma linha nítida entre uma "equipe de funcionalidades", a quem se entrega um roteiro de coisas a construir, e uma "equipe empoderada", a quem se entregam problemas a resolver e resultados a alcançar, e em quem se confia para encontrar a melhor solução. Empoderamento não é licença para fazer qualquer coisa; é a responsabilização por resultados dentro de um marco estratégico claro.

Resultados acima de produtos entregues. O produto entregue é o que você lança — uma funcionalidade, uma versão, uma tela. Um resultado é a mudança no mundo que daí decorre — menos consultas perdidas, alta mais rápida, menos erros de medicação, adesão mais equitativa. O trabalho conduzido por produto mede as equipes por resultados, porque lançar uma funcionalidade que ninguém usa, ou que não torna ninguém mais seguro, é desperdício vestido de progresso.

Gerente de produto. O líder de gestão de produto, responsável pelo valor e pela viabilidade do produto: vale a pena construí-lo, as pessoas o usarão, ele se ajusta à estratégia, às regulações e às finanças da organização? Na saúde e nos cuidados, esse papel deve atuar em estreita parceria com os responsáveis por segurança clínica e governança da informação, e não pairar acima deles.

Modelo operacional de produto. O SVPG é explícito de que isto é um modelo, e não uma metodologia ou um arcabouço rígido: um conjunto de princípios sobre como uma empresa constrói e opera produtos habilitados por tecnologia — equipes empoderadas, responsabilização por resultados, descoberta contínua e estratégia de produto —, e não um processo prescrito que se instala.

Ciclo de vida do produto. Descoberta (há um problema real que valha a pena resolver?), entrega (construí-lo com segurança e qualidade), crescimento e otimização (melhorar a adesão e os resultados) e, por fim, descontinuação (aposentar ou substituir com elegância). As equipes conduzidas por produto são donas de tudo isso, razão pela qual podem fazer escolhas sensatas de vida inteira que uma equipe de projeto não pode.

Boas práticas#

1. Financie a equipe, e não o projeto. Desloquem o dinheiro de orçamentos de projeto com prazo definido para orçamentos permanentes de produto, ligados a um fluxo de valor, como argumenta Mik Kersten em Project to Product. Financiem uma equipe persistente para perseguir resultados ao longo de sucessivos ciclos de planejamento e reautorizem o financiamento com base em resultados demonstrados, e não num plano de marcos acordado anos antes.

2. Dê às equipes problemas e resultados, e não listas de funcionalidades. Formulem o mandato como "reduzir as taxas de não comparecimento em ambulatórios" ou "cortar o tempo que um clínico gasta procurando um resultado" e deixem a equipe empoderada descobrir a melhor solução. Um roteiro de funcionalidades comprometidas, entregue de cima, recria o antipadrão da equipe de funcionalidades contra o qual Cagan adverte.

3. Torne explícitas e clinicamente significativas as medidas de resultado. Acordem de antemão um pequeno conjunto de métricas de resultado, idealmente como objetivos e resultados-chave (OKRs — ver Tópico 7.3). Pareiem toda métrica de eficiência com uma métrica de segurança e uma de equidade, para que uma equipe nunca seja recompensada pela velocidade ao custo de dano ou de ampliação da desigualdade.

4. Mantenha a equipe perto dos usuários reais. Incorporem a descoberta contínua: contato regular com clínicos, trabalhadores de cuidados, administradores e pacientes. Tanto o NHS Service Manual quanto o GOV.UK Service Manual tornam a pesquisa com usuários uma disciplina permanente, e não uma fase pontual. Uma equipe duradoura torna isso viável, porque os relacionamentos persistem.

5. Construa equipes multidisciplinares com a segurança clínica dentro delas. Uma equipe de produto de saúde digital precisa, além de produto/design/engenharia, de um responsável pela segurança clínica (DCB0129/DCB0160), de governança da informação e de expertise em dados. A segurança e a governança são insumos de projeto, de que a equipe é dona, e não portões acrescentados no fim.

6. Instrumente o produto e aja sobre os dados. Equipes duradouras podem investir em telemetria, para que as decisões se baseiem no uso e nos resultados reais, e não em opinião. Acompanhem a adesão por coorte para detectar cedo a exclusão digital.

7. Seja dono do ciclo de vida inteiro, incluindo a descontinuação. Equipes empoderadas planejam a aposentadoria e a migração elegantes, e não apenas o lançamento. Decidir não continuar construindo e consolidar numa plataforma estratégica é uma decisão de produto legítima e valiosa.

8. Alinhe as equipes pela estratégia, e não pela microgestão. Autonomia sem alinhamento produz otimização local e caos. Uma visão e uma estratégia de produto claras — e, em escala, um marco de portfólio e de programa (Tópicos 5.2 e 5.3) — é o que permite empoderar as equipes com segurança.

Perguntas para discutir com a sua equipe#

1. Quais dos serviços que operamos hoje são genuinamente serviços vivos que merecem uma equipe de produto duradoura e financiada, e quais são trabalho finito que apenas fingimos precisar de uma? Esta é a pergunta fundamental de triagem, e errá-la em qualquer direção é caro. Numa organização de saúde digital e de cuidados, o parque é uma mistura — um prontuário de cuidados compartilhado ou o aplicativo voltado ao paciente é um serviço vivo, mas a saída de um data center pontual ou a renovação de hardware é genuinamente finita —, e a resposta honesta exige nomear cada sistema significativo e defender o seu caso, em vez de aplicar um só modelo de financiamento a tudo. A tensão é que a máquina financeira e de governança costuma empurrar tudo para pedidos de capital com prazo definido, de modo que chamar algo de "produto" pode parecer defesa em causa própria, enquanto chamar de "projeto" um serviço vivo garante, em silêncio, a decadência de construir e abandonar descrita antes neste tópico. Considerem o custo de vida inteira, o ritmo em que as diretrizes clínicas e a demanda mudam ao redor do serviço e se o risco à segurança do paciente se acumula quando ninguém é dono da melhoria contínua. Uma boa resposta nomeia dois ou três serviços em que uma equipe duradoura é claramente justificada, é franca sobre os casos limítrofes e estaciona explicitamente o trabalho finito para o Tópico 5.1, em vez de defender uma política única para tudo.

2. Quais são as duas ou três métricas de resultado em que de fato apostaríamos o financiamento de uma equipe, e como pareamos cada uma com uma medida de segurança e uma de equidade para nunca sermos recompensados pela velocidade ao custo de dano? Resultados acima de produtos entregues é fácil de dizer e difícil de operacionalizar, porque no instante em que uma métrica passa a movimentar dinheiro, começa a distorcer o comportamento. Uma equipe de saúde digital a quem se diz para "reduzir as taxas de não comparecimento" pode atingir o número incentivando os pacientes mais confiantes no digital, enquanto amplia em silêncio a distância para as coortes mais velhas ou mais carentes — de modo que o debate precisa trazer à tona qual métrica única de eficiência cada equipe poderia otimizar em excesso e o que a salvaguarda pareada de segurança e de equidade de fato mede. Levem à mesa candidatos concretos (menos erros de medicação, alta mais rápida, adesão por localidade ou por indicador de acesso digital) e testem sob estresse se são clinicamente significativos ou apenas fáceis de instrumentar. Considerem quem é dono de cada métrica, qual é a linha de base e com que frequência é revista, porque um resultado sem dono ou sem linha de base é decoração. Uma resposta honesta aceita que alguns resultados que nos importam são lentos ou difíceis de medir, resiste à atração por números de adesão vaidosos e se compromete a publicar a medida de equidade ao lado da de eficiência, para que a concessão permaneça visível.

3. Quanta autoridade real estamos dispostos a dar a uma equipe empoderada para mudar de direção, e que marco estratégico impede essa autonomia de se fragmentar em otimização local? O empoderamento é o cerne do modelo operacional de produto e também a sua falsificação mais comum, porque as organizações rebatizam equipes de "equipes de produto" enquanto continuam entregando um roteiro fixo e medindo a entrega. A pergunta genuína é onde fica a fronteira: uma equipe pode mudar de uma funcionalidade patrocinada pelo conselho para uma solução diferente quando a descoberta mostra que ela realizará melhor o resultado, ou a governança clínica, a governança da informação e os contratos existentes com fornecedores vetarão isso na prática? A tensão é que a autonomia sem alinhamento produz duplicação e deriva num ICS, enquanto o alinhamento imposto como microgestão recria a fábrica de funcionalidades — de modo que a resposta está numa visão e estratégia de produto explícitas e, em escala, num marco de portfólio, que restrinja sem ditar. Considerem uma decisão recente em que uma equipe quis mudar de rumo e perguntem honestamente se o sistema deixou. Uma boa resposta define as decisões que uma equipe pode tomar sozinha e as que exigem escalonamento, nomeia o documento de estratégia que fornece o marco e é franca sobre onde a organização hoje confunde controle com alinhamento.

4. Como financiamos e defendemos uma equipe duradoura ao longo do ciclo orçamentário anual, e o que de fato faremos quando as finanças nos pedirem para justificar um "produto" sem data final fixa? O trabalho conduzido por produto se sustenta ou cai pelo dinheiro, e a máquina das finanças do NHS e do setor público é construída para pedidos de capital com prazo definido, e não para um financiamento corrente de custeio ligado a um fluxo de valor — de modo que esta pergunta força o incômodo detalhe operacional por trás de "financie a equipe, e não o projeto". A tensão é que uma equipe duradoura precisa de estabilidade plurianual para reter pessoas escassas de clínica, produto e engenharia, mas o orçamento de que depende é disputado de novo todo ano contra esquemas de capital que mostram um começo e um fim arrumados. Tragam os números reais: qual é o custo permanente da equipe, a que fluxo de valor ela corresponde e que evidência de resultados demonstrados justificaria a reautorização, em contraste com um plano de marcos acordado anos atrás. Considerem como as regras contábeis de capital versus custeio, os ciclos de aquisição e os contratos com fornecedores ajudam ou combatem o modelo na sua organização. Uma resposta honesta nomeia quem aprova o orçamento corrente, o que acontece com a equipe num ano de orçamento ruim e se a organização está preparada para converter um serviço genuíno numa linha de produto, em vez de relegá-lo em silêncio de volta a pedidos de projeto.

5. Quando o trabalho conduzido por produto encontra os nossos deveres de segurança clínica e de governança da informação, a segurança e a governança estão genuinamente dentro da equipe como insumos de projeto, ou ainda são portões em direção aos quais a equipe corre e em torno dos quais negocia? Uma equipe duradoura e empoderada que entrega continuamente muda o quadro de risco, porque cada iteração é um potencial evento de segurança clínica e de proteção de dados, e não uma única aprovação no fim de um projeto — de modo que o trabalho de perigos da DCB0129/DCB0160 e os DPIAs precisam viver dentro do ritmo da equipe, e não ser acrescentados num portão de lançamento. A tensão é real: incorporar um responsável pela segurança clínica e um líder de governança da informação em cada equipe de produto é caro, e essas habilidades são escassas; assim, as organizações são tentadas a compartilhá-las de forma rala ou a tratar a garantia como uma aprovação que a equipe busca tarde. Essa tentação é exatamente o que recria a falha de construir e abandonar para a segurança, porque uma equipe que otimiza uma métrica de resultado sob pressão de entrega descobrirá o dano, sem uma voz interna de segurança, só depois que ele atingir os pacientes. Considerem como o caso de segurança é mantido vivo ao longo de muitas pequenas versões, quem é dono do registro de perigos e se os colegas de governança têm influência real sobre a descoberta e a priorização ou apenas um veto no final. Uma boa resposta é franca sobre onde a segurança hoje é um portão e não um insumo de projeto e se compromete com a equipe e o ritmo que tornam a garantia contínua viável.

6. Como manteremos uma equipe duradoura genuinamente próxima dos usuários desassistidos, para que a melhoria contínua estreite, e não amplie, a exclusão digital? O trabalho conduzido por produto promete a equidade como resultado de primeira ordem, mas uma equipe estável que instrumenta o próprio produto naturalmente ouvirá mais alto os usuários que já se engajam — os digitalmente confiantes, os conectados, os que aparecem na telemetria —, de modo que a proximidade com os usuários pode se tornar, em silêncio, proximidade com os usuários fáceis. A tensão é que as coortes de maior risco de exclusão (pacientes mais velhos, pessoas em localidades carentes, aquelas com baixo acesso digital ou barreiras de idioma) são as mais difíceis e caras de alcançar pela descoberta contínua, e no entanto são precisamente as pessoas a quem um serviço público de saúde existe para servir. Levem à mesa a prática concreta: que coortes são deliberadamente recrutadas para a pesquisa, como a adesão é acompanhada por localidade e por indicador de acesso digital e que alternativa não digital existe quando a via digital deixa alguém para trás. Considerem se a métrica de equidade da equipe de fato muda decisões ou apenas é reportada. Uma resposta honesta admite onde o atual grupo de pesquisa pende para os de fácil alcance, nomeia os grupos desassistidos que ainda não está ouvindo e descreve o investimento específico — alcance ativo, digital assistido, retaguarda por telefone — que impede a melhoria de acumular vantagem.

Na prática: um exemplo de saúde e cuidados#

Um sistema de cuidados integrados (ICS) opera um aplicativo de gestão de consultas voltado ao paciente, usado em vários hospitais. Historicamente, cada melhoria era um projeto separado: um fornecedor era contratado para "acrescentar lembretes por SMS", entregava e ia embora. Seis meses depois, os lembretes estavam falhando, ninguém era dono da correção e era preciso um pedido de capital para reabrir o contrato.

O ICS muda para um modelo conduzido por produto. Monta uma equipe de produto duradoura — um gerente de produto, um designer, quatro engenheiros, um responsável pela segurança clínica e um líder de governança da informação —, financiada de forma corrente e com o mandato de um resultado, e não de uma lista de funcionalidades: reduzir a taxa de não comparecimento (DNA) e melhorar a equidade de acesso em toda a população.

A equipe conduz uma descoberta contínua com pacientes e agendadores ambulatoriais. Descobre que os lembretes ajudam, mas o maior fator de não comparecimento numa localidade carente é que os pacientes não conseguem reagendar com facilidade e, simplesmente, perdem o horário. Como a equipe é dona do resultado, e não de uma especificação, ela desloca o investimento de uma chamativa funcionalidade de notificações para um fluxo simples de reagendamento autônomo e instrumenta a adesão por localidade e por indicador de acesso digital.

Ao longo de três ciclos de planejamento, a taxa de DNA cai e — de forma decisiva — a equipe monitora a métrica de equidade e percebe que a adesão fica para trás entre os pacientes mais velhos, o que motiva uma via de retaguarda por telefone para que a via digital não amplie a desigualdade. O financiamento continua porque os resultados são demonstráveis. Nenhuma funcionalidade jamais foi "aprovada e abandonada"; o serviço simplesmente continua melhorando. Quando uma plataforma nacional depois oferece a mesma capacidade, a mesma equipe conduz a migração e descontinua o próprio componente — uma decisão de vida inteira que uma equipe de projeto jamais estaria em posição de tomar.

Perspectivas setoriais#

Startup#

Numa pequena empresa de saúde digital, o trabalho conduzido por produto é o modo padrão — muitas vezes o único: uma única equipe empoderada, às vezes a empresa inteira, é dona do produto de ponta a ponta. O financiamento é a restrição vinculante, porque a pista de investidores ou o dinheiro de subvenções significa que a equipe precisa mostrar tração de resultados (adesão, retenção, um sinal clínico inicial) rápido o bastante para justificar a próxima rodada; assim, a descoberta contínua e a instrumentação são ferramentas de sobrevivência, e não luxos. O apetite de risco é alto e a responsabilização corre perante fundadores e investidores, e não perante um conselho ou o público, de modo que a equipe pode pivotar em dias. A armadilha é tratar a segurança clínica e a governança da informação (DCB0129, DPIA) como custo corporativo a adiar — na saúde, essa disciplina é inegociável mesmo na fase semente, e os compradores do NHS exigirão evidências do DTAC antes de deixá-los chegar perto dos dados de pacientes.

Pequena empresa#

Para um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou agência de cuidados domiciliares, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase de startup —, o trabalho conduzido por produto raramente significa montar uma equipe multifuncional dedicada, porque não há gerente de produto, designer ou engenheiro sobrando para financiar. Aqui a "equipe duradoura" costuma ser o gerente do consultório ou o gerente registrado mais um fornecedor de confiança; assim, a disciplina que importa é responsabilizar quem configura e mantém o sistema por resultados — menos consultas perdidas, reconciliação de medicamentos mais segura, melhor acesso para os residentes mais frágeis — e não por uma instalação pontual. O caixa é apertado e contínuo, e não limitado por uma pista, de modo que o movimento sensato é comprar produtos que outros mantêm vivos (o roteiro de um fornecedor bem gerido, um prontuário de cuidados compartilhado, uma plataforma do ICS) em vez de encomendar construções sob medida que ninguém manterá. A segurança clínica e a governança da informação pesam por inteiro — os mesmos deveres de implantação da DCB0160 e as mesmas obrigações de DPIA de um grande hospital —, mas sem nenhuma capacidade interna, o que faz de escolher fornecedores que sejam donos de seu caso de segurança uma genuína decisão de produto. O ângulo da equidade está próximo: um pequeno prestador costuma atender exatamente os pacientes mais velhos ou mais carentes, mais expostos à exclusão digital; manter uma alternativa não digital não é, portanto, opcional.

Grande organização#

Num grande hospital do NHS, num sistema de cuidados integrados (ICS) ou numa empresa de tecnologia em saúde, o modelo de equipe duradoura colide com o orçamento anual de capital e com uma máquina financeira moldada em projetos. O trabalho central é converter serviços permanentes — a equipe de otimização do EPR, a equipe do prontuário de cuidados compartilhado — de projetos de arranca-e-para em equipes de produto financiadas, com orçamentos correntes ligados a fluxos de valor, o que é uma mudança financeira e de governança tanto quanto de organograma. A responsabilização se distribui por governança clínica, governança da informação, garantia do conselho e contratos com fornecedores; assim, o empoderamento precisa vir pareado com uma estratégia de produto explícita e com alinhamento de portfólio (ver Tópico 5.3 — Gestão de portfólio corporativo de projetos (EPPM)) para impedir que dezenas de equipes autônomas otimizem localmente. A escala é inimiga da proximidade com os usuários, de modo que o investimento deliberado em pesquisa incorporada é o que mantém honestas as equipes de uma grande organização.

Governo#

Em escala nacional — NHS England, DHSC, UKHSA —, o trabalho conduzido por produto financia plataformas de longa duração (o NHS App, o NHS login, as APIs nacionais de interoperabilidade) como produtos e não como programas, submetidos ao GDS and NHS Service Standard e às suas avaliações de serviço. O financiamento flui por acordos de revisão de gastos (Spending Review) e casos de negócio; a parte difícil é, portanto, sustentar equipes estáveis ao longo de anos fiscais e ciclos políticos quando a máquina ao redor é construída para projetos com prazo definido. A responsabilização é perante ministros, o Parlamento e o público, por meio do National Audit Office, e o dever de equidade é estatutário; as métricas de resultado devem, portanto, ser pareadas com medidas publicadas de equidade em nível populacional. O prêmio é o alcance: uma única melhoria de produto pode tocar dezenas de milhões de usuários de uma vez, o que eleva tanto o benefício quanto o custo de errar.

Modos de falha comuns#

• Conduzido por produto só no nome ("fábrica de funcionalidades"). A organização rebatiza as equipes de projeto como "equipes de produto", mas continua entregando um roteiro fixo e medindo-as pela entrega. Correção: mudem o mandato e as métricas, e não apenas os cargos.
• Resultados sem salvaguarda de segurança ou de equidade. Otimizar uma única métrica de eficiência pode esconder dano ou ampliar a exclusão. Correção: toda métrica de resultado é pareada com uma medida de segurança e uma de equidade.
• "Empoderamento" sem estratégia. Equipes deixadas a inventar a própria direção derivam e se duplicam. Correção: forte visão e estratégia de produto e alinhamento em nível de portfólio (Tópico 5.3).
• Aplicar o conduzido por produto a trabalho genuinamente finito. Uma migração pontual de data center ou uma implantação de hardware não precisa de uma equipe perpétua. Correção: usem o trabalho conduzido por projeto (Tópico 5.1) onde o escopo é realmente fixo.
• Financiamento que reverte a pedidos anuais de projeto. Uma equipe duradoura com orçamento de arranca-e-para não consegue planejar nem reter pessoas. Correção: financiamento corrente, revisado por resultados, para o fluxo de valor.
• Gerente de produto como escritor de tíquetes. Reduzir o papel à administração do backlog o desperdiça. Correção: responsabilizem o gerente de produto por valor, viabilidade e resultados.

Modelo de maturidade#

Lista de verificação#

• Este é genuinamente um serviço contínuo (e não trabalho finito) que se adequa a uma equipe duradoura?
• Uma equipe estável e multifuncional é dona do produto durante todo o seu ciclo de vida?
• A equipe tem o mandato de problemas e resultados, e não de uma lista fixa de funcionalidades?
• As métricas de resultado estão acordadas — cada uma pareada com uma medida de segurança e uma de equidade?
• A segurança clínica (DCB0129/DCB0160) e a governança da informação estão dentro da equipe?
• A equipe é financiada de forma corrente e reautorizada com base em resultados demonstrados?
• A pesquisa contínua com usuários e a descoberta são uma prática permanente?
• O produto é instrumentado, com a adesão acompanhada por coorte para detectar exclusão?
• Há uma estratégia de produto clara que alinha a autonomia às metas organizacionais?
• A descontinuação/migração elegante é planejada como etapa explícita do ciclo de vida?

Fontes-chave#

• Silicon Valley Product Group (SVPG), Marty Cagan — The Product Operating Model: An Introduction e Empowered Product Teams (svpg.com); livros Inspired, Empowered e 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 e o NHS Digital Service Standard.
• GOV.UK — Government Digital Service (GDS) Service Manual e Service Standard.
• NHS Digital — padrões de segurança clínica DCB0129 (fabricação) e DCB0160 (implantação) de sistemas de TI em saúde.
• John Doerr — Measure What Matters (OKRs), para a definição de metas baseada em resultados.

Referências#

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/