flowchart TD
IDEIA([Ideia selecionada<br/>Módulo 12<br/>intencional · difusa]) --> P1
subgraph CINCO["AS CINCO PERGUNTAS DA DEFINIÇÃO"]
direction TB
P1["1. Quem exatamente é o usuário?<br/>contexto · letramento · fase do tratamento"]
P2["2. O que o produto faz?<br/>funcionalidade principal · fluxo de uso"]
P3["3. O que o produto NÃO faz?<br/>pelo menos 3 exclusões explícitas"]
P4["4. Sob quais condições funciona?<br/>pré-requisitos técnicos e contextuais"]
P5["5. Sob quais condições falha?<br/>limites operacionais e de aplicabilidade"]
P1 --> P2 --> P3 --> P4 --> P5
end
P5 --> SOL([Solução definida<br/>testável · prototipável<br/>comunicável])
SOL --> VPC([Value Proposition Canvas<br/>Módulo 13])
SOL --> PROT([Módulo 14<br/>Protótipo])
style IDEIA fill:#74add1,color:#fff,stroke:#4a8ab0
style CINCO fill:#f5f0e8,color:#333,stroke:#c8a96e
style P1 fill:#4dac26,color:#fff,stroke:#2d7a14
style P2 fill:#4dac26,color:#fff,stroke:#2d7a14
style P3 fill:#f07d02,color:#fff,stroke:#b85c00
style P4 fill:#7b3294,color:#fff,stroke:#561f6a
style P5 fill:#d7191c,color:#fff,stroke:#a01010
style SOL fill:#1a1a2e,color:#fff,stroke:#0d0d1a
style VPC fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style PROT fill:#2c7bb6,color:#fff,stroke:#1a5a8a
Startup: Solução e Proposta de Valor
Ao final deste módulo, você será capaz de:
distinguir com precisão o que separa uma ideia de uma solução, respondendo às cinco perguntas que transformam uma intenção difusa em uma definição testável; preencher o Value Proposition Canvas completo a partir dos dados de empatia que seu grupo coletou nos Módulos 9 e 10, rastreando cada elemento do Perfil do Cliente até uma observação ou citação real das entrevistas; identificar e corrigir o erro mais comum e mais caro no desenvolvimento de produtos — a inversão entre Mapa de Valor e Perfil do Cliente; traduzir características técnicas de um produto em benefícios reais para o usuário por meio da cadeia de perguntas “e daí?”; redigir um parágrafo de proposta de valor focado em benefícios, que qualquer pessoa possa ler e entender sem precisar de conhecimento técnico; e produzir a descrição de solução precisa que seu grupo precisará como ponto de partida para o Módulo 14, de Prototipação.
Da ideia à solução — uma travessia que exige precisão
Você chegou a este módulo com algo que poucos grupos em projetos de inovação realmente possuem: uma ideia selecionada com critérios explícitos. No Módulo 12, seu grupo não apenas gerou ideias — gerou muitas delas, examinou o conjunto com diversidade cognitiva, usou uma matriz para comparar as candidatas em dois eixos independentes e, no final, escolheu uma ideia específica com uma justificativa documentada. Isso é muito mais do que a maioria das equipes de produto faz antes de começar a construir.
Mas existe uma diferença fundamental entre o que seu grupo tem agora e o que precisa ter ao final deste módulo. A ideia que você trouxe do Módulo 12 é, por melhor que esteja formulada, ainda uma intenção. “Uma forma de ajudar pacientes hipertensos a não perderem as consultas de retorno” descreve um problema que você quer atacar e uma direção geral de solução. Não descreve a solução. Quando digo que ainda é uma intenção, não estou diminuindo o trabalho que você fez — estou sendo preciso sobre o estágio em que o projeto se encontra. Uma intenção, por si só, não pode ser prototipada, não pode ser testada com usuários reais e não pode ser apresentada a um investidor ou parceiro clínico de forma convincente. Para que qualquer uma dessas coisas seja possível, a intenção precisa se tornar uma definição.
O que separa uma intenção de uma definição? Cinco perguntas que a intenção deixa sem resposta. Quando você diz “uma forma de ajudar pacientes hipertensos a não perderem as consultas de retorno”, você não sabe quais pacientes exatamente — hipertensos em que contexto? No SUS, no sistema suplementar, na medicina privada? Com qual nível de letramento digital? Em qual fase do tratamento? E o que exatamente o produto faz? Quando diz “ajudar a não perderem as consultas”, isso pode significar lembretes automatizados, reagendamento simplificado, comunicação direta com a unidade de saúde, um sistema de acompanhamento da jornada do paciente, ou vinte outras coisas diferentes do ponto de vista técnico. Cada uma dessas possibilidades é uma solução distinta, com arquitetura diferente, com custos diferentes, com desafios de implementação distintos e, mais importante, com impacto diferente sobre o problema real do usuário.
A imprecisão sobre o que o produto faz tem um custo direto: equipes que não definem sua solução com clareza tendem a acrescentar funcionalidades continuamente, porque cada nova ideia parece razoável quando não há uma fronteira explícita que permita dizer “isso está fora do escopo”. Esse fenômeno tem um nome nos ambientes de desenvolvimento de produto: expansão do escopo, ou scope creep em inglês. A solução para a expansão do escopo não é força de vontade — é uma definição clara o suficiente para que qualquer membro do grupo consiga dizer “isso está dentro” ou “isso está fora” sem precisar perguntar a mais ninguém.
Há ainda outra pergunta que a ideia deixa aberta, e que é igualmente importante: o que o produto não faz? Os limites de uma solução são tão definidores quanto o seu escopo. Um produto que tenta resolver todos os problemas do paciente hipertenso — adesão ao medicamento, comparecimento às consultas, monitoramento da pressão, comunicação com o médico, suporte emocional, orientação dietética e exercício físico — não é um produto abrangente. É um produto que não foi definido. Sem limites explícitos, o grupo não tem como priorizar o que construir primeiro, não tem como avaliar se o que construiu funciona e não tem como comunicar o valor do produto para um usuário que precisa entender para que serve antes de decidir se vai usá-lo.
As cinco perguntas que transformam uma ideia em solução
A medicina treina seus estudantes para serem específicos porque a vagueza no raciocínio clínico é perigosa. Um diagnóstico sem a identificação precisa do paciente — incluindo idade, comorbidades, medicações em uso, contexto social, histórico familiar — é um template, não uma conduta. Um plano terapêutico sem contraindicações explicitadas, sem parâmetros de acompanhamento e sem definição de critérios de sucesso não é um plano — é uma intenção. O mesmo princípio que torna o raciocínio clínico rigoroso é o que torna a definição de produto confiável: especificidade explícita, inclusive sobre o que não se aplica.
As cinco perguntas que seu grupo precisa responder para transformar a ideia selecionada no Módulo 12 em uma solução definida são as seguintes. Cada uma delas será explorada em detalhes logo adiante, mas vale apresentá-las juntas primeiro para que você compreenda como se relacionam.
A primeira pergunta é: quem exatamente é o usuário? Não “pacientes hipertensos” — mas quais pacientes hipertensos, em qual contexto de atenção à saúde, com qual nível de letramento digital, em qual fase do tratamento, com quais condicionantes sociais e econômicos que afetam sua relação com o sistema de saúde.
A segunda pergunta é: o que exatamente o produto faz? Qual é a funcionalidade principal que endereça a necessidade identificada? Qual é o fluxo de uso primário — o que o usuário faz, passo a passo, da primeira interação com o produto até o resultado que resolve o problema?
A terceira pergunta é: o que o produto não faz? Pelo menos três exclusões explícitas que delimitam o escopo e impedem a expansão progressiva para funcionalidades não planejadas.
A quarta pergunta é: sob quais condições o produto funciona? Quais são os pré-requisitos técnicos, contextuais e comportamentais para que o produto funcione como previsto? O que o usuário precisa ter, saber ou fazer para que o produto seja útil?
A quinta pergunta é: sob quais condições o produto não funciona? Em quais situações específicas o produto falhará, entregará resultados piores do que a alternativa atual ou simplesmente não se aplicará?
O diagrama a seguir ilustra o processo de transformação da ideia em solução definida, mostrando como as cinco perguntas estruturam esse trabalho e o que cada uma contribui para a definição final.
Onde você está no processo do Design Thinking: você completou as fases de Empatia (Módulos 9 e 10), Definição (Módulo 10) e Ideação (Módulo 12). Este módulo inicia a fase de Solução — o momento em que uma ideia selecionada com critérios se transforma em uma definição que pode ser prototipada e testada.
O Value Proposition Canvas
O Value Proposition Canvas é uma ferramenta de diagnóstico desenvolvida por Alexander Osterwalder e Yves Pigneur, publicada no livro “Value Proposition Design” em 2014. Osterwalder já era conhecido no mundo das startups e da gestão pelo Business Model Canvas, publicado em 2010, que organiza em nove blocos todos os componentes de um modelo de negócio. O Value Proposition Canvas é, em certo sentido, um zoom sobre dois dos nove blocos do Business Model Canvas: o bloco de Proposta de Valor e o bloco de Segmento de Clientes. Enquanto o Business Model Canvas mapeia como o negócio funciona como um todo, o Value Proposition Canvas se concentra exclusivamente na pergunta mais fundamental de qualquer produto: existe um encaixe real entre o que o produto oferece e o que o cliente genuinamente precisa?
A ferramenta é composta de dois lados que funcionam como complementos: o Perfil do Cliente (representado visualmente como um círculo do lado direito do canvas) e o Mapa de Valor (representado como um quadrado do lado esquerdo). O Perfil do Cliente descreve o cliente — suas tarefas, suas dificuldades e o que quer ganhar. O Mapa de Valor descreve o produto — o que ele oferece, como alivia dificuldades e como cria ganhos. O objetivo da ferramenta é verificar se o que está no Mapa de Valor realmente corresponde ao que está no Perfil do Cliente. Quando essa correspondência existe, os criadores da ferramenta chamam de encaixe (em inglês, fit). Quando não existe, o produto está resolvendo problemas que o cliente não tem, ou ignorando problemas que o cliente realmente sofre.
O motivo pelo qual essa ferramenta é tão relevante para o estágio em que seu projeto se encontra agora é precisamente esse: ela é um diagnóstico de encaixe. Até o Módulo 12, seu grupo trabalhou nos dois lados separadamente — na empatia, investigou o cliente; na ideação, explorou soluções possíveis. O Value Proposition Canvas é o primeiro momento em que os dois lados são colocados lado a lado para verificar se existe, de fato, uma correspondência entre eles.
O Perfil do Cliente — três dimensões
O Perfil do Cliente é composto de três dimensões. É importante entender que essas três dimensões não são itens que você inventa — elas são extraídas diretamente dos dados de empatia que seu grupo coletou nos Módulos 9 e 10. Se o Perfil do Cliente for preenchido com suposições em vez de observações reais, ele deixa de ser um diagnóstico e se torna um espelho das crenças do grupo, que é exatamente o que você quer evitar.
A primeira dimensão são as Tarefas do Cliente (em inglês, Customer Jobs). Essa dimensão descreve o que o cliente está tentando realizar na vida — não apenas em relação ao problema que seu produto pretende resolver, mas no contexto mais amplo em que esse problema existe. As tarefas do cliente se dividem em três tipos que coexistem na vida de qualquer usuário real.
As tarefas funcionais são o que o cliente está fisicamente tentando fazer: gerenciar o diabetes, agendar uma consulta de retorno, entender o resultado de um exame, tomar o medicamento no horário correto. São tarefas objetivas, mensuráveis, que a pessoa realiza ou não realiza.
As tarefas sociais descrevem como o cliente quer ser percebido pelos outros durante ou após a realização dessas tarefas funcionais: ser visto como um paciente responsável pela equipe de saúde, ser reconhecido como alguém que cuida da própria saúde pela família, não ser estigmatizado pelo sistema de saúde por não conseguir seguir as orientações médicas à risca.
As tarefas emocionais descrevem como o cliente quer se sentir: sentir-se no controle da própria condição de saúde, sentir-se respeitado e não julgado durante as consultas, não viver com medo constante de um evento cardiovascular, sentir que o esforço de manter o tratamento faz diferença e que alguém percebe esse esforço.
Tome como exemplo um paciente hipertenso acompanhado em uma Unidade Básica de Saúde do SUS. Suas tarefas funcionais incluem tomar os medicamentos regularmente, comparecer às consultas de retorno, medir a pressão arterial periodicamente e entender o que os valores encontrados significam. Suas tarefas sociais incluem ser percebido como um paciente cooperativo pela equipe da UBS e não ser visto pelos familiares como alguém que ignora a própria saúde. Suas tarefas emocionais incluem não sentir que é um fardo para a família e sentir que tem alguma agência no gerenciamento de uma condição crônica que vai continuar presente pelo resto da vida.
É fundamental entender que as tarefas do cliente não são as funcionalidades do produto — elas são a agenda própria do usuário, que existe independentemente do produto. O produto pode ajudar o cliente a realizar algumas dessas tarefas, mas ele não as cria. Elas já existem. Se o produto não ajuda o cliente em nenhuma tarefa real, ele não tem utilidade — independentemente de quão sofisticado seja do ponto de vista técnico.
A segunda dimensão são as Dores (em inglês, Pains). As dores são tudo aquilo que impede, bloqueia, frustra ou preocupa o cliente enquanto tenta realizar suas tarefas. As dores se dividem em quatro tipos que é útil distinguir.
Os resultados indesejados e problemas descrevem o que dá errado: o paciente toma o medicamento errado por confusão entre embalagens similares, ou vai à consulta e a médica que o acompanha foi substituída sem aviso.
Os obstáculos descrevem o que está no caminho: a fila de espera de três semanas para conseguir nova consulta quando a anterior precisou ser cancelada, a impossibilidade de ligar para a UBS durante o horário de trabalho porque o telefone só funciona dentro do horário comercial.
Os riscos descrevem o que o cliente teme que possa acontecer: perder a vaga de acompanhamento na UBS por ter faltado a uma consulta, sofrer um acidente vascular cerebral porque não conseguiu controlar a pressão de forma consistente durante um período de estresse.
Os problemas funcionais descrevem o que não funciona na solução atual: o médico prescreve uma mudança no medicamento mas não explica por quê, deixando o paciente sem entender o racional da conduta e menos propenso a aderir.
Existe uma distinção importante que você precisa guardar: dores são diferentes da ausência de ganhos. “Eu gostaria que isso funcionasse melhor” não é uma dor. “Isso falha de uma forma que me causa um prejuízo específico e concreto” é uma dor. A clareza sobre essa distinção é o que permite que o Mapa de Valor endereça dores reais em vez de melhorias genéricas.
A terceira dimensão são os Ganhos (em inglês, Gains). Os ganhos são os resultados e benefícios que o cliente deseja — não apenas a ausência das dores, mas os estados positivos que o cliente quer atingir. Os ganhos também se dividem em quatro tipos com intensidades crescentes de desejo.
Os ganhos necessários são o mínimo esperado — o que o cliente simplesmente precisa para que o produto funcione: “preciso que o lembrete chegue antes da consulta, não no dia anterior à noite”. Os ganhos esperados são o que o cliente assume que o produto terá, mesmo sem pedir explicitamente: “espero poder confirmar a consulta pela mesma plataforma que me enviou o lembrete”. Os ganhos desejados são o que o cliente adoraria ter, mas não esperaria necessariamente encontrar: “seria incrível se o médico já soubesse como foi minha pressão no último mês antes de eu chegar à consulta”. Os ganhos inesperados são o que o cliente nem saberia pedir, mas adoraria se encontrasse: “e se eu pudesse ver meu histórico de pressão num gráfico e entender os padrões ao longo do tempo?”
Os ganhos inesperados são a categoria mais difícil de identificar a partir das entrevistas de empatia — precisamente porque o usuário não os verbalizaria espontaneamente. Eles emergem da observação profunda do contexto de vida do usuário, de perguntas abertas sobre o que tornaria a experiência significativamente melhor, e às vezes de analogias com outros domínios da vida do usuário onde soluções similares funcionam bem.
Conexão com os Módulos 9 e 10: as dimensões do Perfil do Cliente não são criadas do zero neste módulo — elas são derivadas dos dados que seu grupo já coletou. As dores no canvas vêm da seção “Dores” do Mapa de Empatia e dos pontos de atrito da Jornada do Usuário. Os ganhos vêm da seção “Ganhos” do Mapa de Empatia. As tarefas do cliente emergem das seções “Faz e Diz” do Mapa de Empatia e das etapas da Jornada do Usuário. As ferramentas foram projetadas para se encaixar — o que você produziu antes alimenta o que você está construindo agora.
A tabela a seguir organiza as três dimensões do Perfil do Cliente com suas subdivisões, exemplos contextualizados para a saúde e a fonte de dado correspondente nos Módulos 9 e 10. Use-a como referência ao preencher o canvas do seu grupo.
| Dimensão | Tipo | Definição | Exemplo em HealthTech | Fonte nos dados de empatia |
|---|---|---|---|---|
| Tarefas do Cliente | Funcional | O que o cliente fisicamente tenta realizar | Tomar os medicamentos no horário correto todos os dias | Jornada do Usuário — etapas funcionais |
| Tarefas do Cliente | Social | Como o cliente quer ser percebido pelos outros | Ser visto como paciente responsável pela equipe da UBS | Mapa de Empatia — “Diz” |
| Tarefas do Cliente | Emocional | Como o cliente quer se sentir | Sentir-se no controle da própria condição crônica | Mapa de Empatia — “Pensa e Sente” |
| Dores | Resultado indesejado | O que dá errado | Confundir medicamentos de embalagens similares | Mapa de Empatia — “Dores”; entrevistas |
| Dores | Obstáculo | O que está no caminho | Impossibilidade de ligar para a UBS durante o trabalho | Jornada do Usuário — pontos de atrito |
| Dores | Risco | O que o cliente teme | Perder a vaga de acompanhamento por falta | Mapa de Empatia — “Pensa e Sente” |
| Dores | Problema funcional | O que não funciona na solução atual | Médico não explica por que mudou o medicamento | Entrevistas — observações diretas |
| Ganhos | Necessário | Mínimo esperado | Lembrete chegando com antecedência suficiente | Mapa de Empatia — “Ganhos” |
| Ganhos | Esperado | O que o cliente assume que o produto terá | Poder confirmar ou reagendar pela mesma plataforma | Entrevistas — expectativas expressas |
| Ganhos | Desejado | O que adoraria ter se pedido | Médico conhecer o histórico antes da consulta | Entrevistas — aspirações |
| Ganhos | Inesperado | O que não saberia pedir mas adoraria | Gráfico pessoal de pressão com interpretação clara | Observação etnográfica |
O Mapa de Valor — três dimensões
O Mapa de Valor é o lado do canvas que descreve o produto. Assim como o Perfil do Cliente tem três dimensões, o Mapa de Valor também tem três dimensões, e cada uma delas corresponde diretamente a uma dimensão do Perfil do Cliente. Esse paralelismo é intencional: a ferramenta é projetada para tornar visível se existe — ou não — uma correspondência real entre o que o produto oferece e o que o cliente precisa.
A primeira dimensão são os Produtos e Serviços (em inglês, Products & Services). Essa dimensão lista tudo que o produto ou serviço é — suas funcionalidades, componentes e características. É uma descrição do produto em si, não do valor que ele gera. Um aplicativo de gestão de consultas para pacientes hipertensos na atenção primária é um produto. Uma interface web que permite ao médico visualizar o histórico de adesão do paciente antes da consulta é um produto. O sistema de notificações que envia o lembrete com 48 horas de antecedência é um componente do produto. Todos esses elementos pertencem à dimensão de Produtos e Serviços.
Entender que Produtos e Serviços descrevem o produto, não o valor que ele cria, é importante porque ajuda a separar o que existe (a funcionalidade) do que importa (o resultado para o usuário). Essa separação é a base da distinção entre característica e benefício, que exploraremos em detalhes na próxima seção.
A segunda dimensão são os Aliviadores de Dor (em inglês, Pain Relievers). Essa dimensão descreve como o produto reduz ou elimina dores específicas do Perfil do Cliente. O princípio aqui é de correspondência um a um: cada aliviador de dor deve endereçar uma dor específica identificada no Perfil do Cliente. Se o seu grupo conseguir descrever um aliviador de dor mas não conseguir apontar qual dor do Perfil do Cliente ele alivia, isso significa uma de duas coisas: ou a dor existe mas não foi identificada na pesquisa de empatia, ou o aliviador de dor foi inventado sem fundamentação nos dados — o que é o sinal mais claro de que o produto foi projetado para usuários imaginários em vez de usuários reais.
Para o exemplo do paciente hipertenso no SUS: se uma das dores identificadas é “perder a vaga de acompanhamento quando o paciente não consegue comparecer”, um aliviador de dor bem formulado seria “permite que o paciente reagende a consulta diretamente da notificação, em até 24 horas antes do horário marcado, sem precisar ligar para a UBS”. Observe que esse aliviador não é uma descrição de funcionalidade — é uma descrição de como a funcionalidade resolve uma dor específica.
A terceira dimensão são os Criadores de Ganho (em inglês, Gain Creators). Essa dimensão descreve como o produto cria ou amplifica ganhos específicos do Perfil do Cliente. A mesma lógica de correspondência se aplica: cada criador de ganho deve mapear para um ganho específico identificado no Perfil do Cliente. Criadores de ganho sem correspondência no Perfil do Cliente são funcionalidades que o cliente não valoriza — ou, pior, que complicam a experiência sem nenhum retorno real.
Para o mesmo exemplo: se um dos ganhos desejados identificados nas entrevistas é “o médico saber como foi minha pressão no mês anterior sem depender do que eu conseguir lembrar”, um criador de ganho bem formulado seria “gera um resumo semanal de adesão — medicamentos tomados, medições de pressão registradas — que é enviado automaticamente ao médico antes de cada consulta agendada”. Esse criador de ganho endereça um ganho que os dados de empatia revelaram como real e relevante. Ele não foi inventado porque parecia tecnicamente interessante.
O encaixe — o que significa “product-market fit” neste estágio
O conceito de product-market fit — encaixe entre produto e mercado — é um dos termos mais usados e mais mal compreendidos no ecossistema de startups. No contexto do Value Proposition Canvas, o encaixe tem uma definição precisa: cada aliviador de dor alivia uma dor real do Perfil do Cliente, e cada criador de ganho cria um ganho real do Perfil do Cliente, e os produtos e serviços listados são suficientes para possibilitar esses aliviadores e criadores.
Osterwalder e Pigneur distinguem três tipos de encaixe que ocorrem em momentos diferentes da vida de um produto, e é importante que você saiba em qual deles seu projeto se encontra agora.
O encaixe entre problema e solução (problem-solution fit) ocorre quando os aliviadores de dor e criadores de ganho propostos endereçam as tarefas, dores e ganhos mais significativos do Perfil do Cliente — não todos, mas os que mais importam. Esse tipo de encaixe pode ser verificado no papel, com os dados de empatia disponíveis, antes de construir qualquer coisa. É exatamente o que você está fazendo neste módulo.
O encaixe entre produto e mercado (product-market fit) ocorre quando usuários reais, ao usar o produto, validam que os aliviadores de dor e criadores de ganho funcionam como previsto. Esse tipo de encaixe só pode ser verificado com testes reais — é o que acontecerá nos Módulos 14 e 15, quando você prototipar e validar a solução com usuários reais.
O encaixe com o modelo de negócio (business model fit) ocorre quando o produto pode ser entregue de forma sustentável economicamente, sendo acessível aos clientes e rentável para o negócio. Esse tipo de encaixe será abordado no Módulo 15.
No Módulo 13, o objetivo é o encaixe entre problema e solução: verificar, com os dados disponíveis, se o que o produto propõe realmente endereça o que o Perfil do Cliente revela. A pergunta central é: as três dores mais significativas identificadas nas entrevistas têm aliviadores de dor correspondentes? O ganho mais importante identificado nas entrevistas tem um criador de ganho correspondente?
flowchart LR
subgraph PC["PERFIL DO CLIENTE<br/>(direita — descreve o cliente)"]
direction TB
TC["Tarefas do Cliente<br/>funcional · social · emocional"]
DO["Dores<br/>resultados · obstáculos · riscos · problemas"]
GA["Ganhos<br/>necessários · esperados · desejados · inesperados"]
end
subgraph MV["MAPA DE VALOR<br/>(esquerda — descreve o produto)"]
direction TB
PS["Produtos e Serviços<br/>o que o produto é"]
AD["Aliviadores de Dor<br/>como o produto alivia dores específicas"]
CG["Criadores de Ganho<br/>como o produto cria ganhos específicos"]
end
DO <-->|"correspondência<br/>um a um"| AD
GA <-->|"correspondência<br/>um a um"| CG
TC <-->|"o produto<br/>viabiliza tarefas"| PS
ENC(["ENCAIXE<br/>Fit<br/>quando cada AD alivia<br/>uma dor real, e cada CG<br/>cria um ganho real"])
MV --- ENC
ENC --- PC
style PC fill:#f5f0e8,color:#333,stroke:#c8a96e
style MV fill:#e8f0f5,color:#333,stroke:#6e9ac8
style TC fill:#4dac26,color:#fff,stroke:#2d7a14
style DO fill:#d7191c,color:#fff,stroke:#a01010
style GA fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style PS fill:#74add1,color:#fff,stroke:#4a8ab0
style AD fill:#f07d02,color:#fff,stroke:#b85c00
style CG fill:#7b3294,color:#fff,stroke:#561f6a
style ENC fill:#1a1a2e,color:#fff,stroke:#0d0d1a
O erro de inversão: o processo correto é preencher o Perfil do Cliente primeiro — a partir dos dados de empatia — e só então preencher o Mapa de Valor para endereçar o que o Perfil revelou. O erro mais comum é fazer exatamente o inverso: a equipe começa pelo Mapa de Valor (“aqui está o que queremos construir”) e então preenche o Perfil do Cliente de forma que justifique o Mapa de Valor que já havia sido decidido. O resultado parece um encaixe mas é apenas um reflexo das crenças da equipe. Você saberá que cometeu esse erro se, ao olhar para o Perfil do Cliente preenchido, não conseguir citar a entrevista ou observação específica que deu origem a cada item.
Característica versus benefício — a distinção que define a proposta de valor
Existe um erro tão comum no desenvolvimento de produtos de saúde — e de produtos em geral — que tem um nome próprio na literatura de marketing e de design de produto. Esse erro é confundir característica com benefício, ou, dito de outra forma, confundir o que o produto é com o que o produto significa para o usuário. Parece uma distinção óbvia quando enunciada assim, mas na prática, e especialmente para equipes formadas por pessoas com formação técnica, essa distinção colapsa com surpreendente frequência e com consequências importantes.
Uma característica (ou funcionalidade) é uma propriedade do produto — algo que o produto tem ou faz, descrito do ponto de vista do produto em si. Um benefício é um resultado para o usuário — algo que muda na vida ou no trabalho do usuário por causa do produto, descrito do ponto de vista do usuário. A diferença não é cosmética. É uma diferença de perspectiva que determina se a comunicação sobre o produto será compreendida e valorizada pelo usuário, ou se será ignorada.
Theodore Levitt, professor de marketing da Harvard Business School, formulou uma das frases mais citadas em toda a história da teoria de produtos: “As pessoas não querem comprar uma broca de um quarto de polegada — elas querem um buraco de um quarto de polegada na parede”. Levitt estava articulando algo que parece elementar mas que as equipes de produto violam constantemente: o cliente não compra o produto, ele compra o resultado que o produto permite. A broca é a característica. O buraco na parede é o benefício. Mas Levitt vai ainda mais longe em sua análise: as pessoas não querem o buraco na parede em si. Elas querem poder pendurar o quadro que vai decorar a sala. O que elas querem, no nível mais profundo, é uma sala que reflita seus gostos e faça os visitantes sentirem que ela é acolhedora. O produto vai ficando cada vez mais distante conforme a análise dos benefícios vai se aprofundando.
Em saúde, essa distinção é ainda mais nítida — e ainda mais frequentemente ignorada — porque as equipes de HealthTech tendem a ter formação técnica (médica ou de tecnologia da informação) e a se comunicar com mais naturalidade na linguagem das características do que na linguagem dos benefícios.
Considere dois exemplos lado a lado:
Característica: “O sistema integra dados de dispositivos vestíveis via o protocolo FHIR R4, calcula médias de pressão arterial em intervalos configuráveis pelo usuário e envia alertas por notificação push quando a média semanal ultrapassa o limiar parametrizado pelo médico.”
Benefício: “O médico chega à consulta de retorno já sabendo como esteve a pressão do paciente nos últimos 30 dias — sem depender do que o paciente conseguir lembrar, que frequentemente não é preciso — e pode decidir se a medicação atual está funcionando com base em dados reais, não em relatos de memória.”
A característica é tecnicamente correta e até impressionante para alguém com formação em tecnologia da informação em saúde. Mas para o médico que a usaria, ou para o paciente que seria beneficiado, a característica não responde à única pergunta que importa para a decisão de adotar o produto: “o que muda na minha prática ou na minha vida se eu usar isso?” O benefício responde essa pergunta diretamente.
Por que equipes recorrem às características
Se a distinção entre característica e benefício é tão importante, por que equipes tão inteligentes e bem-intencionadas continuamente descrevem seus produtos em termos de características? Há três razões que se combinam e que você precisa conhecer para conseguir resistir a elas.
A primeira razão é que as características são mais fáceis de especificar. Uma característica pode ser escrita como um requisito técnico, verificada como um critério de aceitação e medida objetivamente. “O sistema envia notificações 48 horas e 2 horas antes da consulta” é verificável: ou envia, ou não envia. “O paciente não perde a consulta por esquecimento” é o benefício, mas é mais difícil de verificar diretamente — requer acompanhamento do comportamento do usuário ao longo do tempo. A dificuldade de medir o benefício faz com que as equipes gravitam para a especificação de características, que são mais confortáveis do ponto de vista técnico.
A segunda razão é que as equipes são mais confiantes sobre características do que sobre benefícios. A equipe sabe o que o produto faz porque ela o construiu ou o planejou. Mas saber o que o produto faz é diferente de saber o que isso significa para o usuário — para saber o que significa, é preciso conhecer o contexto de vida do usuário com profundidade suficiente para rastrear como a característica se traduz em impacto real. Esse conhecimento vem da pesquisa de empatia, não do planejamento técnico. Equipes que pularam a fase de empatia não têm base para articular benefícios com confiança, então recorrem às características.
A terceira razão é que as características soam mais sérias e técnicas do ponto de vista de quem as criou, enquanto os benefícios podem soar presunçosos — como se a equipe estivesse prometendo demais. “Integramos dados de wearables via FHIR R4” soa profissional e preciso. “O médico não precisará mais depender da memória imprecisa do paciente” soa como uma promessa audaciosa. Mas a promessa audaciosa — se fundamentada em dados de empatia e em uma lógica de produto coerente — é exatamente o que torna a proposta de valor convincente. O conservadorismo na comunicação dos benefícios é, paradoxalmente, o que faz com que muitos produtos tecnicamente excelentes não sejam adotados.
A cadeia “e daí?” — traduzindo características em benefícios
O método prático para traduzir características em benefícios é simples e pode ser aplicado imediatamente: para cada característica do seu produto, pergunte “e daí?” até a resposta se conectar diretamente com uma tarefa, dor ou ganho no Perfil do Cliente. Cada pergunta “e daí?” move a análise um nível mais próximo do impacto real para o usuário. A cadeia termina quando você chegar a algo que o usuário reconheceria imediatamente como relevante para a sua vida.
O diagrama a seguir ilustra essa cadeia para um exemplo de HealthTech, mostrando como cada “e daí?” transforma uma característica técnica no benefício que a sustenta.
flowchart TD
C1["CARACTERÍSTICA<br/>'O sistema envia lembretes<br/>48h e 2h antes da consulta'"]
C1 -->|"e daí?"| C2["O paciente vê o lembrete<br/>em momento com maior chance<br/>de estar disponível para agir"]
C2 -->|"e daí?"| C3["O paciente consegue<br/>rearranjar a agenda<br/>com antecedência suficiente"]
C3 -->|"e daí?"| C4["O paciente não perde<br/>a consulta por esquecimento<br/>ou conflito de agenda"]
C4 -->|"e daí?"| C5["O paciente não perde<br/>a vaga de acompanhamento<br/>que levou semanas para conseguir"]
C5 -->|"e daí?"| BEN["BENEFÍCIO<br/>'Garante que o paciente que esqueceria<br/>a consulta por sobrecarga de trabalho<br/>não perde o acompanhamento contínuo<br/>que é a base do controle da hipertensão'"]
C1 -.->|"conecta com"| DOR["Dor identificada:<br/>'Medo de perder a vaga<br/>na UBS por falta'"]
BEN -.->|"endereça"| DOR
style C1 fill:#74add1,color:#fff,stroke:#4a8ab0
style C2 fill:#abd9e9,color:#333,stroke:#74add1
style C3 fill:#e0f3f8,color:#333,stroke:#abd9e9
style C4 fill:#fee090,color:#333,stroke:#fdae61
style C5 fill:#fdae61,color:#fff,stroke:#f46d43
style BEN fill:#d7191c,color:#fff,stroke:#a01010
style DOR fill:#1a1a2e,color:#fff,stroke:#0d0d1a
Para que a cadeia “e daí?” funcione, é preciso que dois elementos estejam presentes. O primeiro é o conhecimento profundo do contexto do usuário: se você não sabe o que significa, na prática, “perder a vaga de acompanhamento na UBS”, não conseguirá chegar ao benefício real — a cadeia se interrompe antes de chegar a algo que importe. Esse conhecimento vem das entrevistas de empatia do Módulo 9 e do Mapa de Empatia do Módulo 10. É por isso que a qualidade da pesquisa de empatia determina diretamente a qualidade da proposta de valor.
O segundo elemento é honestidade sobre as premissas em cada passo da cadeia. Cada “e daí?” implica uma premissa comportamental ou contextual: “o paciente vê o lembrete em momento com maior chance de estar disponível para agir” é uma premissa — ela assume que o paciente tem o celular consigo e que está num momento em que consegue agir sobre a notificação. Essa premissa pode ser verdadeira para alguns perfis de usuário e falsa para outros. Identificar as premissas explicitamente ajuda o grupo a reconhecer quais delas precisam ser testadas no Módulo 14.
A tabela a seguir apresenta comparações diretas entre formulações de característica e formulações de benefício para o mesmo produto, usando o exemplo do sistema de gestão de consultas para pacientes hipertensos no SUS.
| Formulação como característica | Formulação como benefício |
|---|---|
| “O sistema envia lembretes 48h e 2h antes da consulta” | “O paciente que esqueceria a consulta por sobrecarga de trabalho mantém o acompanhamento contínuo sem precisar reiniciar o processo de agendamento” |
| “A plataforma permite reagendamento sem ligação telefônica” | “O paciente que precisa remarcar a consulta durante o horário de trabalho consegue fazê-lo em menos de dois minutos, sem depender de uma ligação que talvez não consiga fazer durante o expediente” |
| “O sistema gera relatório de adesão com histórico de 30 dias” | “O médico chega à consulta já sabendo se o paciente aderiu ao tratamento no período anterior, podendo usar o tempo da consulta para discutir causas e estratégias em vez de coletar informações que o paciente pode não lembrar com precisão” |
| “A interface calcula e exibe tendência de pressão arterial ao longo do tempo” | “O paciente consegue ver, de forma compreensível, se o esforço que está fazendo para controlar a pressão está produzindo resultado — o que aumenta a motivação para continuar” |
O parágrafo de proposta de valor
A proposta de valor é frequentemente confundida com outras coisas que não é. Ela não é uma descrição do produto. Não é uma missão da empresa. Não é uma lista de funcionalidades. Não é um slogan publicitário. Uma proposta de valor é uma promessa específica sobre o que mudará na vida ou no trabalho do usuário se ele usar o produto — uma promessa fundamentada nos dados de empatia do Perfil do Cliente e nos aliviadores de dor e criadores de ganho do Mapa de Valor.
Um parágrafo de proposta de valor bem escrito responde a uma única pergunta de forma clara e convincente: “por que alguém que tem exatamente o perfil desse usuário deveria usar este produto em vez da alternativa que usa hoje?” A resposta a essa pergunta não está nas características técnicas do produto — está na diferença que o produto faz na vida de alguém específico, com problemas específicos, num contexto específico.
O teste mais simples para saber se um parágrafo de proposta de valor está bem escrito é este: leia-o para alguém que não tem nenhum conhecimento sobre tecnologia da informação e sobre medicina. Se essa pessoa conseguir dizer, com suas próprias palavras, para quem o produto serve e por que faria diferença na vida dessa pessoa, o parágrafo está cumprindo sua função. Se ela precisar perguntar “mas o que o produto tecnicamente faz?” para entender o parágrafo, ele está escrito na linguagem das características, não dos benefícios.
Um exemplo de parágrafo de proposta de valor bem articulado para o sistema hipotético:
“Para pacientes com hipertensão acompanhados em unidades básicas de saúde que frequentemente perdem consultas de retorno por conflitos com horários de trabalho ou por esquecimento puro e simples — perdendo com isso a continuidade de um acompanhamento que leva semanas para ser reconstituído —, o sistema oferece lembretes personalizados com antecedência suficiente para reorganizar a agenda, além da possibilidade de reagendar sem precisar ligar para a unidade. Para o médico, a consulta começa com um histórico automatizado dos 30 dias anteriores, tornando possível discutir estratégias de adesão em vez de dedicar os primeiros minutos a reconstruir o que aconteceu desde a última visita.”
Observe que esse parágrafo não menciona protocolos técnicos, nomes de sistemas ou arquitetura de integração. Ele descreve dois usuários (paciente e médico), os problemas específicos de cada um e como o produto endereça esses problemas de forma concreta. Qualquer pessoa conseguiria entender para que serve esse produto após ler esse parágrafo.
O teste dos três critérios: um bom parágrafo de proposta de valor deve satisfazer os três critérios a seguir. Primeiro, qualquer pessoa que leia deve entender para quem o produto serve sem precisar saber nada sobre a área de saúde ou tecnologia. Segundo, deve ser possível identificar claramente o que muda na vida do usuário — não o que o produto tecnicamente faz, mas o que diferencia o antes e o depois de usar o produto. Terceiro, ao ler, o usuário real deve reconhecer sua própria situação descrita no parágrafo — não uma versão idealizada de si mesmo, mas a situação real com as dificuldades reais que emergiu das entrevistas de empatia.
Como preencher o canvas com dados de empatia — passo a passo
O processo de preenchimento do Value Proposition Canvas não é intuitivo porque contraria a ordem natural de como as equipes pensam sobre seus produtos. Equipes tendem a começar pelo produto — é o que estão empolgadas para construir — e a justificar o produto com base no cliente depois. O canvas força a inversão dessa lógica, e a inversão é o que o torna útil. A seguir, descrevo o processo correto em cinco etapas, com as perguntas que você deve se fazer em cada etapa e os sinais de que a etapa foi concluída adequadamente.
Etapa 1: reunir todos os dados de empatia antes de tocar no canvas. Antes de escrever qualquer coisa no canvas, reúna fisicamente — num espaço compartilhado, num documento aberto no computador, ou num quadro acessível a todos — o conjunto completo dos dados de empatia produzidos nos Módulos 9 e 10. Isso inclui as anotações das entrevistas de empatia, o Mapa de Empatia preenchido, a Jornada do Usuário com os pontos de atrito identificados e o enunciado POV que seu grupo formulou. Sem esses materiais à mão, o preenchimento do Perfil do Cliente terá que recorrer a suposições — e suposições preenchem o espaço exatamente onde observações reais deveriam estar.
Etapa 2: preencher o Perfil do Cliente a partir dos dados, com rastreabilidade. Preencha o Perfil do Cliente item a item, e para cada item anote — ao lado ou em referência — a fonte específica de onde ele veio. “Dor: medo de perder a vaga na UBS por falta — fonte: entrevista com paciente A, 12/03, afirmação direta”. A rastreabilidade serve a dois propósitos: obriga o grupo a distinguir observações de suposições (se você não consegue citar a fonte, é suposição) e facilita a revisão posterior quando o grupo precisar checar se a dor identificada é realmente tão significativa quanto parece.
Ao preencher as dores, diferencie explicitamente as dores de alta intensidade — as que causam obstáculos maiores, perdas reais ou medos genuínos — das dores de baixa intensidade, que são apenas inconveniências. O Mapa de Valor deve endereçar prioritariamente as dores de alta intensidade. Endereçar apenas inconveniências é uma forma de encaixe superficial que não cria valor real.
Etapa 3: somente então preencher o Mapa de Valor. Com o Perfil do Cliente completo e fundamentado, comece o Mapa de Valor. Preencha os Aliviadores de Dor primeiro: para cada dor de alta intensidade no Perfil do Cliente, pergunte “o que o produto faz para aliviar especificamente essa dor?” Se a resposta não existir, significa que o produto não endereça essa dor — o que pode ser uma oportunidade perdida ou uma decisão consciente de escopo. Se a resposta existir, a formule sempre na perspectiva do usuário, não na perspectiva técnica do produto.
Etapa 4: verificar o encaixe. Coloque os dois lados do canvas lado a lado e trace linhas explícitas entre cada Aliviador de Dor e a Dor correspondente, e entre cada Criador de Ganho e o Ganho correspondente. Cada Aliviador de Dor deve ter uma linha. Cada Criador de Ganho deve ter uma linha. Se um Aliviador de Dor não tem linha correspondente no Perfil do Cliente, questione sua existência. Se uma Dor de alta intensidade não tem um Aliviador de Dor correspondente, questione se o produto está endereçando o problema certo.
Etapa 5: identificar as premissas ocultas. Para cada elemento do Mapa de Valor, identifique as premissas que precisam ser verdadeiras para que ele funcione como descrito. “O Aliviador de Dor X funciona como descrito se e somente se o usuário tiver um smartphone com conexão de internet e notifications habilitadas.” Essas premissas serão os pontos de partida para os testes no Módulo 14.
A lista de verificação do encaixe: ao final do preenchimento do canvas, verifique os cinco critérios a seguir antes de considerar o canvas completo. As três dores mais significativas do Perfil do Cliente têm aliviadores de dor correspondentes no Mapa de Valor. O ganho mais importante — o que emergiu com mais frequência e intensidade nas entrevistas — tem um criador de ganho correspondente. Todos os aliviadores de dor e criadores de ganho do Mapa de Valor têm correspondência no Perfil do Cliente — nenhum foi inventado sem base nos dados. Cada item do Perfil do Cliente pode ser rastreado a uma observação ou citação específica das entrevistas ou do Mapa de Empatia. As premissas de funcionamento de cada elemento do Mapa de Valor estão identificadas e documentadas.
Definindo a solução com precisão clínica
Na medicina, uma conduta terapêutica imprecisa é uma conduta perigosa. Prescrever “um anti-hipertensivo” sem especificar a classe, a dose, a frequência, as contraindicações, os critérios de ajuste e os parâmetros de acompanhamento não é uma conduta clínica — é uma intenção expressa em linguagem técnica. A precisão não é um detalhe burocrático do raciocínio clínico; é a condição para que a conduta seja implementável, avaliável e segura.
O mesmo princípio se aplica à definição de um produto de saúde. Uma definição de solução vaga — “um aplicativo para ajudar pacientes hipertensos” — não é uma definição de produto. É uma intenção. Para que a definição seja útil, ela precisa ter precisão suficiente para que qualquer membro do grupo possa dizer “isso está dentro do escopo” ou “isso está fora do escopo” diante de qualquer decisão concreta que surgir durante o desenvolvimento. Uma definição que não permite essa discriminação é uma definição que não cumpre sua função.
A descrição de solução que seu grupo produzirá neste módulo deve ter cinco elementos estruturados. Cada elemento responde a uma das perguntas que a ideia deixava em aberto, conforme discutimos no início do módulo.
O primeiro elemento é o usuário específico. Não a persona genericamente — mas o conjunto de características observadas que definem o usuário real para quem o produto foi projetado. Inclui o contexto de atenção à saúde (UBS, clínica particular, hospital universitário), o nível de letramento digital observado nas entrevistas, a fase do tratamento em que se encontra e os condicionantes sociais relevantes identificados na pesquisa.
O segundo elemento é a funcionalidade principal, descrita como um fluxo de uso. Não “o sistema gerencia consultas”, mas “o sistema recebe os dados de agendamento da UBS, envia uma notificação ao paciente 48 horas antes da consulta com a opção de confirmar ou reagendar, e registra a resposta automaticamente no cadastro da UBS”. O fluxo de uso principal deve ser descrito passo a passo, do ponto de vista do usuário, do primeiro contato com o produto até o resultado que resolve o problema.
O terceiro elemento são as exclusões explícitas — pelo menos três funcionalidades ou casos de uso que o produto deliberadamente não cobre. As exclusões têm a mesma importância estratégica do que o escopo: elas definem o que o grupo não vai construir neste ciclo, liberando energia para fazer bem o que está dentro do escopo. Exemplos de exclusões bem formuladas: “o sistema não monitora pressão arterial diretamente — integrar dados de dispositivos vestíveis está fora do escopo desta versão”; “o sistema não substitui o prontuário eletrônico da UBS e não sincroniza com o e-SUS — ele é um complemento independente”; “o sistema não gerencia triagem ou urgências — é exclusivo para consultas programadas de retorno”.
O quarto elemento são as condições de funcionamento — os pré-requisitos que precisam estar presentes para que o produto funcione como descrito. Condições técnicas: o paciente precisa ter um celular com sistema operacional iOS 14 ou Android 8 ou superior, com conexão à internet pelo menos intermitente. Condições contextuais: a UBS precisa ter um sistema de agendamento que permita exportação de dados via API ou importação manual de planilha. Condições comportamentais: o médico precisa confirmar as consultas no sistema com pelo menos 72 horas de antecedência para que o lembrete seja enviado no prazo correto.
O quinto elemento são as condições de falha — as situações em que o produto não funcionará como previsto e o que o usuário deveria fazer nessas situações. Isso não é pessimismo — é honestidade de engenharia que evita que o produto seja usado em contextos onde inevitavelmente falhará, gerando frustração e abandono. Exemplos: “o sistema não funciona para pacientes sem celular ou sem número de telefone cadastrado na UBS — nesses casos, o lembrete telefônico convencional permanece como alternativa”; “o sistema não funciona se a UBS não atualizar o cadastro de agendamentos com regularidade — a cadência de atualização é uma dependência crítica de funcionamento”.
Existe uma conexão direta entre a descrição de solução e o que você aprendeu no Módulo 11, sobre Segurança da Informação e LGPD. Toda descrição de solução que envolva o processamento de dados pessoais de pacientes — e praticamente toda HealthTech envolve — precisa incluir, como elemento adicional, a descrição dos dados sensíveis que são processados, a base legal para esse processamento sob a Lei Geral de Proteção de Dados, e as medidas técnicas de proteção que serão adotadas.
Para o exemplo que usamos, os dados processados incluem nome completo do paciente, número de telefone, data e hora da consulta agendada e a confirmação ou não-comparecimento. Esses dados são, em combinação, dados de saúde — pois revelam que a pessoa é paciente de uma unidade de saúde com uma condição específica. A base legal pode ser o legítimo interesse do responsável pelo tratamento (a UBS) na execução de política de saúde pública, combinada com o consentimento explícito do paciente coletado no cadastro. A medida técnica inclui criptografia de dados em repouso e em trânsito, controle de acesso baseado em papéis, e política de retenção de dados com prazo definido.
Incluir esse elemento na descrição de solução não é apenas uma obrigação legal — é um sinal de maturidade do produto. Investidores em HealthTech, gestores de saúde e parceiros institucionais avaliam esse elemento como diferenciador positivo de equipes que pensaram na solução de forma responsável desde o início.
Conexão com o Módulo 14 — Prototipação: a descrição de solução que você produz neste módulo é o insumo direto para o Módulo 14. O protótipo testa uma hipótese central sobre o produto — e identificar qual é a hipótese central só é possível quando a solução está bem definida. Se a definição for vaga, o protótipo também será vago, e um protótipo vago não gera aprendizado sobre o que precisa ser testado.
Erros comuns no preenchimento do canvas — e como identificá-los
O Value Proposition Canvas é uma ferramenta de diagnóstico tão poderosa quanto os dados que a alimentam — e tão enganosa quanto as suposições que a distorcem. Os cinco erros que descrevo a seguir são os mais frequentes em grupos de estudantes que trabalham com a ferramenta pela primeira vez, e reconhecê-los é a primeira condição para evitá-los.
Erro 1: preencher o Perfil do Cliente com suposições em vez de dados de empatia. Este é o erro mais prevalente e o mais difícil de detectar, porque o resultado visual é idêntico: um canvas preenchido. A diferença está na qualidade do encaixe. Um Perfil do Cliente preenchido com observações reais produz um encaixe entre problema e solução que tem chance real de funcionar quando testado com usuários. Um Perfil do Cliente preenchido com o que a equipe supõe sobre o usuário produz um encaixe que funciona apenas no papel — e que colapsa no primeiro teste com um usuário real.
Como identificar: peça a cada membro do grupo que cite, para cada item do Perfil do Cliente, a entrevista específica ou a observação do Mapa de Empatia que gerou aquele item. Se não houver resposta, o item é suposição. A porcentagem de itens que não têm fonte citável é uma medida direta da fragilidade do canvas.
Erro 2: preencher o Mapa de Valor antes do Perfil do Cliente. Conforme discutido, esse é o erro de inversão: a equipe começa com o produto que quer construir e preenche o Perfil do Cliente de forma que o produto pareça fazer sentido. O resultado é sempre um encaixe perfeito — precisamente porque o Perfil do Cliente foi construído para encaixar. É o equivalente clínico de construir o diagnóstico para justificar o tratamento que o médico já havia decidido antes de examinar o paciente.
Como identificar: se o Perfil do Cliente parece descrever um usuário que precisa exatamente do que o produto oferece — sem nenhuma dor que o produto não endereça, sem nenhum ganho que o produto não cria — provavelmente o Perfil foi construído de trás para frente. Um Perfil do Cliente real é sempre mais amplo do que o Mapa de Valor pode endereçar: há dores que o produto não alivia, ganhos que o produto não cria e tarefas nas quais o produto não interfere. Isso não é falha do produto — é realidade. Um produto que tenta endereçar tudo não endereça nada bem.
Erro 3: formular aliviadores de dor como descrições de funcionalidade. O canvas tem a dimensão de Produtos e Serviços para listar as funcionalidades do produto. Os Aliviadores de Dor não são funcionalidades — são os mecanismos pelos quais as funcionalidades endereçam dores específicas. Quando um grupo escreve “o sistema tem criptografia de ponta a ponta” como Aliviador de Dor, está descrevendo uma característica técnica, não o alívio de uma dor do usuário. A dor poderia ser “medo de que dados médicos sejam vistos por pessoas não autorizadas”, e o aliviador seria “garante que apenas o médico responsável e o próprio paciente têm acesso aos dados de saúde registrados no sistema”.
Como identificar: leia cada Aliviador de Dor em voz alta e pergunte “isso está descrito do ponto de vista do produto ou do ponto de vista do usuário?” Se a resposta for “do produto”, reformule.
Erro 4: propor criadores de ganho para ganhos que não foram identificados nas entrevistas. Equipes frequentemente incluem criadores de ganho para funcionalidades que acharam interessante incluir no produto, sem verificar se o ganho correspondente apareceu de fato nas entrevistas de empatia. O resultado é um produto com funcionalidades que o usuário não pediu, não valoriza e, possivelmente, não vai usar — o que desperdiça recursos de desenvolvimento e dilui o foco do produto.
Como identificar: para cada Criador de Ganho no Mapa de Valor, encontre o Ganho correspondente no Perfil do Cliente. Se o Ganho não estiver lá, ou se estiver lá mas na categoria de ganho “inesperado” sem nenhuma evidência nas entrevistas, questione a inclusão desse Criador de Ganho no escopo desta versão do produto.
Erro 5: redigir a proposta de valor na linguagem das características. Conforme explorado em detalhes na seção anterior, este erro produz uma proposta de valor que comunica o que o produto tecnicamente é em vez do que o produto faz pela vida do usuário. Uma proposta de valor escrita em linguagem de características pode ser percebida como competente por engenheiros mas é invisível para os usuários reais.
Como identificar: aplique o teste da pessoa leiga. Leia a proposta de valor para alguém que não tem nenhum conhecimento técnico e pergunte “o que você acha que esse produto faz?” Se a resposta incluir descrições técnicas ou protocolos, a proposta está escrita em linguagem de características. Se a resposta descrever uma mudança na vida de alguém específico, está no caminho certo.
O produto do módulo — o que seu grupo deve entregar
Ao final deste módulo, seu grupo deverá ter produzido três documentos distintos que se articulam entre si. Compreender a função de cada um e a relação entre eles é importante para que o trabalho durante os 170 minutos de atividade seja organizado e produza resultados utilizáveis no Módulo 14.
O primeiro documento é o Value Proposition Canvas completo, com todos os elementos preenchidos e com rastreabilidade das fontes de dados para o Perfil do Cliente. Cada item do Perfil do Cliente deve ter, anotado ao lado, a fonte que o originou — entrevista, Mapa de Empatia ou Jornada do Usuário. Cada Aliviador de Dor deve ter uma linha explícita conectando-o à Dor correspondente. Cada Criador de Ganho deve ter uma linha explícita conectando-o ao Ganho correspondente.
O segundo documento é a definição da solução, estruturada nos cinco elementos descritos na seção anterior: usuário específico, funcionalidade principal como fluxo de uso, exclusões explícitas, condições de funcionamento e condições de falha. Adicionalmente, o elemento de dados pessoais e LGPD deve estar presente, identificando os dados processados, a base legal e as medidas de proteção.
O terceiro documento é o parágrafo de proposta de valor, redigido na linguagem dos benefícios, que qualquer pessoa possa ler e entender sem conhecimento técnico, e que qualquer membro do grupo possa usar para explicar o produto de forma convincente a um usuário real, a um médico parceiro, a um gestor de saúde ou a um potencial investidor.
Esses três documentos serão a base do trabalho no Módulo 14, onde seu grupo construirá o protótipo inicial. O protótipo testará a hipótese central que emerge da definição da solução — e essa hipótese só pode ser identificada com clareza quando os três documentos deste módulo estão completos e coerentes entre si.
O processo de design thinking até aqui — uma síntese integradora
Você está no décimo terceiro módulo de uma disciplina projetada para que o aprendizado de cada etapa construa diretamente sobre o que veio antes. Vale a pena, antes de entrar no trabalho prático deste módulo, fazer um inventário do que seu grupo construiu até aqui e compreender como cada peça se encaixa na estrutura maior.
No Módulo 9, seu grupo foi a campo. Realizou entrevistas com usuários reais — não com usuários imaginários, mas com pessoas que vivem os problemas que você está tentando resolver. Aprendeu a fazer perguntas abertas que revelam motivações e contextos em vez de confirmar hipóteses. Coletou dados brutos: citações, observações comportamentais, incongruências entre o que as pessoas dizem e o que fazem. Esse trabalho de campo é o fundamento de tudo que vem depois.
No Módulo 10, seu grupo organizou os dados brutos em estruturas que tornam os padrões visíveis. O Mapa de Empatia transformou observações dispersas em uma compreensão organizada do que o usuário pensa, sente, diz, faz, sofre e deseja. A Jornada do Usuário revelou como o problema se manifesta ao longo do tempo e identificou os momentos de maior atrito — os pontos onde a dor é mais intensa e onde uma intervenção produziria o maior impacto. O enunciado POV destilou tudo isso em uma declaração precisa sobre quem é o usuário, qual é a necessidade fundamental e qual é o insight que justifica essa necessidade.
No Módulo 12, seu grupo liberou o pensamento criativo de forma estruturada. Brainstorming e Crazy 8s expandiram o espaço de soluções possíveis bem além do óbvio. O processo de convergência — clusterização, votação, matriz de impacto e viabilidade — reduziu esse espaço à ideia mais promissora, com critérios explícitos para a escolha. Você saiu do Módulo 12 com uma ideia selecionada e uma justificativa documentada.
Neste módulo, as duas linhas de trabalho se encontram formalmente pela primeira vez: o conhecimento profundo do usuário (construído nos Módulos 9 e 10) é colocado lado a lado com a melhor ideia de solução (produzida no Módulo 12), e o Value Proposition Canvas torna visível se existe — ou não — um encaixe real entre os dois. A solução definida que emerge desse processo é o insumo que o Módulo 14 precisa para construir um protótipo que teste as hipóteses certas.
O diagrama a seguir mostra essa trajetória completa e o lugar deste módulo no processo de design thinking que seu grupo percorreu ao longo da disciplina.
flowchart LR
subgraph EMP["EMPATIA<br/>Módulos 9 e 10"]
direction TB
M9["Módulo 9<br/>Entrevistas<br/>Dados brutos"] --> M10["Módulo 10<br/>Mapa de Empatia<br/>Jornada do Usuário<br/>POV"]
end
subgraph DEF["DEFINIÇÃO<br/>Módulo 10"]
direction TB
POV["POV<br/>Enunciado do Problema<br/>HMW — Como Poderíamos?"]
end
subgraph IDEA["IDEAÇÃO<br/>Módulo 12"]
direction TB
M12["Módulo 12<br/>Brainstorm + Crazy 8s<br/>Ideia selecionada<br/>com critérios"]
end
subgraph SOL["SOLUÇÃO<br/>Módulo 13"]
direction TB
M13A["Value Proposition Canvas<br/>Perfil do Cliente<br/>Mapa de Valor<br/>Encaixe"]
M13B["Definição da Solução<br/>5 elementos<br/>+ LGPD"]
M13C["Proposta de Valor<br/>parágrafo de benefícios"]
M13A --> M13B --> M13C
end
subgraph PROT["PROTOTIPAÇÃO<br/>Módulo 14"]
direction TB
M14["Módulo 14<br/>Protótipo<br/>Hipótese central<br/>Teste com usuários"]
end
subgraph VAL["VALIDAÇÃO<br/>Módulo 15"]
direction TB
M15["Módulo 15<br/>Validação<br/>Modelo de Negócio<br/>Pitch"]
end
EMP --> DEF --> IDEA
M10 -->|"Perfil do Cliente"| SOL
IDEA -->|"Ideia selecionada"| SOL
SOL --> PROT --> VAL
style EMP fill:#f5f0e8,color:#333,stroke:#c8a96e
style DEF fill:#e8f5e8,color:#333,stroke:#6ec87b
style IDEA fill:#e8eef5,color:#333,stroke:#6e9ac8
style SOL fill:#f5e8e8,color:#333,stroke:#c86e6e
style PROT fill:#f5f0e8,color:#333,stroke:#c8a96e
style VAL fill:#e8f0f5,color:#333,stroke:#6e9ac8
style M9 fill:#4dac26,color:#fff,stroke:#2d7a14
style M10 fill:#74add1,color:#fff,stroke:#4a8ab0
style POV fill:#4dac26,color:#fff,stroke:#2d7a14
style M12 fill:#7b3294,color:#fff,stroke:#561f6a
style M13A fill:#d7191c,color:#fff,stroke:#a01010
style M13B fill:#f07d02,color:#fff,stroke:#b85c00
style M13C fill:#2c7bb6,color:#fff,stroke:#1a5a8a
style M14 fill:#1a1a2e,color:#fff,stroke:#0d0d1a
style M15 fill:#1a1a2e,color:#fff,stroke:#0d0d1a
Proposta de valor na medicina — por que isso importa além do projeto
Você pode estar se perguntando por que um estudante de medicina precisa saber formular propostas de valor. A pergunta é legítima e merece uma resposta direta.
A medicina contemporânea está atravessando uma transformação acelerada na qual o médico cada vez mais precisará articular, para múltiplos públicos com perspectivas distintas, por que determinada intervenção, protocolo, tecnologia ou mudança de prática clínica vale a pena. Esse não é mais apenas um exercício acadêmico — é uma competência prática que determinará a capacidade do médico de implementar inovações, de influenciar políticas institucionais e de advogar por recursos para os seus pacientes.
Quando um médico defende a adoção de telemedicina em uma instituição conservadora, precisa articular a proposta de valor da telemedicina para um gestor hospitalar — não em termos de infraestrutura técnica (características), mas em termos de acesso, custo e resultado para o paciente (benefícios). Quando um médico propõe mudanças num protocolo de atendimento, precisa convencer colegas e coordenadores — não com argumentos técnicos isolados, mas com a demonstração de qual problema real o protocolo atual não resolve e como a mudança proposta endereça esse problema. Quando um médico lidera um serviço de saúde e precisa justificar um investimento em tecnologia para um conselho ou para uma secretaria de saúde, a pergunta que precisará responder é exatamente a da proposta de valor: “o que muda para o paciente se fizermos isso?”
A distinção entre características e benefícios, o processo de rastrear qualquer proposta ao impacto real sobre pessoas reais, a disciplina de não pressupor que o usuário valoriza o que você valoriza — todas essas habilidades que você está desenvolvendo neste módulo são competências médicas tanto quanto são competências de design de produto.
Há também uma dimensão ainda mais direta: à medida que a IA e outras tecnologias transformam a prática médica, os médicos que conseguirem colaborar produtivamente no desenvolvimento e na implementação de soluções tecnológicas — não como especialistas em tecnologia, mas como especialistas no problema clínico que a tecnologia pretende resolver — terão um papel diferenciado nessa transformação. Saber articular com precisão o que o usuário real precisa, quais dores devem ser aliviadas e quais ganhos são genuinamente valorizados é a contribuição específica que o conhecimento clínico oferece ao desenvolvimento de produtos de saúde. Essa contribuição só é possível quando o médico tem vocabulário e metodologia para traduzir o conhecimento clínico em linguagem compreensível para equipes de produto.
Um guia para o trabalho em grupo — os 170 minutos do projeto
Os 170 minutos de trabalho em grupo neste módulo são distribuídos em três blocos com objetivos distintos e resultados verificáveis. Descrevo a seguir a estrutura sugerida para esses blocos, com as perguntas-guia que devem orientar o trabalho de cada fase.
O primeiro bloco, de aproximadamente 60 minutos, é dedicado ao Perfil do Cliente. O grupo deve reunir todos os materiais dos Módulos 9 e 10 e, a partir deles, preencher as três dimensões do Perfil do Cliente com rastreabilidade explícita de cada item. A pergunta que deve guiar esse bloco é: “cada item que estamos colocando aqui tem origem em algo que alguém nos disse, em algo que observamos, ou em algo que está no Mapa de Empatia ou na Jornada do Usuário?” Se a resposta for não, o item é suposição e deve ser marcado como tal — não eliminado, mas claramente identificado para revisão posterior.
O segundo bloco, de aproximadamente 70 minutos, é dedicado ao Mapa de Valor e à verificação do encaixe. Com o Perfil do Cliente preenchido, o grupo formula os Aliviadores de Dor, os Criadores de Ganho e lista os Produtos e Serviços. Para cada Aliviador de Dor formulado, a pergunta é: “qual dor específica do Perfil do Cliente este alivia, e como exatamente o alivia?” Para cada Criador de Ganho, a pergunta é: “qual ganho específico do Perfil do Cliente este cria, e como exatamente o cria?” Ao final deste bloco, o grupo deve traçar as linhas de correspondência e identificar as dores de alta intensidade que não têm aliviadores correspondentes — elas são candidatas a ser incorporadas ao escopo ou a ser reconhecidas como limitações desta versão do produto.
O terceiro bloco, de aproximadamente 40 minutos, é dedicado à definição da solução e ao parágrafo de proposta de valor. A partir do canvas preenchido, o grupo redige os cinco elementos da definição da solução e o parágrafo de proposta de valor. O teste final: leia o parágrafo para alguém fora do grupo — um colega de outra área, um familiar, qualquer pessoa sem conhecimento técnico específico — e verifique se a pessoa consegue responder com suas próprias palavras “para quem isso serve e por que faria diferença”.
Sinais de que algo precisa ser revisado: se o Perfil do Cliente foi preenchido em menos de 20 minutos, provavelmente foi preenchido com suposições. Se o Mapa de Valor foi preenchido antes do Perfil do Cliente, houve inversão de processo. Se cada item do Perfil do Cliente tem exatamente um aliviador de dor ou criador de ganho correspondente, o canvas foi preenchido de trás para frente. Se o parágrafo de proposta de valor inclui termos técnicos que precisam de explicação, foi escrito na linguagem das características.
Síntese e preparação para o Módulo 14
Este módulo marcou uma transição importante no desenvolvimento do seu projeto. Você começou com uma ideia — intencional, promissora, mas ainda difusa — e, ao final do trabalho, terá uma solução definida: um produto com escopo explícito, com limites claros, com um Perfil do Cliente fundamentado em dados reais, com um Mapa de Valor que endereça as dores e ganhos mais significativos desse cliente, e com uma proposta de valor articulada na linguagem dos benefícios.
Essa transição da ideia para a solução não é apenas um exercício acadêmico de metodologia de produto. É o exercício de uma forma de pensar que você utilizará ao longo de toda a carreira médica: a habilidade de ir da observação de um problema real à proposta de uma intervenção específica, com fundamentação explícita em dados, com limites claramente definidos e com a capacidade de comunicar o valor da intervenção de forma que quem precisa decidir sobre ela possa entender o que está em jogo.
No Módulo 14, você usará a definição da solução que produziu aqui para construir um protótipo. O protótipo não tentará representar o produto completo — ele testará a hipótese central do produto: a suposição mais importante que, se for falsa, invalida todo o resto da proposta de valor. Identificar essa hipótese central é o primeiro passo do Módulo 14 — e ela só pode ser identificada com clareza quando a solução está definida com a precisão que este módulo exigiu de você.
O trabalho de hoje é o fundamento do que vem a seguir.
Glossário dos termos centrais
Os termos a seguir aparecem com frequência na literatura e nas discussões sobre design de produto e são usados com precisão técnica neste módulo. Conhecê-los com exatidão evita confusões comuns que levam a erros de preenchimento do canvas.
Value Proposition Canvas: ferramenta de diagnóstico de encaixe entre produto e cliente, composta pelo Perfil do Cliente (tarefas, dores e ganhos) e pelo Mapa de Valor (produtos e serviços, aliviadores de dor e criadores de ganho). Desenvolvida por Alexander Osterwalder e Yves Pigneur.
Perfil do Cliente (Customer Profile): lado direito do canvas, que descreve o cliente. Preenchido exclusivamente a partir de dados de pesquisa de empatia — nunca de suposições.
Mapa de Valor (Value Map): lado esquerdo do canvas, que descreve o produto. Preenchido a partir do Perfil do Cliente para garantir correspondência.
Encaixe (Fit): estado em que cada aliviador de dor alivia uma dor real do Perfil do Cliente e cada criador de ganho cria um ganho real do Perfil do Cliente. Existem três tipos: encaixe entre problema e solução (no papel), entre produto e mercado (com testes), e com o modelo de negócio (sustentabilidade).
Tarefas do Cliente (Customer Jobs): o que o cliente está tentando realizar na vida — funções, objetivos sociais e estados emocionais desejados. Existem independentemente do produto.
Dores (Pains): o que impede, bloqueia, frustra ou preocupa o cliente enquanto tenta realizar suas tarefas. Diferentes da ausência de ganhos.
Ganhos (Gains): os resultados e benefícios que o cliente deseja — em quatro intensidades: necessários, esperados, desejados e inesperados.
Aliviadores de Dor (Pain Relievers): como o produto endereça dores específicas do Perfil do Cliente. Descritos na perspectiva do usuário, não do produto.
Criadores de Ganho (Gain Creators): como o produto cria ou amplifica ganhos específicos do Perfil do Cliente.
Característica (Feature): propriedade do produto, descrita do ponto de vista técnico ou funcional do produto em si.
Benefício (Benefit): resultado para o usuário, descrito do ponto de vista do impacto na vida ou no trabalho do usuário.
Proposta de Valor: promessa específica sobre o que muda na vida do usuário ao usar o produto, redigida na linguagem dos benefícios, compreensível por qualquer pessoa sem conhecimento técnico específico.
Encaixe entre problema e solução (Problem-Solution Fit): verificação, com dados de pesquisa, de que o Mapa de Valor endereça as tarefas, doras e ganhos mais significativos do Perfil do Cliente. Ocorre no Módulo 13.
Encaixe entre produto e mercado (Product-Market Fit): validação, com testes com usuários reais, de que os aliviadores de dor e criadores de ganho funcionam como previsto. Ocorre nos Módulos 14 e 15.
Escopo (Scope): o conjunto definido de funcionalidades e casos de uso que o produto cobre nesta versão.
Expansão de escopo (Scope Creep): adição progressiva e não planejada de funcionalidades ao produto, normalmente resultado de uma definição de solução vaga.
Para aprofundar
Se você quiser aprofundar os conceitos deste módulo, as obras a seguir são as referências diretas para o que foi discutido aqui. Osterwalder, A. e Pigneur, Y. — “Value Proposition Design: How to Create Products and Services Customers Want” (2014) — é a fonte primária para o Value Proposition Canvas e o ponto de partida para qualquer aprofundamento. O mesmo Osterwalder e Pigneur publicaram “Business Model Generation” (2010), que apresenta o Business Model Canvas e é útil para compreender o contexto mais amplo do qual o Value Proposition Canvas surgiu. Para a distinção entre características e benefícios, Theodore Levitt escreveu “Marketing Myopia” em 1960 na Harvard Business Review — um dos artigos mais lidos e citados em toda a história da administração, disponível gratuitamente nos arquivos digitais da HBR. Para o contexto de design thinking, Tim Brown — fundador da IDEO — publicou “Change by Design” (2009), que apresenta a metodologia do design centrado no ser humano de forma acessível e com exemplos da área da saúde. No contexto especificamente de startups de saúde, o framework de Eric Ries apresentado em “The Lean Startup” (2011) é complementar ao que foi discutido aqui, especialmente no conceito de hipótese central e produto mínimo viável, que você usará no Módulo 14.