flowchart TD
A["Módulo 02<br/>Canvas inicial de hipóteses<br/>(problema + usuário + solução)"]
B["Módulos 3-8<br/>Conteúdo técnico<br/>(IA, Telemedicina, Agentes, RV/RA, Biotecnologia)"]
C["Módulo 09<br/>Design Thinking e Empatia<br/>(pesquisa qualitativa com usuários)"]
D["Módulo 10<br/>Mapa de Empatia e Jornada do Usuário<br/>(síntese do usuário)"]
E["Módulo 12<br/>Ideação<br/>(Brainstorm + Crazy 8s)"]
F["Módulo 13<br/>Solução e Proposta de Valor<br/>(refinamento da solução)"]
G["Módulo 14<br/>Prototipação<br/>(MVP tangível)"]
H["Módulo 15<br/>Validação e Modelo de Negócio<br/>(canvas final)"]
I["Apresentação final<br/>Pitch para banca"]
A --> B
B --> C
A --> C
C --> D
D --> E
E --> F
F --> G
G --> H
H --> I
style A fill:#0d6efd,color:#fff
style C fill:#198754,color:#fff
style D fill:#198754,color:#fff
style E fill:#fd7e14,color:#fff
style F fill:#fd7e14,color:#fff
style G fill:#dc3545,color:#fff
style H fill:#dc3545,color:#fff
style I fill:#6f42c1,color:#fff
Startup: Conceituar a HealthTech
Ao final deste módulo, você será capaz de:
distinguir startups de empresas tradicionais e compreender as especificidades que tornam as HealthTechs um subcampo singular do empreendedorismo; aplicar os conceitos centrais da metodologia Lean Startup — em particular o ciclo construir-medir-aprender, o MVP, o pivô e a aprendizagem validada — ao contexto de um projeto de saúde digital; identificar os principais agentes regulatórios e os atores do ecossistema de saúde digital no Brasil, compreendendo como eles condicionam o modelo de negócio de uma HealthTech; articular uma hipótese de problema de forma estruturada, distinguindo o que o seu grupo sabe do que supõe; e iniciar o trabalho em equipe com clareza sobre objetivos, papéis e dinâmica de colaboração.
O que é uma startup: buscando um modelo sob incerteza
Quando você ouve a palavra “startup”, é provável que venham à mente imagens de jovens em escritórios descontraídos, aplicativos de smartphone e rodadas milionárias de investimento. Essa associação não é inteiramente errada, mas é superficial — e superficialidade é um luxo que quem está tentando construir uma startup não pode se dar. Para este módulo, e para o projeto integrador que você desenvolverá ao longo do semestre, é necessário começar pela definição precisa do que uma startup é e, sobretudo, do que ela não é.
A definição mais influente e útil da palavra startup foi formulada pelo empreendedor e professor norte-americano Steve Blank: uma startup é uma organização temporária projetada para buscar, em condições de incerteza radical, um modelo de negócios escalável e repetível. Pouco depois, Eric Ries, ex-aluno de Blank e autor do livro “The Lean Startup” (2011), refinaria essa definição ao enfatizar que a startup ainda não sabe qual é o seu negócio — ela está aprendendo. Cada palavra dessa definição merece atenção.
“Organização temporária” porque a startup não existe para si mesma: ela existe para encontrar um modelo de negócios que, uma vez encontrado, transformará a startup em uma empresa capaz de crescer. Quando isso acontece, a startup deixa de existir como tal e passa a ser uma empresa em operação. A Amazon de 1994, operando a partir de uma garagem em Seattle e vendendo livros por correio, era uma startup. A Amazon de hoje é uma das maiores corporações do mundo e definitivamente não é mais uma startup — ainda que tenha preservado algumas práticas culturais da época.
“Condições de incerteza radical” é a parte da definição que mais frequentemente passa despercebida, e que mais importa para entender por que uma startup precisa se comportar de forma diferente de uma empresa tradicional. A incerteza radical não é o mesmo que risco calculável. Risco calculável é o que uma companhia de seguros faz com maestria: com base em dados históricos suficientes, ela pode estimar com precisão razoável a probabilidade de um carro ser roubado em determinada cidade, de uma pessoa com certo perfil de saúde vir a ter um infarto antes dos sessenta anos, de uma lavoura ser destruída por granizo num certo período do ano. O risco calculável admite modelos probabilísticos, análises atuariais e estratégias de hedge.
A startup, por sua vez, opera em terreno onde dados históricos suficientes simplesmente não existem ou não se aplicam. Ela está, por definição, tentando criar algo que não existia antes — um produto, um serviço, uma forma de distribuição, um modelo de precificação — em um mercado que ainda não se formou completamente ou cujo comportamento ainda não é previsível. Não há série histórica para consultar porque o que a startup está tentando fazer não foi feito antes, pelo menos não daquela forma, para aquele público, naquele contexto. Essa é a incerteza radical: não saber o que não sabe.
A consequência prática dessa distinção é profunda. Uma empresa tradicional — uma rede de farmácias, uma operadora de planos de saúde, um hospital privado — tem um modelo de negócios estabelecido. Ela sabe qual é o seu produto, para quem o vende, a que preço, por qual canal de distribuição, com qual estrutura de custos. O problema de gestão que ela enfrenta é como executar esse modelo com eficiência crescente: reduzir custos, ampliar cobertura, fidelizar clientes, melhorar processos. É um problema de execução. A startup, pelo contrário, não sabe nenhuma dessas coisas. Ela tem uma hipótese sobre um produto, uma intuição sobre um mercado, uma crença sobre um modelo de preço — mas tudo isso precisa ser testado. O problema central da startup não é execução: é aprendizagem.
A distinção entre executar e buscar
Compreender a diferença entre “executar um plano” e “buscar um modelo” é talvez o insight mais importante que você levará deste módulo para o projeto integrador. Uma empresa tradicional recebe, no início do ano, um plano de negócios com metas claras: crescer o faturamento em quinze por cento, abrir duas novas unidades, reduzir o índice de glosa dos planos de saúde. Esse plano foi construído sobre premissas que a empresa já verificou empiricamente ao longo de anos de operação. O papel da gestão é garantir que o plano seja cumprido.
Uma startup no primeiro mês de existência não tem esse luxo. Ela tem hipóteses — crenças sobre como o mercado funciona, sobre o que o usuário quer, sobre qual problema vale a pena resolver e como resolvê-lo. O papel da equipe fundadora é transformar hipóteses em conhecimento verificado tão rápido quanto possível, gastando o mínimo possível para fazer isso. Essa é a essência do que Steve Blank chama de “busca” — e é radicalmente diferente da execução de planos conhecidos.
Isso tem uma implicação que contraria o senso comum: o planejamento extenso e detalhado, que funciona bem para empresas estabelecidas, é frequentemente contraproducente para startups. Um plano de negócios de quarenta páginas escrito antes de a startup ter conversado com qualquer usuário real é, na prática, um documento repleto de hipóteses apresentadas como certezas. O problema não é escrever o plano — é confundir o plano com a realidade. Startups que operam dessa forma tendem a gastar meses construindo produtos que descobrem, tarde demais, que ninguém quer.
Por que “empresa pequena” não é sinônimo de startup
Uma confusão muito comum — e com consequências práticas significativas — é equiparar startup a “empresa pequena” ou “empresa nascente”. Essa equação é incorreta, e entender por que ela é incorreta ajuda a clarificar o que realmente distingue o empreendedorismo de startup de outras formas de empreendedorismo.
Um consultório médico recém-aberto por um recém-formado é uma empresa pequena e nascente, mas não é uma startup. Ele tem um modelo de negócios bem estabelecido — consulta médica presencial, remuneração por procedimento ou por plano de saúde, custo fixo previsível de aluguel, equipamentos e funcionários — e seu desafio é executar esse modelo com competência, conquistar uma carteira de pacientes e se estabelecer na comunidade. Esse é um desafio legítimo e difícil, mas é um problema de execução, não de busca.
Uma HealthTech que está desenvolvendo um sistema de triagem baseado em inteligência artificial para uso em unidades básicas de saúde, por outro lado, é uma startup mesmo que tenha dez funcionários e esteja há dois anos no mercado — porque ela ainda não sabe com certeza se seu produto resolve o problema que se propõe a resolver, se os gestores de saúde vão comprá-lo, se a ANVISA vai classificar o software como dispositivo médico regulado, se o modelo de precificação por assinatura mensal funciona melhor do que o modelo de licença anual. Ela ainda está buscando. Enquanto estiver buscando, é uma startup.
Exemplos históricos de busca de modelo
Olhar para como empresas icônicas encontraram seus modelos de negócio é uma forma eficaz de tornar concreto o que significa “buscar sob incerteza”. Amazon, Airbnb e Nubank são exemplos particularmente instrutivos porque todos eles envolvem pivôs significativos — mudanças de direção baseadas em aprendizado — antes de encontrarem o modelo que os tornou o que são hoje.
A Amazon começou em 1994 como uma livraria online. Jeff Bezos escolheu livros como produto inicial não porque tivesse uma visão grandiosa sobre o varejo, mas porque livros eram um produto com características favoráveis para venda online: enorme variedade de títulos, embalagem simples, baixo custo de armazenamento por unidade. O verdadeiro modelo de negócios da Amazon — uma plataforma de e-commerce para qualquer categoria de produto, com uma infraestrutura de computação em nuvem vendida para terceiros como Amazon Web Services — não existia no plano original de 1994. Emergiu de anos de experimentação, aprendizado com os clientes e expansão gradual de capacidades.
O Airbnb começou em 2008 quando seus fundadores, sem dinheiro para pagar o aluguel em San Francisco, resolveram alugar colchões infláveis no apartamento deles para pessoas que precisavam de hospedagem durante uma conferência de design. A ideia inicial era modesta e específica: hospedagem alternativa para viajantes sem recursos durante eventos de alta demanda. O modelo de plataforma global de hospedagem entre pares só foi encontrado depois de muita experimentação, incluindo uma fase em que os fundadores foram pessoalmente de porta em porta fotografar os imóveis anunciados em Nova York para melhorar a qualidade das listagens — uma intervenção manual e não escalável que confirmou uma hipótese sobre o que impedia os hóspedes de reservar.
O Nubank foi fundado em 2013 com a hipótese de que o mercado de cartões de crédito no Brasil era dominado por poucos bancos grandes que cobravam tarifas abusivas e ofereciam péssima experiência ao cliente. O produto inicial era um cartão de crédito sem anuidade gerenciado exclusivamente por aplicativo. Mas o Nubank precisou testar se os brasileiros confiariam em um banco digital sem agências, se a ausência de anuidade seria suficiente para gerar adesão, se a interface poderia ser mais simples do que a dos bancos tradicionais. Cada uma dessas era uma hipótese que precisou ser validada antes de o modelo ser confirmado.
O que esses três exemplos têm em comum é a disposição para aprender rápido e mudar de direção quando o aprendizado assim indicava — sem, no entanto, abandonar as convicções fundamentais sobre o problema que queriam resolver. Essa combinação de flexibilidade tática com clareza estratégica é uma das marcas do empreendedor que usa bem a metodologia que examinaremos a seguir.
A Lean Startup: aprender mais rápido do que se gasta
Em 2011, Eric Ries publicou “The Lean Startup” — um livro que sistematizou práticas que fundadores de empresas de tecnologia vinham desenvolvendo empiricamente desde os anos 2000 e as transformou num método coerente e ensinável. O livro tornou-se um dos mais influentes na história do empreendedorismo e mudou a forma como aceleradoras, investidores e fundadores ao redor do mundo pensam sobre como construir novas empresas.
O ponto de partida de Ries é uma crítica direta às práticas então dominantes no empreendedorismo: planos de negócio longos e detalhados escritos antes de qualquer validação de mercado, desenvolvimento de produto longo e secreto que só liberava o produto ao público quando estava “pronto”, e a crença de que execução perfeita era mais importante do que aprendizado rápido. Ries argumentou que essas práticas eram responsáveis por uma taxa de fracasso altíssima nas startups — não porque os empreendedores fossem incompetentes, mas porque o método era errado.
O ciclo construir-medir-aprender
O coração da metodologia Lean Startup é o ciclo construir-medir-aprender. A descrição parece simples, mas as implicações são profundas e frequentemente contraintuitivas.
O ciclo funciona assim: a startup parte de uma hipótese sobre o que os usuários querem ou precisam. Em vez de construir o produto completo baseado nessa hipótese, ela constrói o experimento mais simples possível que permita testar a hipótese — isso é o que Ries chama de Produto Mínimo Viável, ou MVP. Com esse MVP em mãos, a startup o expõe a usuários reais e mede o que acontece: as pessoas usam o produto? Pagam por ele? Voltam a usá-lo depois da primeira experiência? Recomendam para amigos? Com base nas medições, a equipe aprende se a hipótese era válida ou não — e decide se deve perseverar na direção atual ou pivotar para uma nova direção. Depois, o ciclo recomeça.
O que torna esse ciclo poderoso não é nenhuma das etapas isoladas, mas a velocidade com que ele é percorrido e a disciplina de usar dados reais — e não intuições ou opiniões — para tomar decisões. Ries enfatiza que o objetivo não é construir mais rápido, nem medir mais dados, nem aprender mais sobre qualquer coisa: o objetivo é encurtar o ciclo inteiro para que cada rodada de aprendizado seja completada antes que os recursos da startup se esgotem.
Um erro comum entre estudantes e empreendedores iniciantes é interpretar o ciclo como uma sequência linear: primeiro construímos, depois medimos, depois aprendemos, e então recomeçamos. Na realidade, o ciclo é pensado de trás para frente. Você começa pelo aprendizado: qual é a hipótese mais importante que preciso validar agora? A partir daí, você define a medição: que métrica me dirá se a hipótese é verdadeira ou falsa? E só então você define a construção: qual é o menor experimento que me dará essa medição? Inverter essa lógica — construir primeiro e perguntar depois o que medir — é uma das formas mais comuns de desperdiçar recursos numa startup.
A hipótese de valor e a hipótese de crescimento
Ries identifica duas hipóteses fundamentais que toda startup precisa validar antes de poder afirmar que tem um negócio sustentável. Compreender cada uma delas é essencial para o projeto integrador que você vai desenvolver.
A hipótese de valor pergunta: o produto ou serviço cria valor suficiente para que o usuário queira usá-lo de forma recorrente? Essa hipótese é sobre a proposta de valor central da startup — se o que ela oferece resolve um problema real, de uma forma que o usuário considera melhor do que as alternativas disponíveis. Validar a hipótese de valor significa encontrar usuários que efetivamente escolhem o produto, que o usam, que se importariam se deixasse de existir. Não significa apenas que usuários dizem gostar do produto em pesquisas de opinião — significa que eles demonstram esse valor com comportamento: uso frequente, disposição para pagar, recomendação espontânea.
A hipótese de crescimento pergunta: como novos usuários descobrem e adotam o produto? Uma startup que tem uma hipótese de valor validada — um produto que seus usuários existentes adoram — mas não tem uma hipótese de crescimento clara está presa num nicho. Ela pode ser um negócio pequeno e sustentável, mas não é uma startup no sentido preciso do termo, porque não tem o potencial de escalar. Existem três tipos básicos de motor de crescimento identificados por Ries: o motor viral, no qual usuários existentes recrutam novos usuários por meio de uso normal do produto; o motor de pagamento, no qual a empresa usa receita para comprar novos clientes por meio de publicidade ou vendas; e o motor pegajoso, no qual a retenção de usuários existentes é tão alta que o crescimento orgânico sustenta a expansão. Identificar qual motor se aplica ao seu negócio — e estruturar os experimentos em torno desse motor — é parte essencial do trabalho de busca de modelo.
Aprendizagem validada como unidade de progresso
Uma das contribuições mais importantes de Ries à teoria do empreendedorismo é a noção de aprendizagem validada como unidade de progresso para uma startup. Essa ideia desafia intuitivamente o que a maioria das pessoas entende por “progresso” num projeto.
Em um projeto de desenvolvimento de software tradicional, progresso se mede em funcionalidades entregues, linhas de código escritas, bugs corrigidos. Em um projeto de uma startup, essas métricas são ilusórias — Ries as chama de “métricas de vaidade” — porque não dizem nada sobre se a startup está se aproximando de um modelo de negócios viável. Uma startup que passou três meses construindo um produto complexo e polido, mas que ainda não o testou com um único usuário real, não progrediu em nenhum sentido relevante. Uma startup que passou o mesmo tempo testando três hipóteses diferentes, refutando duas delas e confirmando uma, progrediu imensamente — mesmo que o produto que ela tem ao final dos três meses seja uma apresentação de slides e uma planilha.
Isso é contraintuitivo, mas tem uma lógica poderosa: numa startup, o recurso mais escasso não é dinheiro, nem tempo, nem talento técnico. É conhecimento sobre o mercado. Todo o dinheiro, tempo e talento que você gasta antes de ter esse conhecimento é, em alguma medida, um desperdício potencial — porque você pode estar construindo algo que ninguém quer. Cada hipótese validada é, portanto, uma redução na incerteza que envolve o negócio, e redução de incerteza é exatamente o que uma startup precisa para sobreviver.
O MVP: o experimento mais barato para aprender o mais importante
O Produto Mínimo Viável é talvez o conceito do Lean Startup mais mal compreendido — e mais mal aplicado — na prática do empreendedorismo. Por isso, vale a pena definir o que ele é e o que ele não é com clareza.
O MVP não é a versão mais simples ou mais barata do produto final que a startup pretende construir. Esse é um mal-entendido muito comum que leva equipes a construir produtos incompletos e chamá-los de MVP quando na verdade são apenas protótipos ruins. Um MVP também não precisa ser um produto de software. Pode ser uma conversa, uma apresentação de slides, uma página de internet estática, um processo manual realizado por humanos, ou um vídeo explicando um produto que ainda não existe.
A definição correta é: o MVP é o menor experimento possível que permite testar a hipótese mais importante que a startup precisa validar naquele momento, ao menor custo e com a maior velocidade possível. O “mínimo” no nome não se refere à qualidade ou à completude do produto — refere-se ao mínimo de esforço necessário para gerar o aprendizado que a startup precisa.
Três exemplos históricos ilustram isso com elegância. O Dropbox, antes de ter qualquer código funcional de sincronização de arquivos na nuvem, precisava validar uma hipótese fundamental: as pessoas realmente queriam um serviço assim? Para testar isso sem construir o produto, o fundador Drew Houston gravou um vídeo de três minutos explicando como o Dropbox funcionaria — um produto que ainda não existia. Ele postou o vídeo em uma comunidade de tecnologia e, da noite para o dia, a lista de espera do produto saltou de cinco mil para setenta e cinco mil usuários. Essa foi a validação da hipótese de valor com praticamente zero custo de desenvolvimento.
A Zappos, pioneira no e-commerce de sapatos nos Estados Unidos, precisava validar se as pessoas comprariam sapatos online sem poder experimentá-los antes — algo que parecia improvável no início dos anos 2000. O fundador Nick Swinmurn não construiu nenhum sistema de e-commerce, nenhum armazém, nenhuma parceria com marcas. Ele simplesmente foi a lojas físicas de calçados, fotografou os produtos, publicou as fotos em um site rudimentar e, quando alguém fez um pedido, voltou à loja, comprou os sapatos pelo preço cheio e os enviou pelo correio. Era um modelo completamente não escalável e não lucrativo — mas era o menor experimento que permitia testar a hipótese central.
O Buffer, serviço de agendamento de postagens em redes sociais, usou uma landing page simples que descrevia o produto e apresentava dois planos de preço. Quando o usuário tentava comprar qualquer um dos planos, era informado de que o produto ainda não estava disponível e convidado a deixar seu email para ser notificado. A quantidade de emails cadastrados — e a proporção de usuários que clicaram no plano mais caro — deu ao fundador Joel Gascoigne informação suficiente para validar tanto a hipótese de valor quanto uma hipótese inicial sobre disposição a pagar.
Esses três casos têm em comum uma característica que você deve incorporar no projeto integrador: antes de construir qualquer coisa, pergunte-se qual é a hipótese que, se falsa, invalidaria o negócio — e pergunte-se qual é o menor experimento que permitiria testar essa hipótese.
Pivô versus perseverar: aprender a mudar de direção
O pivô é um dos conceitos mais importantes — e mais frequentemente romantizados — do vocabulário das startups. Na cultura popular do empreendedorismo, o pivô é frequentemente retratado como um momento de epifania em que o fundador abandona uma ideia ruim e tem uma ideia brilhante. Isso é uma simplificação enganosa.
Na definição de Ries, o pivô é uma mudança estruturada de direção que mantém um pé no que foi aprendido. A palavra “estruturada” é fundamental: um pivô não é uma reação impulsiva ao fracasso, nem uma mudança de ideia motivada por ansiedade ou pressão de investidores. É uma decisão deliberada, baseada em evidências coletadas no ciclo construir-medir-aprender, de que a hipótese atual não se sustenta e de que uma direção diferente tem mais chances de levar a um modelo de negócios viável.
Ries identifica vários tipos de pivô que uma startup pode fazer. O pivô de segmento de clientes ocorre quando o produto funciona, mas para um grupo de usuários diferente do que a startup havia imaginado originalmente. O pivô de problema acontece quando a startup descobre que o problema que ela havia identificado não é suficientemente grave ou frequente para sustentar um negócio, mas que, ao conversar com os usuários, identificou outro problema mais relevante que pode resolver. O pivô de canal ocorre quando o produto e o mercado estão certos, mas a forma de chegar ao usuário precisa mudar. O pivô de tecnologia acontece quando a startup descobre que pode resolver o mesmo problema com uma tecnologia diferente que apresenta vantagens de custo, escala ou performance. O pivô de modelo de receita ocorre quando o produto e o mercado estão certos, mas a forma de capturar valor economicamente precisa ser redesenhada.
Uma das histórias de pivô mais bem documentadas no setor de saúde digital é a da empresa norte-americana Flatiron Health. Fundada em 2012, ela começou como um marketplace de ensaios clínicos oncológicos — conectando pacientes com câncer a estudos clínicos disponíveis. Depois de meses tentando fazer esse modelo funcionar, os fundadores perceberam que o verdadeiro problema não era encontrar pacientes para os ensaios, mas organizar e estruturar dados clínicos de pacientes oncológicos, que estavam dispersos em prontuários de formatos incompatíveis em milhares de clínicas. Pivotaram para se tornar uma plataforma de dados oncológicos, foram adquiridos pela Roche em 2018 por 1,9 bilhão de dólares.
O contraponto do pivô é perseverar — a decisão de que a direção atual está correta e que o que falta é mais tempo e mais esforço de execução. A habilidade mais difícil no empreendedorismo de startup é distinguir entre os dois: quando os dados dizem que é hora de pivotar e quando dizem que é hora de perseverar. Essa decisão exige que a equipe seja honesta com os dados e evite o que Ries chama de “pivô por covardia” — mudar de direção simplesmente porque o progresso está lento, antes de ter evidências que justifiquem a mudança.
O paradoxo do sucesso precoce
Uma HealthTech que cresce rapidamente — que em poucos meses tem centenas de usuários entusiasmados, uma cobertura de imprensa positiva e uma rodada de investimento semente — pode estar em condição mais frágil do que uma HealthTech que cresce devagar e com metodologia.
O paradoxo do sucesso precoce funciona assim: quando uma startup cresce rápido antes de ter validado suas hipóteses fundamentais, ela constrói uma estrutura — equipe, contratos, obrigações com investidores, expectativas de usuários — que torna muito mais caro e doloroso mudar de direção quando o aprendizado finalmente aponta que uma mudança é necessária. O sucesso precoce pode ser um sinal de que a startup encontrou um nicho de “adotantes iniciais” entusiasmados que não são representativos do mercado mais amplo. Quando a startup tenta escalar além desse nicho e o crescimento estanca, ela está numa posição muito pior do que se tivesse crescido devagar e aprendido o que o mercado principal realmente quer.
Para uma HealthTech, esse paradoxo é ainda mais grave por razões que exploraremos em detalhe na seção sobre especificidades do setor saúde: os adotantes iniciais em saúde — médicos inovadores, gestores progressistas, pacientes altamente engajados — costumam ser muito mais tolerantes com problemas de produto e muito mais motivados a usar novas tecnologias do que a maioria do mercado. Uma startup que valida sua hipótese de valor apenas nesse grupo pode ter uma surpresa desagradável ao tentar expandir.
O que é uma HealthTech
Com a definição de startup estabelecida, é possível definir com precisão o que é uma HealthTech. A definição que utilizaremos neste curso é a seguinte: uma HealthTech é uma empresa nascente cujo produto ou serviço central aplica tecnologia digital, computacional ou biotecnológica à resolução de problemas em saúde, com modelo de negócio escalável e saúde como mercado primário.
Cada elemento dessa definição é deliberado e vale a pena desdobrá-lo.
“Empresa nascente” indica que estamos falando de startups, não de empresas estabelecidas. Uma grande farmacêutica que desenvolve um aplicativo de aderência medicamentosa para seus pacientes não se torna uma HealthTech — ela é uma empresa farmacêutica estabelecida que está adicionando um componente digital ao seu portfólio. O que distingue a HealthTech é a condição de startup: ela ainda está buscando seu modelo de negócios sob incerteza radical.
“Produto ou serviço central” indica que a tecnologia não é um acessório ou um canal de distribuição — ela é o núcleo do que a empresa oferece. Um médico que usa WhatsApp para se comunicar com pacientes não está criando uma HealthTech. Uma empresa que desenvolve um sistema de monitoramento remoto de pacientes cardíacos usando sensores e processamento de dados em tempo real está criando uma HealthTech porque a tecnologia é o produto.
“Saúde como mercado primário” distingue HealthTechs de empresas de tecnologia que prestam serviços para a área da saúde como um entre vários setores. Uma empresa de software de gestão empresarial que tem módulos para clínicas e hospitais entre seus clientes não é uma HealthTech — saúde é um segmento de mercado para ela, não o mercado principal. Uma empresa que desenvolveu um sistema específico de inteligência artificial para leitura de eletrocardiogramas, cujos clientes são exclusivamente serviços de cardiologia, é uma HealthTech.
As categorias de HealthTechs existentes
O campo das HealthTechs é amplo e heterogêneo. Conhecer as principais categorias ajuda a situar seu projeto no ecossistema e a entender com quais outros atores você vai interagir.
A telemedicina abrange empresas que facilitam a consulta médica e a prestação de cuidados à distância, seja por videoconferência, por chat ou por monitoramento remoto de sinais vitais. No Brasil, exemplos como a Teladoc (empresa norte-americana com operações no país) e plataformas como o iClinic e o Doctoralia têm expandido o acesso a consultas em regiões onde a oferta de especialistas é escassa. A regulamentação da telemedicina pelo CFM pela Resolução 2.314/2022 abriu um mercado significativo que antes operava em zona cinzenta legal.
A inteligência artificial diagnóstica é uma categoria de HealthTech que aplica algoritmos de aprendizado de máquina à análise de imagens médicas, dados laboratoriais, sinais de monitoramento e outros dados clínicos para apoiar ou automatizar diagnósticos. A empresa brasileira Norus Vascular, que usa IA para detecção de aneurismas intracranianos em imagens de tomografia, é um exemplo. A Dasa, embora não seja uma startup, tem investido pesadamente em IA diagnóstica. No ecossistema de startups, empresas como a Diagnósticos da América e a Lauduz têm explorado esse espaço.
Os wearables e sistemas de monitoramento contínuo são dispositivos usáveis ou implantáveis que coletam dados fisiológicos de forma contínua — frequência cardíaca, saturação de oxigênio, glicemia, padrões de sono, pressão arterial — e os transmitem para sistemas que os analisam e geram alertas ou recomendações. O mercado global de wearables em saúde cresceu exponencialmente com a popularização de smartwatches, mas há startups brasileiras focadas em nichos específicos, como monitoramento de pacientes crônicos em ambulatórios e terapia intensiva domiciliar.
A gestão de saúde crônica é uma categoria que engloba empresas focadas em ajudar pacientes com condições crônicas — diabetes, hipertensão, insuficiência cardíaca, DPOC — a gerenciar sua condição de forma mais eficaz, com menor taxa de internações e menor custo para o sistema de saúde. A empresa brasileira Cuco Health, focada em pacientes diabéticos, é um exemplo representativo dessa categoria. O modelo de negócio típico envolve contratos com planos de saúde que pagam pelo valor gerado em redução de custos.
A saúde mental digital é uma categoria que cresceu aceleradamente após a pandemia de COVID-19, com empresas oferecendo terapia por videoconferência, aplicativos de mindfulness e autorregulação emocional, triagem de saúde mental e plataformas de conexão entre pacientes e psicólogos. A Vittude e a Zenklub são exemplos brasileiros nessa categoria. A adesão de planos de saúde ao reembolso de sessões de terapia digital criou um modelo de receita mais claro para essa categoria nos últimos anos.
A biotecnologia de precisão abrange startups que desenvolvem diagnósticos moleculares, terapias baseadas em edição genética, sequenciamento genômico aplicado à clínica ou biofármacos desenvolvidos com tecnologias de biologia sintética. Essa é a categoria com ciclos mais longos de desenvolvimento e validação, pois envolve necessariamente testes clínicos controlados e aprovação regulatória rigorosa. No Brasil, empresas como a Oncobiológics e a Recepta Biopharma têm explorado esse campo.
Os sistemas de informação em saúde são startups que desenvolvem prontuários eletrônicos, sistemas de gestão clínica, plataformas de integração de dados de saúde e ferramentas de análise de dados populacionais. Empresas como a MV Sistemas, a Philips Tasy e startups como o Resultados Digitais em Saúde operam nesse espaço. Com a implantação da Rede Nacional de Dados em Saúde (RNDS), surgem oportunidades para startups que desenvolvam integrações e aplicações baseadas nos dados do SUS.
As especificidades das HealthTechs: por que saúde é diferente
Você já sabe o que é uma startup e o que é uma HealthTech. Agora é necessário entender por que construir uma HealthTech é diferente de construir uma startup em qualquer outro setor. Essa diferença não é apenas de grau — é de natureza. E compreendê-la com profundidade é o que distingue equipes que chegam ao final do semestre com projetos viáveis daquelas que constroem coisas belas mas ilegais, ou tecnicamente interessantes mas sem mercado.
As cinco especificidades estruturais das HealthTechs
O setor saúde apresenta cinco características estruturais que tornam o empreendedorismo nele fundamentalmente diferente de outros setores: regulação intensa e específica, ciclos longos de desenvolvimento e validação, multiplicidade de stakeholders com interesses divergentes, exigência de evidência clínica para adoção institucional, e assimetria de informação com responsabilidade clínica. Cada uma dessas características tem implicações diretas para o modelo de negócio, a estratégia de produto e a gestão do projeto.
Regulação: o mapa que você precisa antes de construir
O setor saúde é um dos mais regulados da economia brasileira, e essa regulação existe por razões legítimas e poderosas: intervenções em saúde, quando mal feitas, matam pessoas. A regulação não é um obstáculo burocrático a ser contornado — é um sistema de proteção que você, como futuro médico e potencial empreendedor em saúde, tem a obrigação ética e legal de respeitar e dominar.
A ANVISA, Agência Nacional de Vigilância Sanitária, é o principal órgão regulatório para HealthTechs que desenvolvem produtos com função diagnóstica, terapêutica ou de monitoramento. Sua missão é garantir que medicamentos, dispositivos médicos e softwares utilizados em contexto clínico sejam seguros e eficazes antes de chegarem ao mercado.
O conceito mais importante para HealthTechs de tecnologia digital é o de SaMD — Software as a Medical Device, ou Software como Dispositivo Médico. Um SaMD é qualquer software destinado a ser usado para uma ou mais finalidades médicas sem fazer parte de um dispositivo de hardware, podendo realizar essas finalidades de forma independente. Em termos práticos: um aplicativo que auxilia médicos a interpretar eletrocardiogramas é um SaMD. Um aplicativo que controla uma bomba de insulina é um SaMD. Um sistema de IA que gera recomendações de diagnóstico é um SaMD. Um aplicativo que apenas exibe informações de saúde sem tomar decisões diagnósticas ou terapêuticas pode não ser classificado como SaMD — mas essa classificação exige análise cuidadosa caso a caso.
A RDC 657/2022 da ANVISA estabeleceu o marco regulatório para SaMD no Brasil. Ela define quatro classes de risco para dispositivos médicos, incluindo softwares, e os requisitos regulatórios correspondentes a cada classe. A Classe I é para produtos de risco mínimo — o processo de registro é simplificado e pode ser feito por notificação. As Classes II, III e IV implicam processos progressivamente mais complexos, com exigências de documentação técnica, testes de segurança e, nas classes mais altas, estudos clínicos que demonstrem eficácia e segurança.
Para a sua HealthTech, a primeira pergunta regulatória a responder é: meu produto é um SaMD? Se sim, em qual classe de risco ele se enquadra? Responder a essa pergunta antes de começar a desenvolver o produto pode economizar anos de retrabalho e recursos que, de outra forma, seriam investidos num produto que não pode ser legalizado da forma como foi concebido.
O CFM, Conselho Federal de Medicina, exerce uma influência regulatória distinta da ANVISA: ele não regula produtos, mas a prática da medicina. Qualquer HealthTech que interfira na relação médico-paciente ou na prática clínica precisa entender como o CFM regula essa prática. A Resolução CFM 2.314/2022 é o marco regulatório vigente para a telemedicina no Brasil. Ela estabelece as condições em que consultas médicas podem ser realizadas à distância, os requisitos de segurança e privacidade de dados, e as responsabilidades do médico que utiliza ferramentas digitais. Para uma HealthTech de telemedicina, essa resolução define o que é possível fazer e o que é vedado — e ignorá-la significa operar em ilegalidade.
A ANS, Agência Nacional de Saúde Suplementar, regula os planos de saúde privados no Brasil e exerce uma influência significativa sobre os modelos de receita das HealthTechs. A tabela de procedimentos da ANS define o que os planos de saúde são obrigados a cobrir e como são remunerados os prestadores. Para uma HealthTech que queira ser remunerada por planos de saúde — seja diretamente, seja por meio de hospitais e clínicas credenciados — a ANS determina se o produto entra numa categoria de procedimento coberto, se precisa de regulamentação específica para ser incluído na tabela, e quais os critérios de eficácia que precisam ser demonstrados para justificar a cobertura.
A LGPD, Lei Geral de Proteção de Dados, Lei 13.709/2018, é a legislação que regula o tratamento de dados pessoais no Brasil e tem implicações diretas para qualquer HealthTech que colete, armazene, processe ou compartilhe dados de saúde. A lei define dados de saúde como dados sensíveis, uma categoria especial que recebe proteções reforçadas em comparação com dados pessoais comuns. O tratamento de dados sensíveis de saúde é permitido apenas em circunstâncias específicas previstas em lei — com o consentimento expresso do titular, por razões de saúde pública, por necessidade de tutela da saúde do titular — e exige medidas de segurança técnica e organizacional mais rigorosas.
Para a sua HealthTech, a LGPD não é apenas uma questão de conformidade legal: ela tem implicações diretas para a arquitetura do software, para os processos de coleta de consentimento do usuário, para as políticas de armazenamento e retenção de dados e para os contratos com fornecedores de infraestrutura em nuvem. Uma HealthTech que não contemple a LGPD desde o início do desenvolvimento vai encontrar, mais tarde, a necessidade de refatorar partes significativas do sistema para atender aos requisitos legais — um custo muito maior do que ter projetado o sistema corretamente desde o início.
Ciclos longos de desenvolvimento e validação
Uma das diferenças mais marcantes entre HealthTechs com produtos médicos regulados e startups de consumo é a duração do ciclo do conceito ao mercado. Uma startup de consumo — um aplicativo de produtividade, uma plataforma de e-commerce, um serviço de assinatura de conteúdo — pode ir do conceito ao lançamento em questão de meses. Uma HealthTech que desenvolve um dispositivo médico ou um software diagnóstico regulado pode levar de cinco a dez anos para percorrer o mesmo caminho.
Essa diferença existe porque a validação de um produto médico não é apenas validação de mercado — é validação clínica. Para demonstrar que um produto médico é seguro e eficaz, é necessário realizar estudos com pacientes reais, em condições controladas, com metodologia que permita distinguir os efeitos do produto dos efeitos de outras variáveis. Esses estudos precisam ser aprovados por comitês de ética em pesquisa, conduzidos por pesquisadores credenciados, analisados estatisticamente com rigor e publicados em periódicos científicos revisados por pares. O processo todo — da concepção do estudo à publicação dos resultados — raramente leva menos de dois ou três anos.
Depois da validação clínica, vem o processo regulatório com a ANVISA, que tem sua própria duração — meses para produtos de risco baixo, anos para dispositivos de risco alto. E depois da aprovação regulatória, ainda é preciso negociar a inclusão do produto na tabela da ANS ou conquistar contratos de compra com hospitais e operadoras de planos de saúde, processos que têm suas próprias inércias burocráticas.
Essas realidades têm implicações diretas para o seu projeto integrador: se você está desenvolvendo uma HealthTech com produto médico regulado, o MVP que você vai construir neste semestre não pode ser o produto final — ele será um protótipo ou uma prova de conceito que demonstra a viabilidade técnica e a relevância clínica do produto, mas que não está pronto para uso clínico. Isso não é uma limitação do projeto — é a realidade do setor, e reconhecê-la é parte essencial do pensamento estratégico que a disciplina busca desenvolver.
Múltiplos stakeholders com interesses divergentes
Em uma startup de consumo típica, o modelo de negócio é relativamente simples: o usuário é o cliente, o cliente é o pagador, e o produto precisa criar valor suficiente para que o pagador pague um preço que sustente o negócio. Em saúde, essa estrutura é sistematicamente mais complexa.
O usuário do produto é, frequentemente, o paciente — a pessoa cujo problema de saúde a HealthTech pretende resolver. Mas o paciente raramente é o decisor de compra e ainda mais raramente é o pagador direto. O decisor de compra em contexto hospitalar é tipicamente o diretor clínico, o coordenador médico da especialidade relevante ou o gestor de TI do hospital — cada um com critérios de avaliação diferentes: o clínico quer evidência de eficácia clínica, o gestor de TI quer integração com o sistema de prontuários existente e segurança de dados, o diretor financeiro quer demonstração de retorno sobre investimento. O pagador, por sua vez, é o plano de saúde, que quer evidência de redução de custos.
Essa estrutura é o que empreendedores experientes de saúde chamam de “venda de três cabeças”: você precisa convencer simultaneamente quem usa, quem paga e quem decide comprar — e esses três grupos têm linguagens, critérios e horizontes de tempo diferentes. Uma HealthTech que apenas demonstra que seu produto é tecnicamente sofisticado vai convencer o gestor de TI mas falhar com o clínico. Uma que mostra desfechos clínicos excelentes vai convencer o clínico mas não o gestor financeiro se não houver um business case claro.
Para o seu projeto integrador, entender essa estrutura significa que a resposta à pergunta “para quem estamos vendendo?” é sempre mais complexa do que parece. Quando você mapeia os usuários do seu produto, precisa mapear todos os stakeholders relevantes — pacientes, médicos, gestores, pagadores — e entender o que cada um deles quer, o que cada um teme e quem tem autoridade para bloquear ou autorizar a adoção do produto.
A exigência de evidência clínica
Em outros setores, prova social — muitos usuários satisfeitos, avaliações positivas, cobertura entusiasmada da imprensa especializada — é frequentemente suficiente para que compradores institucionais adotem um produto. Em saúde, isso não é suficiente. Compradores institucionais — hospitais, operadoras de planos, redes de atenção primária — exigem evidência clínica: estudos que demonstrem, com metodologia rigorosa, que o produto melhora desfechos de saúde de forma mensurável.
A hierarquia de evidências que você está aprendendo em outras disciplinas do curso é diretamente relevante aqui. No topo dessa hierarquia estão os ensaios clínicos randomizados e controlados, seguidos por revisões sistemáticas e meta-análises, estudos de coorte e estudos de caso-controle. Para uma HealthTech, construir uma base de evidências que suba progressivamente nessa hierarquia ao longo do tempo é um requisito competitivo — e regulatório — fundamental.
Isso não significa que você precisa ter um ensaio clínico randomizado antes de lançar seu produto. Mas significa que o roteiro de geração de evidências deve ser pensado desde o início. Quais são as métricas de desfecho que você vai medir? Qual será o design do estudo de validação? Com quais instituições você vai fazer parcerias para conduzir esses estudos? Essas perguntas precisam ter respostas preliminares antes de você ter um produto no mercado — porque são elas que vão determinar se você consegue vender para compradores institucionais daqui a dois ou três anos.
Assimetria de informação e responsabilidade clínica
A relação médico-paciente é estruturalmente assimétrica no que diz respeito ao conhecimento: o médico tem um conjunto de conhecimentos especializados sobre a saúde do paciente que o próprio paciente não tem acesso sem mediação. Essa assimetria é a base da autoridade profissional da medicina e, ao mesmo tempo, a fonte de sua responsabilidade ética e legal.
Quando uma HealthTech interfere nessa relação — recomendando condutas clínicas, gerando diagnósticos, modificando comportamentos de saúde, intermediando a comunicação entre médico e paciente — ela assume parte da responsabilidade que antes pertencia exclusivamente ao médico. Essa responsabilidade tem dimensões legais, éticas e práticas que precisam ser anticipadas desde o design do produto.
Do ponto de vista legal, a responsabilidade civil médica no Brasil é regulada tanto pelo Código Civil quanto pelo Código de Defesa do Consumidor. Um software que gera um diagnóstico incorreto e que esse diagnóstico leva a uma conduta inadequada que causa dano ao paciente pode gerar responsabilidade não apenas para o médico que usou o software, mas para a empresa que o desenvolveu. Entender os limites entre apoio à decisão clínica — onde a responsabilidade permanece com o médico — e substituição da decisão clínica — onde a responsabilidade pode ser compartilhada ou transferida — é uma questão de design que tem implicações legais diretas.
Do ponto de vista ético, você precisa antecipar situações de conflito de interesse: quando os dados que sua HealthTech coleta são usados por planos de saúde para negar cobertura a pacientes de alto risco? Quando um algoritmo de triagem sistematicamente subestima a gravidade de apresentações clínicas atípicas em grupos étnicos sub-representados nos dados de treinamento? Quando a conveniência tecnológica do seu produto substitui o contato humano em situações em que esse contato é terapeuticamente importante?
Essas perguntas não têm respostas simples, mas precisam ser feitas desde o início do projeto. A HealthTech que começa pensando em como maximizar engajamento de usuários sem considerar as implicações éticas dessa maximização em contextos de saúde está construindo sobre uma fundação frágil.
O ecossistema de saúde digital no Brasil
Construir uma HealthTech no Brasil significa operar num contexto específico — econômico, demográfico, regulatório e tecnológico — que cria tanto oportunidades únicas quanto desafios particulares. Conhecer esse contexto não é apenas uma curiosidade acadêmica: é uma vantagem competitiva para quem está desenvolvendo um projeto nesse espaço.
O mercado de saúde brasileiro
O mercado de saúde no Brasil é um dos maiores do mundo em termos absolutos. O setor representa aproximadamente dez por cento do Produto Interno Bruto nacional, o que o coloca entre os maiores consumidores de recursos da economia. Esse tamanho cria oportunidades de negócio significativas — mas também cria inércias institucionais e complexidades burocráticas que tornam a entrada de novas empresas difícil.
Três tendências estruturais criam oportunidades específicas para HealthTechs no Brasil. A primeira é o envelhecimento populacional: o Brasil está em transição demográfica acelerada, com crescimento expressivo da população acima de sessenta anos nas próximas décadas. Populações mais velhas têm maior prevalência de doenças crônicas, maior utilização de serviços de saúde e maior necessidade de cuidados continuados — todas áreas em que HealthTechs de monitoramento, gestão de crônicos e coordenação de cuidados têm propostas de valor claras.
A segunda tendência é o aumento da prevalência de doenças crônicas não transmissíveis — diabetes tipo 2, hipertensão arterial, doença cardiovascular aterosclerótica, doença pulmonar obstrutiva crônica — que representam a maior parte da carga de doença no Brasil e o maior componente dos custos do sistema de saúde. Essas condições são altamente manejáveis com acompanhamento contínuo e modificação de comportamento — exatamente o que tecnologias digitais podem facilitar de forma escalável.
A terceira tendência é a escassez de especialistas em regiões remotas. O Brasil tem uma distribuição geográfica extremamente desigual de profissionais de saúde: especialistas se concentram nas capitais e nas cidades de médio e grande porte do Sul e Sudeste. Regiões do Norte, Nordeste e Centro-Oeste têm carências severas de especialidades como cardiologia, neurologia, oncologia e psiquiatria. Para HealthTechs de telemedicina e telessaúde, essa desigualdade geográfica é uma oportunidade de alto impacto.
A estrutura mista do sistema de saúde
O Brasil tem um sistema de saúde que combina um sistema público universal — o SUS — com um setor de saúde suplementar (planos de saúde privados) e um mercado de desembolso direto. Cada um desses segmentos tem características, oportunidades e desafios específicos para HealthTechs.
O SUS cobre, em teoria, cem por cento da população brasileira e é o principal comprador de serviços de saúde do país. Em termos de escala, nenhum outro pagador se compara. Uma HealthTech que consegue integrar seus produtos e serviços ao SUS tem acesso potencial a duzentos e quinze milhões de beneficiários. No entanto, o ciclo de compras do SUS é longo, burocrático e frequentemente sujeito a descontinuidades políticas. O processo de incorporação de novas tecnologias ao SUS passa pela CONITEC, Comissão Nacional de Incorporação de Tecnologias no SUS, que avalia evidências de efetividade, segurança e impacto orçamentário — um processo que pode levar anos.
A saúde suplementar cobre aproximadamente vinte e cinco por cento da população brasileira, concentrada nas faixas de renda média e alta. As operadoras de planos de saúde são compradores mais ágeis do que o SUS e têm incentivos econômicos claros para adotar tecnologias que reduzam custos de sinistralidade. Uma HealthTech que demonstra redução de internações ou de uso de serviços de alta complexidade tem um business case poderoso para operadoras de planos. O desafio é que a concentração do mercado de planos em poucos grandes operadores — como Bradesco Saúde, SulAmérica, Amil, Hapvida — significa que as negociações são com compradores muito maiores e mais poderosos do que a startup, o que cria assimetria de poder contratual.
O mercado de desembolso direto — pacientes que pagam do próprio bolso por serviços de saúde que o plano não cobre ou que preferem não passar pelo sistema — é menos regulado e mais ágil, mas mais limitado em escala para HealthTechs que precisam de volume para viabilizar o negócio.
A digitalização do SUS
O governo federal brasileiro tem investido sistematicamente na digitalização da infraestrutura de dados de saúde pública. Três iniciativas merecem atenção especial para HealthTechs.
O Prontuário Eletrônico do Cidadão, desenvolvido no âmbito da Estratégia de Saúde Digital do Ministério da Saúde, é um sistema de registro eletrônico para a atenção primária do SUS. Ele está sendo implantado progressivamente em Unidades Básicas de Saúde em todo o país e representa uma fonte de dados estruturados sobre a população atendida na atenção primária que antes simplesmente não existia de forma acessível.
A Rede Nacional de Dados em Saúde é a infraestrutura de interoperabilidade que permite que dados de saúde fluam de forma segura entre diferentes sistemas e instituições. Ela usa padrões internacionais de interoperabilidade em saúde — como o HL7 FHIR — para garantir que prontuários, resultados de exames e registros de imunização possam ser acessados pelo profissional de saúde autorizado em qualquer ponto da rede. Para HealthTechs, a RNDS representa uma oportunidade de integrar seus produtos ao ecossistema de dados do SUS e acessar dados populacionais de grande escala para treinamento de modelos de IA ou análise epidemiológica.
O ConecteSUS é o aplicativo cidadão do Ministério da Saúde que dá ao paciente acesso ao seu histórico de atendimentos no SUS, resultados de exames, cartão de vacinas e outros registros. Ele é uma interface de dados de saúde diretamente nas mãos dos cidadãos — e representa uma oportunidade para HealthTechs que desenvolvem produtos orientados ao paciente integrar-se a esse ecossistema.
Como escolher um problema: o começo de tudo
A escolha do problema que o seu grupo vai tentar resolver é a decisão mais importante que vocês tomarão neste módulo — possivelmente a mais importante de todo o projeto integrador. Ela vai condicionar tudo o que vem depois: o mercado que vocês vão explorar, as hipóteses que vão testar, os usuários com quem vão conversar, as tecnologias que vão utilizar, o modelo de negócio que vão desenvolver. É uma decisão que merece muito mais atenção e cuidado do que usualmente recebe.
A armadilha da solução à procura de problema
A maioria dos grupos de estudantes — e, diga-se, de empreendedores iniciantes — começa pelo lugar errado: pela tecnologia ou pela solução, em vez de pelo problema. “Vamos fazer um aplicativo de inteligência artificial para triagem de sintomas.” “Vamos criar uma plataforma de telemedicina para especialistas.” “Vamos usar blockchain para proteger dados de pacientes.” Essas frases descrevem soluções tecnológicas que ainda não têm um problema específico e validado por trás delas.
O problema com essa abordagem é preciso: a tecnologia não define o mercado, nem o valor, nem o modelo de negócio. O problema define. Uma startup que começa pela tecnologia está apostando que, ao construir a solução, vai encontrar o problema certo para ela — uma estratégia que é o inverso do que o Lean Startup recomenda. Em vez de partir de uma hipótese sobre o problema e construir o menor experimento que valide essa hipótese, ela está partindo de uma solução e tentando encontrar um problema que se encaixe nela.
Isso gera um viés cognitivo poderoso e difícil de resistir: a tendência de interpretar qualquer evidência de problema de saúde como uma confirmação de que a sua solução é necessária. Um grupo que decidiu “fazer IA para diagnóstico” vai encontrar, em qualquer conversa com médicos, alguma menção a dificuldades diagnósticas e vai interpretar isso como validação. Mas dificuldades diagnósticas são ubíquas em medicina — elas não validam especificamente a solução de IA que o grupo tem em mente. Para validar a solução, é preciso primeiro caracterizar precisamente o problema: qual dificuldade diagnóstica específica, em qual especialidade, em qual contexto clínico, com qual frequência, com qual consequência para o paciente.
O papel da observação e da experiência vivida
Os melhores problemas para uma startup são aqueles que o fundador conhece por dentro — porque viveu, porque observou de perto ou porque investigou sistematicamente. Esse princípio tem um nome no vocabulário do empreendedorismo: founder-problem fit, o match entre o fundador e o problema que ele quer resolver.
O founder-problem fit importa por razões práticas e profundas. Na dimensão prática: um fundador que conhece profundamente o problema que está tentando resolver vai formular hipóteses mais precisas, vai identificar os usuários certos para entrevistar, vai reconhecer mais rapidamente quando uma solução está no caminho certo ou errado. Na dimensão mais profunda: construir uma startup é difícil, longo e frequentemente frustrante. Os fundadores que persistem quando tudo dá errado são quase sempre aqueles que se importam visceralmente com o problema que estão tentando resolver — não apenas com a tecnologia que escolheram para resolvê-lo.
Para você, estudante de medicina no terceiro semestre, o founder-problem fit tem uma dimensão muito específica: você está começando a observar o sistema de saúde por dentro, com os olhos de alguém que vai trabalhar nele. Cada experiência clínica que você tem — em ambulatórios, em pronto-socorros, em visitas técnicas — é uma oportunidade de observar problemas que passam despercebidos para pessoas de fora do sistema. Quais são os processos que parecem desnecessariamente ineficientes? Quais são as informações que os médicos precisam e que não estão disponíveis no momento certo? Quais são os pacientes que o sistema falha em alcançar ou em cuidar adequadamente? Quais são os erros que se repetem porque não existe um sistema melhor?
Essas observações — construídas a partir de sua experiência em formação, dos relatos de médicos e pacientes que você encontra, dos casos que discute em aulas e internatos — são a matéria-prima do problema que o seu grupo vai escolher resolver. Não subestime o valor de perguntar “por que funciona assim?” toda vez que algo no sistema de saúde parecer não fazer sentido.
Como articular um problema de forma estruturada
Há uma diferença enorme entre um problema vaguamente enunciado e um problema bem articulado. Essa diferença não é meramente estética — ela tem consequências práticas imediatas para a qualidade do trabalho que você vai fazer.
Um problema vaguamente enunciado soa assim: “pacientes têm dificuldade de acessar serviços de saúde” ou “médicos têm muita burocracia” ou “o sistema de saúde não é eficiente”. Esses enunciados são verdadeiros, mas são tão genéricos que não ajudam a identificar qual usuário específico o grupo vai entrevistar, qual produto poderia resolver o problema, qual seria o mercado-alvo ou como medir se o problema foi resolvido.
Um problema bem articulado tem quatro componentes. O primeiro é um usuário específico: não “pacientes em geral”, mas “idosos acima de setenta anos com insuficiência cardíaca acompanhados em ambulatório de cardiologia em cidades do interior”. O segundo é uma situação concreta: não “na área da saúde”, mas “durante a fase de descompensação inicial, quando os sinais de piora ainda são sutis e o paciente está em casa”. O terceiro é uma dificuldade ou dor identificável: não “poderia ser melhor”, mas “o paciente frequentemente não reconhece os sinais de alerta de descompensação precoce — ganho de peso de mais de dois quilos em três dias, dispneia progressiva, edema de membros inferiores crescente — até que já está em descompensação grave e precisa ser internado”. O quarto é uma dimensão de consequência: “isso resulta em hospitalizações de emergência evitáveis, com alta mortalidade intra-hospitalar, alto custo para o sistema e piora irreversível da função cardíaca do paciente”.
Compare os dois enunciados: “pacientes têm dificuldade de acessar serviços de saúde” versus “idosos com insuficiência cardíaca acompanhados em ambulatório frequentemente são hospitalizados em emergência por descompensação que poderia ter sido detectada e tratada de forma ambulatorial se o paciente tivesse reconhecido os sinais de alerta nos dias anteriores”. O segundo enunciado aponta para um usuário específico (idoso, insuficiência cardíaca, acompanhamento ambulatorial), para um momento específico (fase pré-hospitalar de descompensação), para um mecanismo de falha específico (não reconhecimento dos sinais de alerta) e para uma consequência mensurável (hospitalização de emergência evitável). A partir desse enunciado, é possível imaginar hipóteses de solução — um sistema de monitoramento de peso e sintomas com alertas automáticos, uma ferramenta de educação do paciente sobre sinais de alarme, um protocolo de teleatendimento de urgência —, identificar os usuários para entrevistar, e definir métricas de desfecho.
O que não escolher
Alguns tipos de problema devem ser evitados, não porque sejam desinteressantes, mas porque tornam o projeto inviável dentro do contexto deste semestre.
Problemas que dependem de regulamentação inexistente criam risco regulatório intransponível no curto prazo. Se a sua solução depende de que a ANVISA crie uma nova categoria regulatória, ou de que o CFM permita uma prática clínica que ainda não foi regulamentada, ou de que a ANS cubra um tipo de serviço que hoje não está na tabela, o projeto pode ser intelectualmente interessante mas não executável.
Problemas que já têm soluções consolidadas e bem distribuídas não justificam uma nova startup, a menos que o grupo tenha uma vantagem competitiva clara. Se o problema que vocês identificaram já tem cinco empresas bem estabelecidas oferecendo soluções de qualidade, a pergunta não é “como fazemos o mesmo?” mas “por que a solução existente não resolveu completamente o problema?” — e a resposta a essa pergunta pode apontar para um espaço ainda inexplorado.
Problemas muito grandes para um semestre — “resolver a falta de médicos no Brasil”, “eliminar as desigualdades de acesso à saúde” — são problemas reais e importantes, mas não são problemas que um grupo de estudantes resolve em quinze semanas. O escopo precisa ser suficientemente pequeno para que seja possível avançar de forma mensurável dentro do tempo disponível.
Problemas que nenhum membro do grupo tem contato real criam um obstáculo de empatia que é difícil de superar. Se ninguém no grupo já teve qualquer experiência — como paciente, como familiar, como observador em contexto clínico, como voluntário em serviço de saúde — com o problema escolhido, o grupo vai depender inteiramente de pesquisa secundária para entender o usuário. Isso não é impossível, mas torna o projeto mais frágil.
O canvas de hipóteses: pensando sob incerteza
O canvas de hipóteses é a ferramenta central do trabalho que você vai realizar neste módulo. Ele é simples na forma — um conjunto de colunas que organizam o que o grupo sabe e o que o grupo supõe — mas poderoso na função: ele força a equipe a ser explícita sobre o grau de certeza de cada crença que ela tem sobre o problema, o usuário e a solução.
O que é o canvas de hipóteses
O canvas de hipóteses é um documento vivo — não um relatório final, mas um artefato de trabalho que a equipe vai revisar e atualizar ao longo de todo o semestre à medida que acumula aprendizado. Ele tem uma função primária: separar o que é fato verificado do que é hipótese — crença que o grupo tem mas que ainda não foi testada com dados reais.
Essa separação é mais difícil do que parece. A tendência cognitiva natural de qualquer grupo é tratar suas crenças como fatos — especialmente quando essas crenças são compartilhadas por todos os membros do grupo. Se cinco pessoas no grupo acreditam que “médicos gostariam de uma ferramenta de triagem mais rápida”, essa crença pode parecer tão óbvia e compartilhada que o grupo para de tratá-la como hipótese e começa a tratá-la como premissa sobre a qual construir. Mas “médicos gostariam de uma ferramenta de triagem mais rápida” é uma hipótese: ela pode ser verdadeira, pode ser parcialmente verdadeira ou pode ser falsa — e só se sabe depois de conversar com médicos reais em contextos reais.
O canvas de hipóteses combate essa tendência ao criar uma distinção visual e explícita entre o que está verificado e o que está suposto. Isso não é apenas metodologicamente correto — é psicologicamente libertador, porque diz ao grupo que é normal e esperado não saber muita coisa neste ponto do projeto. A questão não é ter certeza: é ser transparente sobre o que sabe e o que supõe, e ter um plano para transformar hipóteses em conhecimento.
A distinção entre fatos e hipóteses
Entender a diferença entre um fato e uma hipótese é fundamental para usar o canvas corretamente. Um fato é uma afirmação sobre o mundo que pode ser verificada com dados existentes e que, quando verificada, confirma-se como verdadeira com uma probabilidade alta o suficiente para fundamentar decisões. Uma hipótese é uma crença que o grupo tem sobre como o mundo funciona, mas que ainda não foi verificada com dados suficientes para ser considerada confiável.
Considere um exemplo. “Pacientes diabéticos têm dificuldade de controlar a glicemia” é um fato verificável: há dados epidemiológicos brasileiros abundantes que demonstram que a maioria dos diabéticos não atinge as metas glicêmicas recomendadas. Esse é um ponto de partida sólido para a articulação de um problema.
“Pacientes diabéticos prefeririam usar um aplicativo de monitoramento a um caderno de anotações” é uma hipótese: o grupo pode ter essa intuição com base em sua experiência como usuário de tecnologia, mas não tem dados que demonstrem que diabéticos, especificamente — com suas características demográficas, nível de letramento digital e contexto clínico específicos — preferem um aplicativo. Pode ser verdade. Pode ser que uma parte dos diabéticos prefira, mas outra parte não. Pode ser que diabéticos idosos prefiram fortemente o caderno e que diabéticos jovens prefiram o aplicativo. É uma hipótese que precisa ser testada.
“Um aplicativo de monitoramento melhoraria o controle glicêmico de pacientes diabéticos que o usassem” é uma hipótese ainda mais arriscada — porque ela pressupõe que o aplicativo seria usado de forma consistente, que os dados registrados seriam precisos, que os alertas e recomendações gerados seriam acionáveis e clinicamente adequados, que os médicos saberiam interpretar os dados gerados e ajustar o tratamento em função deles. Cada uma dessas premissas é uma hipótese adicional. O grupo que confunde essa afirmação com um fato vai construir um produto complexo baseado num conjunto de suposições que pode desmoronar quando qualquer uma delas for testada com usuários reais.
As três colunas do canvas
O canvas que você vai preencher neste módulo tem três colunas, cada uma correspondendo a um domínio de hipóteses que o grupo precisa articular.
A primeira coluna é o que acreditamos sobre o problema. Aqui o grupo registra suas hipóteses sobre qual é o problema que está tentando resolver, com que frequência ele ocorre, quão grave é para os afetados, quem é afetado por ele e quais são suas causas principais. É importante ser específico: em vez de “o problema é o acesso à saúde”, o grupo deve articular qual aspecto específico do acesso, em qual população, em qual momento do cuidado, com quais causas identificáveis. Cada afirmação nessa coluna deve ser marcada como “verificado” ou “hipótese”, e as hipóteses devem ser acompanhadas de uma nota sobre como o grupo pretende testá-las.
A segunda coluna é o que acreditamos sobre o usuário. Aqui o grupo registra suas hipóteses sobre quem são as pessoas afetadas pelo problema — não apenas os dados demográficos, mas a jornada que essas pessoas percorrem ao lidar com o problema, o que as impede de resolver o problema por conta própria, quais tentativas de solução elas já fizeram e por que essas tentativas não foram suficientes, quais são seus objetivos e medos em relação ao problema. Essa coluna é a que mais frequentemente está cheia de hipóteses não verificadas — e é a que mais se beneficia de entrevistas com usuários reais.
A terceira coluna é o que acreditamos sobre a solução. Aqui o grupo registra suas hipóteses sobre o que seria uma solução viável para o problema identificado: como ela funcionaria, quais tecnologias utilizaria, como seria entregue ao usuário, por que seria melhor do que as alternativas existentes, qual seria o modelo de negócio que a sustentaria. Esta é a coluna que deve ser preenchida por último e com mais cautela — porque as hipóteses sobre a solução só fazem sentido depois que as hipóteses sobre o problema e o usuário foram suficientemente desenvolvidas.
Como priorizar hipóteses: encontrando a mais arriscada
Nem todas as hipóteses têm o mesmo nível de risco. A hipótese mais arriscada é aquela que, se falsa, invalida todo o negócio — é o pressuposto fundamental sobre o qual toda a lógica do projeto repousa. Identificar essa hipótese e priorizá-la para teste antes de qualquer outra é uma das práticas mais importantes do Lean Startup.
Para identificar a hipótese mais arriscada, o grupo deve fazer a seguinte pergunta para cada hipótese listada no canvas: “se essa hipótese for falsa, o projeto ainda faz sentido?”. A hipótese para a qual a resposta for “não” de forma mais clara e definitiva é a mais arriscada. Em geral, ela é uma hipótese sobre o problema — se o problema que o grupo identificou não existe da forma como o grupo imagina, ou não é tão grave ou frequente quanto o grupo supõe, ou não afeta o grupo de usuários que o grupo identificou, então qualquer solução que o grupo construa será irrelevante, independentemente de quão elegante seja tecnicamente.
Um exemplo: um grupo está desenvolvendo um sistema de lembretes automáticos para pacientes com hipertensão tomarem sua medicação. A hipótese mais arriscada pode ser que a principal causa de descontrole hipertensivo na população-alvo seja a não aderência à medicação — porque se a causa principal for outra (efeitos adversos que fazem o paciente abandonar a medicação, falta de acesso a medicamentos, ausência de seguimento médico regular, resistência aos medicamentos disponíveis), então um sistema de lembretes não vai resolver o problema, por melhor que seja tecnicamente. Essa hipótese precisa ser testada antes de qualquer desenvolvimento de produto.
Formação e dinâmica da equipe
Uma HealthTech não é construída por indivíduos isolados — é construída por equipes. A qualidade da equipe, a clareza de seus objetivos comuns e a saúde de sua dinâmica de colaboração são, segundo praticamente todos os investidores e empreendedores experientes, o fator mais importante para o sucesso ou fracasso de uma startup em seus estágios iniciais. Isso é especialmente verdadeiro num projeto de semestre, onde o tempo é escasso e a capacidade de aprender rápido e trabalhar junto determina o quanto o grupo avança.
Por que diversidade de perfis gera projetos mais ricos
Equipes homogêneas — grupos de pessoas com formações similares, experiências parecidas e visões de mundo alinhadas — são mais fáceis de gerenciar e mais confortáveis para seus membros. Mas elas produzem projetos mais pobres do que equipes diversas, e a razão é direta: problemas complexos em saúde exigem perspectivas múltiplas para serem compreendidos plenamente.
Uma HealthTech que tenta melhorar o cuidado de pacientes com doença renal crônica em diálise precisa de alguém que compreenda a experiência do paciente em sessões de hemodiálise; alguém que entenda a logística e os sistemas de informação de uma clínica de diálise; alguém que saiba construir ou ao menos especificar sistemas digitais; e alguém que consiga pensar sobre o modelo de negócio e como a solução vai ser sustentável economicamente. Nenhuma dessas perspectivas sozinha é suficiente, e as tensões entre elas — o que parece ideal para o paciente pode não ser viável economicamente; o que parece simples do ponto de vista técnico pode ser clinicamente inadequado — são fontes de aprendizado que tornam o projeto mais robusto.
A diversidade também significa diversidade de estilos cognitivos: pessoas que pensam de forma muito analítica e rigorosa, pessoas que pensam de forma criativa e associativa, pessoas que são naturalmente avessas a risco e buscam validação antes de avançar, pessoas que são naturalmente mais propensas a experimentar e aceitar ambiguidade. Essas diferenças criam tensão — mas é uma tensão produtiva quando bem gerenciada.
As funções que uma equipe de startup de saúde precisa cobrir
Toda startup de saúde funcional precisa cobrir quatro grandes funções, independentemente de quantas pessoas compõem a equipe. Essas funções podem ser desempenhadas por pessoas diferentes ou, em equipes pequenas, acumuladas por um mesmo membro com perfil híbrido.
A função de domínio clínico é desempenhada por quem tem ou busca ativamente o conhecimento sobre o problema de saúde que a startup está tentando resolver: como funciona a doença, como os profissionais de saúde a gerenciam hoje, quais são as limitações das abordagens existentes, quais são os padrões clínicos que a solução precisa respeitar. Em uma equipe de estudantes de medicina, pelo menos um membro deve assumir explicitamente essa função — e deve ser o membro que mais se aprofundará nas entrevistas com médicos e pacientes.
A função técnica é desempenhada por quem tem ou desenvolve habilidade de especificar e construir soluções tecnológicas: entender o que é viável tecnicamente, como sistemas de software funcionam, o que é necessário para integrar com sistemas existentes de prontuário ou com a infraestrutura da RNDS, como dados de saúde devem ser estruturados e protegidos. Em uma equipe de estudantes de medicina sem formação técnica, essa função pode ser parcialmente suprida por consultores externos ou por aprendizado intensivo — mas alguém precisa ser o ponto focal.
A função de empatia com o usuário é desempenhada por quem tem sensibilidade para observar e articular como o usuário final — paciente, médico, gestor — experimenta o problema e como experimentaria a solução. Essa função está no coração das metodologias de design thinking que vocês estudarão nos módulos 9 e 10, e é frequentemente a que determina se o produto final é algo que as pessoas realmente querem usar.
A função de gestão e organização é desempenhada por quem mantém o projeto em movimento: garante que entregas sejam feitas no prazo, que decisões sejam tomadas e documentadas, que o grupo tenha rituais de trabalho produtivos e que os conflitos internos sejam endereçados antes de se tornarem paralisantes. Essa função é frequentemente subestimada em equipes de estudantes, com resultados previsíveis: projetos que derivam, entregas que chegam tarde e grupos que se fragmentam por ausência de coordenação.
Como distribuir responsabilidades sem criar hierarquias rígidas
Startups bem-sucedidas raramente têm hierarquias rígidas de comando nos estágios iniciais. A razão é prática: em condições de incerteza radical, a tomada de decisão centralizada é lenta demais e frequentemente mal-informada, porque o fundador no topo da hierarquia frequentemente tem menos informação relevante do que as pessoas que estão em contato direto com usuários ou com problemas técnicos específicos.
A solução mais comum é a distinção entre responsabilidade por entregas e participação nas decisões coletivas. Cada membro assume responsabilidade primária por um domínio de trabalho — a entrega de pesquisa com usuários, a especificação técnica do MVP, a apresentação do canvas atualizado ao professor — mas as decisões estratégicas que afetam o projeto como um todo são tomadas coletivamente, com cada membro contribuindo com sua perspectiva.
Para o projeto integrador deste semestre, recomendo que o grupo defina, já nesta aula, quem é o responsável por cada uma das quatro funções descritas acima — e que esse acordo seja documentado. Não porque as fronteiras entre funções sejam rígidas, mas porque a ausência de qualquer designação clara de responsabilidade leva invariavelmente a uma situação em que todos assumem que alguém está cuidando de cada função e, na prática, ninguém está.
Gestão de conflitos em equipes de projeto
Conflitos em equipes de startup são normais, previsíveis e, quando bem gerenciados, produtivos. O que distingue equipes que transformam conflito em progresso daquelas que deixam o conflito paralisar o projeto é, fundamentalmente, a clareza sobre o que está em conflito e a capacidade de separar o debate sobre ideias do julgamento sobre pessoas.
Os conflitos mais comuns em projetos de startup de estudantes são de três tipos. Conflitos sobre o problema a escolher ocorrem quando membros do grupo têm intuições diferentes sobre qual problema merece ser perseguido — geralmente porque cada um tem experiências diferentes que apontam para problemas diferentes. Esses conflitos são produtivos: eles forçam o grupo a articular mais claramente o que torna um problema relevante e por que o problema escolhido merece prioridade. A solução não é votar — é usar critérios explícitos de avaliação (gravidade, frequência, tamanho de mercado, founder-problem fit) para comparar as alternativas de forma sistemática.
Conflitos sobre a solução ocorrem quando membros do grupo têm visões diferentes de como o problema deve ser resolvido. Esses conflitos são especialmente perigosos quando surgem antes de o grupo ter validado o problema com usuários reais — porque são essencialmente conflitos sobre hipóteses não testadas, e o vencedor do conflito não é necessariamente quem tem razão, mas quem tem mais carisma ou mais persistência. A solução é disciplina metodológica: antes de debater qual solução é melhor, o grupo deve verificar se o problema que as soluções estão tentando resolver foi adequadamente validado.
Conflitos sobre distribuição de trabalho ocorrem quando membros do grupo sentem que a carga está distribuída de forma injusta. Esses conflitos são os mais destrutivos para a dinâmica da equipe porque envolvem questões de reciprocidade e confiança que são difíceis de restaurar quando quebradas. A solução é preventiva: acordar explicitamente, no início do projeto, quem é responsável por quê — e criar rituais de revisão periódica em que o grupo avalia coletivamente se a distribuição está funcionando.
O primeiro passo: o que fazer neste módulo
Você chegou ao final do conteúdo teórico deste módulo. Agora é hora de traduzir o que aprendeu em ação — e a ação começa na aula desta semana.
O que acontecerá na aula
Os primeiros trinta minutos da aula serão de exposição pelo professor, retomando os pontos mais importantes deste material e respondendo às dúvidas que surgiram durante o seu estudo prévio. Aproveite esse tempo para trazer as perguntas que ficaram abertas depois de estudar este material — não as que você não entendeu por falta de atenção, mas as genuínas, as que mostram que você pensou sobre o conteúdo e encontrou algo que merece aprofundamento.
Os cento e setenta minutos seguintes serão de trabalho em grupo. Você e seus colegas realizarão três tarefas sequenciais nesse tempo: a formação dos grupos definitivos, a escolha do domínio de problema e o preenchimento do canvas inicial de hipóteses.
A formação dos grupos é o primeiro passo e precisa acontecer rapidamente. Grupos de cinco ou seis pessoas, com a maior diversidade de perfis possível. Depois de formado o grupo, escolham um facilitador para a sessão — não um líder permanente, mas alguém responsável por manter a energia e o foco durante a aula.
A escolha do domínio de problema é o segundo passo. Neste momento, vocês não precisam ter um problema completamente articulado — precisam convergir para um domínio amplo de saúde no qual o grupo tem interesse genuíno e algum contato com a realidade. “Doenças crônicas em atenção primária” é um domínio. “Saúde mental em estudantes universitários” é um domínio. “Cuidado paliativo em domicílio” é um domínio. A articulação precisa do problema virá depois, nos módulos de design thinking.
O preenchimento do canvas inicial de hipóteses é o terceiro passo. Com o domínio escolhido, o grupo preenche as três colunas com o que acredita saber e com o que está supondo. Marque claramente o que é fato verificado e o que é hipótese. Seja honesto sobre o que não sabe.
Como estudar este material de forma ativa
Estudar material didático de forma passiva — ler, sublinhar, reler — é uma estratégia de baixa eficácia que a neurociência da aprendizagem documentou extensivamente. Para absorver o conteúdo deste módulo de forma que seja útil para o projeto integrador, você precisa estudar de forma ativa.
Isso significa fazer perguntas ao material enquanto lê, não depois. “Essa definição de startup se aplicaria à clínica de saúde mental digital que vi mencionada no Instagram semana passada?” “A Lean Startup foi pensada para startups de software — como seus princípios se adaptam para uma HealthTech que desenvolve um dispositivo médico físico?” “O que significa, na prática, que dados de saúde são dados sensíveis na LGPD — o que isso implicaria para o tipo de aplicativo que o meu grupo está pensando?”
Significa também relacionar o conteúdo com sua experiência clínica em formação. Cada conceito deste módulo tem uma contraparte na realidade que você está observando: a assimetria de informação médico-paciente que você viu no ambulatório, o problema de adesão medicamentosa que o professor mencionou na aula de farmacologia, a dificuldade de acesso a especialistas que um familiar ou conhecido enfrentou. Conectar o conceitual com o concreto é o que transforma leitura em aprendizado durável.
O que o professor esperará ver no canvas entregue
O canvas que o seu grupo entregará ao final da aula não será avaliado pela qualidade da solução que ele esboça, nem pela sofisticação técnica do que está proposto. Ele será avaliado pela qualidade do pensamento que ele demonstra.
Um canvas bem feito tem hipóteses claramente articuladas — não afirmações vagas do tipo “a saúde poderia ser melhor”, mas afirmações específicas e falsificáveis do tipo “pacientes com insuficiência cardíaca classe funcional II ou III em acompanhamento ambulatorial em cidades com menos de cinquenta mil habitantes têm, em média, mais de duas hospitalizações de emergência por descompensação por ano, em sua maioria evitáveis com monitoramento domiciliar adequado”. Um canvas bem feito distingue explicitamente o que é fato verificado do que é hipótese. E um canvas bem feito identifica qual hipótese o grupo considera a mais arriscada — aquela que, se falsa, invalidaria toda a lógica do projeto.
Não existe um canvas “certo” neste momento. Existe um canvas honesto, que reflete o que o grupo realmente sabe e realmente supõe, e que serve de ponto de partida para a jornada de aprendizado que os módulos seguintes vão estruturar.
Conexão com os módulos seguintes
O canvas que vocês criam hoje será revisado e aprofundado ao longo de todo o semestre. Os módulos 9 e 10 — Design Thinking e Empatia, e Mapa de Empatia e Jornada do Usuário — vão dar ao grupo as ferramentas para investigar sistematicamente as hipóteses sobre o usuário que estão na segunda coluna do canvas. O módulo 12 — Ideação com Brainstorm e Crazy 8s — vai gerar múltiplas alternativas de solução para o problema validado. O módulo 13 — Solução e Proposta de Valor — vai refinar a solução escolhida e articulá-la num formato que permita comunicá-la claramente. O módulo 14 — Prototipação — vai transformar a solução em algo tangível que pode ser testado com usuários. O módulo 15 — Validação e Modelo de Negócio — vai fechar o ciclo, usando o que foi aprendido para construir a versão mais refinada do canvas.
Cada módulo de startup deste semestre é um passo na jornada que começa hoje. A qualidade de cada passo seguinte depende, em boa medida, da seriedade e da honestidade com que vocês realizam este primeiro passo.
Síntese
O ciclo de aprendizagem da startup ao longo do semestre
O diagrama acima representa a jornada que você percorrerá ao longo do semestre. O canvas que você preenche hoje, neste módulo, não é um exercício isolado — é o ponto de partida de uma investigação sistemática que vai se aprofundar a cada módulo de startup. O conteúdo técnico dos módulos intermediários — inteligência artificial, telemedicina, agentes de IA, realidade virtual, biotecnologia — não é desconectado do projeto: ele é o repertório tecnológico que vai ampliar o horizonte de soluções que o seu grupo pode considerar ao voltar para o projeto nos módulos 9 em diante.
Glossário dos termos essenciais
Startup é uma organização temporária projetada para buscar, em condições de incerteza radical, um modelo de negócios escalável e repetível. Distingue-se de uma empresa estabelecida porque ainda está aprendendo qual é o seu negócio — não executando um modelo já conhecido.
Modelo de negócio é a descrição de como uma organização cria, entrega e captura valor. Ele inclui a proposta de valor (o que o produto faz para o usuário), os segmentos de clientes (para quem), os canais (como chega ao usuário), o modelo de receita (como a empresa cobra) e a estrutura de custos (o que custa para operar).
Lean Startup é o método desenvolvido por Eric Ries que orienta startups a aprender mais rápido do que gastam, usando o ciclo construir-medir-aprender para testar hipóteses de forma sistemática e com o menor desperdício possível de recursos.
MVP — Produto Mínimo Viável — é o menor experimento possível que permite testar a hipótese mais importante que a startup precisa validar no momento, ao menor custo e com a maior velocidade possível. Não é necessariamente um produto de software: pode ser um vídeo, uma landing page, uma entrevista estruturada ou um protótipo de papel.
Pivô é uma mudança estruturada de direção que mantém um pé no que foi aprendido. É uma decisão deliberada baseada em evidências de que a hipótese atual não se sustenta e de que uma nova direção tem mais chances de levar a um modelo de negócio viável.
Aprendizagem validada é a unidade de progresso de uma startup. Progresso não se mede em funcionalidades construídas ou em linhas de código escritas — mede-se em hipóteses validadas ou refutadas com dados reais de usuários.
Hipótese de valor é a crença que a startup tem de que seu produto cria valor suficiente para que o usuário queira usá-lo de forma recorrente. Validar a hipótese de valor significa encontrar usuários que demonstram esse valor com comportamento — uso frequente, disposição para pagar, recomendação espontânea.
Hipótese de crescimento é a crença que a startup tem sobre como novos usuários descobrem e adotam o produto. Existem três motores de crescimento: viral (usuários recrutam usuários), de pagamento (receita financia aquisição de novos clientes) e pegajoso (retenção alta sustenta crescimento orgânico).
Canvas de hipóteses é um documento de trabalho que externaliza o que a equipe sabe e o que supõe sobre o problema, o usuário e a solução, separando explicitamente fatos verificados de hipóteses não verificadas.
HealthTech é uma empresa nascente cujo produto ou serviço central aplica tecnologia digital, computacional ou biotecnológica à resolução de problemas em saúde, com modelo de negócio escalável e saúde como mercado primário.
SaMD — Software as a Medical Device, ou Software como Dispositivo Médico — é qualquer software destinado a ser usado para uma ou mais finalidades médicas sem fazer parte de um dispositivo de hardware, podendo realizar essas finalidades de forma independente. SaMDs são regulados pela ANVISA no Brasil sob a RDC 657/2022.
ANVISA é a Agência Nacional de Vigilância Sanitária, responsável por regular e fiscalizar produtos e serviços que podem afetar a saúde da população, incluindo medicamentos, dispositivos médicos e softwares com finalidade diagnóstica ou terapêutica.
LGPD dados sensíveis refere-se à categoria especial de dados pessoais definida pela Lei Geral de Proteção de Dados (Lei 13.709/2018) que inclui dados de saúde, dados biométricos, dados sobre origem racial ou étnica, convicções religiosas e orientação sexual. Dados sensíveis recebem proteções reforçadas na LGPD e seu tratamento é permitido apenas em circunstâncias específicas previstas em lei.
Founder-problem fit é o grau de match entre o fundador e o problema que ele quer resolver: quanto mais o fundador conhece o problema por dentro — por experiência vivida, observação próxima ou investigação sistemática — maior o founder-problem fit e maior a probabilidade de que as hipóteses formuladas sejam precisas e relevantes.
Uma nota final antes da aula
O conteúdo deste módulo é denso e abrange temas que você vai aprofundar ao longo de todo o semestre. Não se preocupe em dominar cada conceito completamente antes da aula — o objetivo agora é ter um mapa conceitual suficientemente claro para que você possa participar da formação do grupo e do preenchimento do canvas com perspectiva metodológica. Os conceitos vão ganhar clareza à medida que você os aplica, comete erros, recebe feedback e aplica de novo. Esse é o processo de aprendizagem que esta disciplina está desenhada para proporcionar.