flowchart TD
M01["Introdução<br/>Tecnologia e Inovação"]
M02["STARTUP<br/>Conceituar a HealthTech"]
M03["Inteligência Artificial"]
M04["Telemedicina"]
M05["Palestra<br/>+ Consolidação"]
M06["Agentes de IA"]
M07["Realidade Virtual e Aumentada"]
M08["Biotecnologia"]
M09["STARTUP<br/>Design Thinking e Empatia"]
M10["STARTUP<br/>Mapa de Empatia e Jornada"]
M11["Segurança da Informação"]
M12["STARTUP<br/>Ideação"]
M13["STARTUP<br/>Solução e Proposta de Valor"]
M14["STARTUP<br/>Prototipação"]
M15["STARTUP<br/>Validação e Modelo de Negócio"]
PITCH["Pitch Final<br/>Banca Avaliadora"]
M01 --> M02
M02 --> M03
M03 --> M04
M04 --> M05
M05 --> M06
M06 --> M07
M07 --> M08
M08 --> M09
M09 --> M10
M10 --> M11
M11 --> M12
M12 --> M13
M13 --> M14
M14 --> M15
M15 --> PITCH
M03 -. "IA pode compor<br/>a solução" .-> M12
M04 -. "regulação condiciona<br/>o modelo" .-> M13
M06 -. "agentes podem<br/>integrar o produto" .-> M13
M07 -. "RV/RA como<br/>recurso terapêutico" .-> M13
M08 -. "biotecnologia como<br/>base da solução" .-> M13
M11 -. "segurança como<br/>requisito de produto" .-> M14
classDef startup fill:#d4edda,stroke:#28a745,color:#155724
classDef teorico fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
classDef palestra fill:#fff3cd,stroke:#ffc107,color:#856404
classDef avaliacao fill:#f8d7da,stroke:#dc3545,color:#721c24
class M02,M09,M10,M12,M13,M14,M15 startup
class M01,M03,M04,M06,M07,M08,M11 teorico
class M05 palestra
class PITCH avaliacao
Projeto das HealthTechs
Guia Completo do Projeto da Startup
Este documento descreve, com alto nível de detalhe, o projeto que percorre toda a disciplina “Tecnologia e Inovação em Saúde”. Leia-o integralmente antes do início das aulas, pois ele define o que se espera de você e de sua equipe em cada etapa do semestre. Retorne a ele sempre que precisar reorientar o trabalho do grupo ou compreender o significado de uma entrega específica.
O que é uma HealthTech e por que este projeto existe
O termo HealthTech designa empresas — em geral startups — que utilizam tecnologia para criar soluções inovadoras no setor da saúde. O conceito é amplo e deliberadamente assim: uma HealthTech pode ser um aplicativo que auxilia pacientes com diabetes no monitoramento da glicemia, um sistema de inteligência artificial que apoia radiologistas na detecção precoce de tumores, uma plataforma de telemedicina que conecta especialistas a municípios remotos, ou um dispositivo vestível que monitora sinais vitais em tempo real e alerta o médico antes que o paciente perceba qualquer sintoma. O que as une não é a tecnologia em si, mas a ambição de resolver problemas reais de saúde de formas que o sistema tradicional, sozinho, não consegue resolver.
Por que uma disciplina de medicina deveria se ocupar de startups? A resposta está no projeto pedagógico do seu curso e na natureza do problema que a saúde enfrenta. O sistema de saúde brasileiro e mundial opera sob tensões crescentes: envelhecimento populacional, aumento da prevalência de doenças crônicas, desigualdade de acesso, escassez de profissionais em áreas remotas, custo crescente de tratamentos e pressão por evidências de efetividade. Nenhuma dessas tensões se resolve apenas com mais médicos formados pelo mesmo modelo de sempre. Resolvê-las exige que os médicos do futuro — e você é um deles — saibam dialogar com tecnologia, identificar oportunidades de inovação e, quando necessário, construir soluções que ainda não existem.
Mais do que isso, a formação médica contemporânea reconhece que a prática clínica do século XXI não ocorre em isolamento. Você trabalhará em ecossistemas digitais: prontuários eletrônicos, plataformas de telemedicina, sistemas de suporte à decisão, aplicativos de monitoramento. Compreender como essas ferramentas são criadas — quais problemas elas pretendem resolver, quais hipóteses elas incorporam, onde elas falham e por quê — é uma competência tão importante quanto saber interpretar um eletrocardiograma. Não se trata de transformar médicos em programadores; trata-se de formar profissionais capazes de avaliar criticamente, adotar conscientemente e, eventualmente, influenciar o desenvolvimento das tecnologias com as quais interagirão ao longo de toda a carreira.
O projeto da HealthTech existe, portanto, por uma razão pedagógica precisa: aprender sobre tecnologia e inovação em saúde fazendo tecnologia e inovação em saúde. Não como simulação didática, mas como exercício genuíno de identificação de problema, compreensão de usuário, geração de solução, prototipação e validação. O produto final do semestre não é uma startup operando no mercado — é um protótipo validado, sustentado por evidências de que o problema identificado é real e de que a solução proposta tem potencial de resolver esse problema. E, principalmente, é o aprendizado incorporado em cada etapa desse processo.
A lógica do projeto ao longo do semestre
O projeto da HealthTech não ocorre em paralelo com a disciplina: ele é a espinha dorsal em torno da qual os módulos teóricos se organizam. Cada tecnologia estudada — inteligência artificial, telemedicina, realidade virtual, biotecnologia, segurança da informação — é, ao mesmo tempo, um conteúdo em si e um recurso potencial para a startup que você e seu grupo estão construindo. O conhecimento não é neutro nem genérico: ele está a serviço de um problema específico que você escolheu investigar.
Essa arquitetura tem uma consequência importante: a qualidade da sua startup depende, em parte, da profundidade com que você assimilou os conteúdos teóricos da disciplina. Um grupo que não compreendeu as limitações dos sistemas de inteligência artificial não saberá avaliar se a solução que propõe é tecnicamente viável. Um grupo que não internalizou os marcos regulatórios da telemedicina não saberá identificar as restrições legais que condicionam o modelo de negócio. Os módulos teóricos não são pré-requisitos da startup: são ingredientes ativos de sua construção.
O diagrama abaixo representa a arquitetura do projeto ao longo do semestre. Observe como os módulos de startup se distribuem entre os módulos teóricos, alimentando-se deles e, ao mesmo tempo, conferindo-lhes sentido e urgência.
A progressão do projeto segue uma lógica que você precisa compreender para não se sentir perdido nas semanas intermediárias. O semestre se divide, informalmente, em três fases.
A primeira fase é predominantemente de preparação e contexto. Nos módulos teóricos, você adquire o vocabulário técnico e o repertório crítico necessários para fazer escolhas informadas sobre a sua startup. O grupo se forma, escolhe um domínio de problema e começa a articular, ainda de forma preliminar, o que pretende construir. Essa escolha inicial não é definitiva — e não deve ser: o processo de design thinking que virá nas semanas seguintes provavelmente a refinará de forma significativa.
A segunda fase é a fase da compreensão do usuário. Antes de propor qualquer solução, o grupo se dedica integralmente a entender o problema da perspectiva de quem o vive. Você conduzirá entrevistas com usuários reais, sintetizará o que ouviu em ferramentas visuais e formulará, com precisão, o enunciado do problema que sua startup se propõe a resolver.
A terceira fase é a da solução. Com o problema bem definido e o usuário bem compreendido, o grupo gera ideias, seleciona a mais promissora, constrói um protótipo e o testa. O semestre se encerra com a elaboração do modelo de negócios e a preparação do pitch.
Formação e dinâmica dos grupos
Cada grupo será composto por cinco a seis estudantes. A formação pode ser feita livremente entre os membros da turma. A composição do grupo é relevante: grupos com perfis muito homogêneos tendem a gerar ideias menos diversas e a ter pontos cegos coletivos. Se possível, busque reunir colegas com interesses, estilos de trabalho e formas de pensar complementares.
O projeto não exige a designação formal de papéis hierárquicos dentro do grupo — não há um “CEO” ou um “CTO”. O que se espera é que, em cada módulo de startup, o grupo tenha clareza sobre quem lidera cada atividade específica, quem registra as decisões e quem é responsável por cada entrega. Essa responsabilidade pode ser rotativa ao longo do semestre ou fixada por acordo interno — o importante é que todos saibam, a cada sessão, o que se espera de cada um.
A dinâmica de trabalho durante os módulos de startup é a seguinte: inicialmente ocorre a exposição do professor, que apresenta o tema do módulo e estabelece a conexão com o projeto. O tempo restante da aula é dedicado ao trabalho do grupo, com orientação docente disponível de forma contínua. Esse tempo é o coração do projeto: é nesse espaço que o grupo pensa, debate, produz e entrega. Use-o com intenção.
A relação entre os membros do grupo deve ser pautada pela honestidade intelectual: quando uma hipótese não funciona, o grupo precisa ter a disposição de reconhecê-lo e ajustar a direção. Grupos que se apegam à primeira ideia por receio de conflito interno raramente produzem projetos relevantes. A dinâmica de aprendizagem por times — uma das metodologias centrais da disciplina — pressupõe que a qualidade do produto coletivo depende da qualidade das interações entre os membros. Discuta, questione, experimente, erre e corrija: esse é o ritmo esperado.
Sobre a escolha do problema e do domínio
Uma das decisões mais importantes do semestre — e uma das mais difíceis — é a escolha do problema que sua HealthTech tentará resolver. Essa escolha pode ser refinada ao longo das etapas de empatia. Não há problema em mudar a direção nessas semanas: é esperado que o contato com usuários reais revele nuances que a escolha inicial não contemplou.
O que torna um problema adequado para uma HealthTech de disciplina? Primeiro, o problema deve estar situado no domínio da saúde, de forma direta ou indireta — pode ser um problema clínico, de gestão hospitalar, de acesso a serviços, de prevenção de doenças, de educação em saúde ou de cuidado crônico. Segundo, o problema deve ser real: não uma suposição teórica sobre o que os pacientes sofrem, mas algo que pelo menos algum dos membros do grupo já observou ou vivenciou, e que será confirmado e aprofundado por meio de entrevistas de empatia. Terceiro, o problema deve ter uma dimensão tecnológica que justifique a proposta de uma solução digital ou habilitada por tecnologia.
É igualmente importante compreender o que não serve como ponto de partida: uma tecnologia. Grupos que começam pela tecnologia — “vamos fazer um aplicativo de IA para diagnóstico” — sem antes identificar um problema real para o qual essa tecnologia é a resposta mais adequada costumam construir soluções elegantes que ninguém quer usar. A HealthTech começa pelo problema, não pela solução. Essa distinção parece simples, mas subverter essa ordem é o erro mais comum entre empreendedores iniciantes — e entre pesquisadores que transformam suas descobertas em produtos.
O domínio escolhido deve estar alinhado com o conteúdo programático da disciplina: inteligência artificial, telemedicina, realidade virtual e aumentada, biotecnologia, segurança da informação, agentes de IA. Isso não significa que o produto final obrigatoriamente utilize todas essas tecnologias; significa que a solução proposta deve ser fundamentada nos conceitos que a disciplina apresenta. Um grupo que propõe uma solução de monitoramento remoto de pacientes com insuficiência cardíaca, por exemplo, deverá ancorar sua proposta no que aprendeu sobre telemedicina, wearables e segurança da informação.
flowchart LR
A["Problema<br/>identificado"] --> B["Usuário<br/>compreendido"]
B --> C["Solução<br/>gerada"]
C --> D["Tecnologia<br/>escolhida"]
D --> E["Protótipo<br/>construído"]
E --> F["Hipóteses<br/>validadas"]
F --> G["Modelo de<br/>negócios"]
X["Tecnologia<br/>escolhida"] -.->|"caminho<br/>equivocado"| Y["Problema<br/>buscado"]
Y -.-> Z["Solução<br/>forçada"]
style X fill:#f8d7da,stroke:#dc3545,color:#721c24
style Y fill:#f8d7da,stroke:#dc3545,color:#721c24
style Z fill:#f8d7da,stroke:#dc3545,color:#721c24
O que fazer em cada módulo de startup
Conceituar a Startup
Inicialmente o professor apresenta os conceitos centrais sobre startups — o que as distingue de empresas tradicionais, a lógica da Lean Startup, os fundamentos do ecossistema de saúde digital — que você já terá estudado previamente no material do módulo. Esses conceitos não são apenas teoria: eles definem o vocabulário e o quadro de referência que o grupo usará ao longo de todo o semestre.
No tempo restante, o grupo tem três tarefas principais. A primeira é a formação definitiva da equipe e a definição de um nome de trabalho para a startup — provisório, sem compromisso de manutenção, apenas para dar identidade ao grupo durante as semanas iniciais. A segunda tarefa é a escolha do domínio de problema: a área de saúde na qual o grupo pretende atuar. Essa escolha deve ser fundamentada em algum contato real com o problema — uma experiência vivida, uma observação clínica ou uma situação reportada por familiar ou conhecido — e não apenas em uma intuição sobre o que “parece importante”. A terceira tarefa é a elaboração de um canvas inicial de hipóteses: um documento simples que registra, de forma estruturada, o que o grupo sabe (ou acredita saber) sobre o problema, o usuário e a possível solução. Esse canvas não é um compromisso; é um ponto de partida que será sistematicamente questionado nas semanas seguintes.
Entrega
O grupo deve postar na plataforma Moodle, até o final da sessão, um documento contendo: o nome provisório da startup, o domínio de problema escolhido (em um parágrafo dissertativo que explica por que o grupo acredita que esse problema merece atenção), e o canvas inicial de hipóteses com as colunas “o que acreditamos sobre o problema”, “o que acreditamos sobre o usuário” e “o que acreditamos sobre a solução”. O documento não precisa ter mais de duas páginas — o valor está na clareza, não na extensão.
Uma observação importante sobre esse momento: a incerteza é esperada e bem-vinda. Você não precisa saber, neste módulo, como o produto vai funcionar, quem exatamente vai pagar por ele ou qual tecnologia vai utilizá-lo. O que se espera é que o grupo tenha identificado uma direção genuína e que consiga articulá-la com honestidade — incluindo o que ainda não sabe. Grupos que apresentam hipóteses excessivamente definidas nesta etapa geralmente estão confundindo certeza com superficialidade.
Consolidação do Projeto
Este é um momento de consolidação: o grupo já escolheu seu domínio de problema e elaborou hipóteses iniciais, e agora é hora de confrontar essas hipóteses com o que foi aprendido nos módulos de inteligência artificial e telemedicina. A pergunta central que o grupo deve responder nesta sessão é: o que os módulos anteriores mudaram — ou deveriam mudar — na forma como o grupo pensa o problema ou a solução?
Durante esta sessão, o professor percorre os grupos para uma conversa de feedback, comentando o canvas de hipóteses entregue anteriormente e fazendo perguntas que ajudam o grupo a identificar pontos cegos e oportunidades de refinamento. Esse feedback não é uma avaliação formal — é uma orientação pedagógica que o grupo deve levar a sério e incorporar ao trabalho das semanas seguintes.
Entrega
O grupo deve postar no Moodle, até o final da sessão, um documento de atualização do canvas de hipóteses. O documento deve indicar explicitamente o que mudou em relação à versão anterior, por que mudou, e quais perguntas permanecem abertas. Não é necessário ter respostas para todas as perguntas: identificar com clareza o que ainda não se sabe é, em si mesmo, um avanço.
Design Thinking e Empatia
Este módulo inaugura a segunda fase do projeto: a compreensão profunda do usuário. Antes de qualquer proposta de solução, o grupo precisa ir a campo e ouvir as pessoas que vivem o problema que pretende resolver.
A metodologia de empatia do design thinking propõe que o empreendedor (ou, neste caso, o grupo) saia das suas hipóteses e vá ao encontro da experiência real do usuário. Isso significa conduzir entrevistas abertas e não diretivas com pessoas que têm contato direto com o problema identificado: podem ser pacientes, cuidadores, médicos, enfermeiros, gestores hospitalares, farmacêuticos ou qualquer outro ator do sistema de saúde cuja perspectiva seja relevante para o domínio escolhido.
A entrevista de empatia tem características que a distinguem de uma pesquisa de opinião ou de um questionário estruturado. Ela é conduzida com perguntas abertas que convida o entrevistado a contar histórias, não a responder categorias. O entrevistador ouve mais do que fala, tolera o silêncio, segue a direção que o entrevistado estabelece e resiste à tentação de antecipar respostas ou de confirmar hipóteses já formadas. O objetivo não é validar o que o grupo já acredita: é descobrir o que o grupo ainda não sabe.
flowchart LR
A["Preparação<br/>da entrevista"] --> B["Condução<br/>sem roteiro<br/>rígido"]
B --> C["Registro fiel<br/>de observações"]
C --> D["Síntese<br/>em insights"]
D --> E["Questionamento<br/>das hipóteses<br/>iniciais"]
style A fill:#d4edda,stroke:#28a745,color:#155724
style B fill:#d4edda,stroke:#28a745,color:#155724
style C fill:#d4edda,stroke:#28a745,color:#155724
style D fill:#d4edda,stroke:#28a745,color:#155724
style E fill:#d4edda,stroke:#28a745,color:#155724
Durante o trabalho, cada membro do grupo compartilha com os demais o que ouviu nas entrevistas que conduziu. Em seguida, o grupo organiza o material coletado em tópicos — não ainda ferramentas formais, mas agrupamentos temáticos de observações, citações diretas e impressões de campo. Cada registro deve indicar claramente se é uma observação direta (“a paciente disse que…”) ou uma inferência do entrevistador (“a forma como ela hesitou ao falar sobre o médico sugere que…”). Misturar observação e interpretação é o erro mais comum nesta etapa, e o que mais compromete a qualidade das etapas seguintes.
Entrega
O grupo deve postar no Moodle um documento com: a descrição de cada entrevista realizada (perfil do entrevistado, duração aproximada, contexto), os principais trechos ou paráfrases do que foi ouvido, e uma síntese em texto dissertativo — não em listas — dos temas que emergiram com maior frequência ou intensidade. O documento deve conter também uma seção explícita sobre como o material coletado confirmou, refinou ou contradisse as hipóteses do canvas elaborado nos módulos anteriores.
Mapa de Empatia e Jornada do Usuário
Aqui você e seu grupo transformarão o material bruto das entrevistas em duas ferramentas estruturadas que vão orientar toda a fase de solução do projeto: o Mapa de Empatia e a Jornada do Usuário.
O Mapa de Empatia organiza o que o grupo sabe sobre o usuário em dimensões que se complementam e, quando analisadas juntas, oferecem um retrato coerente da sua experiência: o que ele pensa e sente em relação ao problema; o que ele ouve de médicos, familiares e colegas; o que ele vê ao seu redor quando o problema se manifesta; o que ele faz e o que ele diz sobre o problema; suas dores — frustrações, medos, obstáculos; e seus ganhos — o que ele deseja alcançar, o que define sucesso para ele. Preencher cada dimensão exclusivamente com dados das entrevistas — sem inferências não suportadas pelo material coletado — é o que diferencia um Mapa de Empatia válido de uma projeção das suposições do grupo.
A Jornada do Usuário mapeia a experiência no tempo. Ela descreve cada etapa pela qual o usuário passa ao interagir com o sistema de saúde (ou com um processo específico relacionado ao problema), os pontos de contato em cada etapa, as emoções que o usuário experimenta em cada momento e os pontos de dor — os momentos em que a experiência é mais frustrante, confusa ou ineficiente. A Jornada é uma narrativa: ela conta uma história com começo, meio e fim, e é exatamente essa estrutura narrativa que permite ao grupo identificar onde, ao longo dessa história, uma intervenção tecnológica poderia fazer maior diferença.
journey
title Jornada de uma paciente com hipertensão
section Detecção
Sentir sintomas inespecíficos: 3: Paciente
Hesitar em buscar atendimento: 2: Paciente
section Diagnóstico
Conseguir consulta (fila longa): 2: Paciente
Receber diagnóstico de HAS: 3: Paciente, Médico
section Tratamento inicial
Receber prescrição: 4: Médico
Entender a medicação: 2: Paciente
Comprar medicamento: 3: Paciente
section Adesão
Lembrar de tomar a medicação: 2: Paciente
Monitorar a pressão em casa: 2: Paciente
Registrar medições: 1: Paciente
section Retorno
Agendar retorno: 2: Paciente
Levar dados ao médico: 2: Paciente
Ajustar tratamento: 4: Paciente, Médico
O diagrama acima é apenas um exemplo ilustrativo. A jornada que o seu grupo construirá será específica ao usuário que vocês entrevistaram e ao problema que identificaram — ela terá etapas, emoções e pontos de dor próprios, derivados das entrevistas reais.
Com o Mapa de Empatia e a Jornada do Usuário concluídos, o grupo estará em condições de formular o enunciado do problema com a precisão necessária para orientar a fase de ideação. Um bom enunciado de problema descreve quem é o usuário, em que situação específica o problema se manifesta e qual é o impacto desse problema na vida do usuário. Ele não inclui a solução: o enunciado descreve o problema, não o caminho para resolvê-lo.
Entrega
O grupo deve postar no Moodle: o Mapa de Empatia completo (pode ser uma imagem digitalizada de um artefato produzido em papel ou um arquivo de design), a Jornada do Usuário completa (com as etapas, os pontos de contato, as emoções e os pontos de dor claramente identificados), e o enunciado do problema em formato dissertativo — um parágrafo preciso e bem redigido que descreve o usuário, a situação e o impacto do problema. Esse enunciado é uma das entregas mais importantes do semestre: dedique tempo para escrevê-lo bem.
Ideação: Brainstorm e Crazy 8s
Com o problema definido e o usuário compreendido, chega o momento de gerar ideias. Não uma ideia, nem três: muitas ideias, das mais variadas possíveis, sem qualquer julgamento prévio sobre viabilidade ou originalidade. Esse é o princípio central da fase de ideação no design thinking, e é contraintuitivo para quem está acostumado a contextos onde a qualidade vale mais do que a quantidade.
A fase de ideação deste módulo utilizará duas técnicas complementares que o material descreve em detalhes: o brainstorm estruturado, que gera um volume alto e diverso de ideias a partir de regras explícitas que inibem a autocensura; e o Crazy 8s, uma técnica rápida de ideação visual em que cada membro esboça oito ideias distintas em oito minutos. As duas técnicas se complementam: o brainstorm opera pela palavra e pela discussão; o Crazy 8s opera pela imagem e pela rapidez.
Durante o trabalho em grupo, a sessão de ideação segue uma sequência que o professor delineará no início da aula: divergência (gerar o máximo de ideias possível, sem filtragem), compartilhamento (cada membro apresenta suas ideias ao grupo), e convergência (o grupo seleciona as ideias mais promissoras com base em critérios explícitos). Os critérios de seleção não são fixos: o grupo decide quais são os mais relevantes para o problema em questão, podendo incluir originalidade, viabilidade técnica no contexto da disciplina, alinhamento com as necessidades identificadas do usuário, e potencial de impacto na saúde.
flowchart LR
A["Revisão do<br/>enunciado<br/>do problema"] --> B["Divergência:<br/>brainstorm<br/>e Crazy 8s"]
B --> C["Compartilhamento<br/>de ideias"]
C --> D["Definição de<br/>critérios de<br/>seleção"]
D --> E["Convergência:<br/>ideia(s)<br/>selecionada(s)"]
E --> F["Refinamento<br/>da ideia<br/>eleita"]
style A fill:#d4edda,stroke:#28a745,color:#155724
style B fill:#d4edda,stroke:#28a745,color:#155724
style C fill:#d4edda,stroke:#28a745,color:#155724
style D fill:#d4edda,stroke:#28a745,color:#155724
style E fill:#d4edda,stroke:#28a745,color:#155724
style F fill:#d4edda,stroke:#28a745,color:#155724
Uma observação sobre a etapa de convergência: é comum que grupos entrem em conflito na escolha entre ideias concorrentes. Esse conflito é produtivo desde que seja mediado por critérios — e não por hierarquia, simpatia pessoal ou volume de voz. Se o grupo não consegue convergir durante a sessão, uma boa estratégia é selecionar duas ou três ideias finalistas e, antes do próximo módulo, testá-las brevemente com ao menos um usuário real para decidir qual merece ser desenvolvida.
Entrega
O grupo deve postar no Moodle: uma descrição dissertativa das sessões de brainstorm e Crazy 8s (como foram conduzidas, quantas ideias foram geradas, quais os critérios de seleção adotados), o conjunto de ideias geradas na fase de divergência (pode ser uma lista, neste caso específico, pois o volume de ideias é o que importa), e uma descrição detalhada da ideia selecionada — ou das finalistas, se o grupo ainda não convergiu. A descrição da ideia selecionada deve explicar por que ela foi escolhida e como ela responde ao enunciado do problema formulado anteriormente.
Solução e Proposta de Valor
Partiremos de uma ideia ainda difusa a uma solução clara e a uma proposta de valor articulada. São dois movimentos distintos, mas profundamente relacionados.
Definir a solução significa responder, com precisão, o que exatamente o produto faz, para quem e em quais condições. Uma solução bem definida não é uma promessa vaga de transformação; é uma descrição específica de uma intervenção concreta. Ela tem limites: o produto faz isso, mas não faz aquilo. Ela tem um usuário preciso: não “pacientes em geral”, mas “pacientes com diabetes tipo 2 que fazem acompanhamento em UBS de cidades com menos de 50 mil habitantes”. E ela tem condições de operação: funciona em contextos com conectividade limitada, ou exige internet de alta velocidade? Pode ser usado sem treinamento, ou requer capacitação? O grupo precisa responder a essas perguntas — não necessariamente de forma definitiva, mas com a suficiente clareza para que o protótipo, no módulo seguinte, possa ser construído a partir delas.
A proposta de valor é a articulação do benefício que o produto entrega ao usuário — e que nenhum outro produto disponível entrega da mesma forma, na mesma combinação ou com a mesma acessibilidade. Ela responde à pergunta: por que o usuário escolheria este produto em vez de não usar nada, ou em vez de usar o que já existe? A resposta não deve ser dada em termos de características técnicas do produto, mas em termos de resultados que importam para o usuário. A distinção entre “o que o produto tem” e “o que o produto faz pela vida do usuário” é a diferença entre uma especificação técnica e uma proposta de valor.
O grupo usará o Value Proposition Canvas para estruturar esse trabalho: uma ferramenta que mapeia, de um lado, o perfil do cliente (tarefas que ele precisa realizar, dores que experimenta e ganhos que deseja) e, do outro, o mapa de valor do produto (como o produto alivia as dores, como cria os ganhos desejados e quais são os produtos e serviços que compõem a oferta). O “encaixe” entre essas duas dimensões é o que define se a proposta de valor é genuína.
flowchart LR
subgraph Usuário
A["Tarefas que<br/>precisa realizar"]
B["Dores que<br/>experimenta"]
C["Ganhos que<br/>deseja"]
end
subgraph Produto
D["Aliviadores<br/>de dor"]
E["Criadores<br/>de ganho"]
F["Produtos e<br/>serviços"]
end
B <-->|"encaixe"| D
C <-->|"encaixe"| E
A <-->|"encaixe"| F
Entrega
O grupo deve postar no Moodle: o Value Proposition Canvas completo (preenchido com dados reais do usuário identificado nos módulos anteriores, não com suposições), uma descrição dissertativa da solução — o que o produto faz, para quem, em que condições e com que limites —, e um parágrafo síntese da proposta de valor escrito para o usuário, não para o professor. Esse parágrafo deve ser inteligível para alguém que nunca ouviu falar da startup e deve comunicar o benefício central de forma clara e convincente.
Prototipação
A prototipação é, provavelmente, a etapa que mais surpreende estudantes de medicina que se deparam pela primeira vez com o processo de inovação. Na formação médica tradicional, o produto do trabalho intelectual é sempre acabado: um diagnóstico, uma prescrição, uma tese. Na lógica do design thinking e da cultura maker, o produto mais valioso em determinadas etapas é incompleto — e é exatamente essa incompletude que o torna útil.
Um protótipo não é uma versão prévia do produto final: é um artefato criado para testar uma hipótese específica. A hipótese pode ser sobre a usabilidade de uma interface, sobre a relevância de uma funcionalidade, sobre a disposição do usuário de modificar um comportamento ou sobre a clareza de uma instrução. O protótipo é o menor experimento possível que permite ao grupo obter uma resposta sobre essa hipótese com o menor custo de tempo e recursos.
Os protótipos variam em fidelidade ao produto final. Um protótipo de baixa fidelidade pode ser um conjunto de telas desenhadas em papel, uma sequência de cartões que simula o fluxo de uso de um aplicativo, ou um modelo físico feito de materiais simples. É rápido de produzir, fácil de modificar e adequado para testar hipóteses amplas sobre a direção do produto. Um protótipo de média fidelidade usa ferramentas de design digital para criar mockups estáticos ou com alguma interatividade — adequado para testar hipóteses sobre fluxos de navegação e arquitetura de informação. Um protótipo de alta fidelidade simula o produto final com elevado grau de realismo, adequado para testar hipóteses sobre detalhes de interação quando as decisões centrais já foram tomadas.
flowchart TD
H["Hipótese a<br/>testar"] --> P["Construir<br/>protótipo<br/>adequado"]
P --> T["Testar com<br/>usuário real"]
T --> A["Analisar<br/>reações<br/>e feedback"]
A --> D{"Hipótese<br/>confirmada?"}
D -->|"Sim"| R["Avançar para<br/>a próxima<br/>hipótese"]
D -->|"Não"| J["Refinar<br/>a solução"]
J --> P
style H fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
style P fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
style T fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
style A fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
style D fill:#fff3cd,stroke:#ffc107,color:#856404
style R fill:#d4edda,stroke:#28a745,color:#155724
style J fill:#f8d7da,stroke:#dc3545,color:#721c24
Para este módulo, o grupo deve decidir qual é a hipótese central que precisa ser testada sobre a solução definida no módulo anterior. Essa hipótese deve ser a mais importante para a viabilidade do produto — não necessariamente a mais fácil de testar. Em seguida, o grupo constrói o protótipo mais simples que permite testar essa hipótese e, se possível dentro do tempo da sessão, o apresenta a pelo menos um usuário real para coletar reações. A velocidade é parte do exercício: prototipar não é uma atividade de precisão artesanal, mas de aprendizagem acelerada.
Entrega
O grupo deve postar no Moodle: a descrição da hipótese testada, o protótipo construído (como arquivo de imagem, PDF ou link para ferramenta de design digital), o relato do teste com usuário (quem foi testado, o que foi perguntado, o que foi observado) e a síntese do aprendizado — o que o teste confirmou, o que refutou e quais ajustes serão feitos na solução como resultado.
Validação e Modelo de Negócio
Este módulo trata de duas questões que, juntas, determinam se uma HealthTech tem futuro real: a solução resolve um problema verdadeiro para pessoas reais? E existe um modelo de negócios que a torna sustentável?
A validação é o processo de testar hipóteses fundamentais sobre o produto com o menor custo possível. O que se busca validar nesta etapa são as hipóteses de maior risco — aquelas que, se estiverem erradas, comprometeriam toda a razão de existir da startup. Para uma HealthTech, essas hipóteses geralmente incluem: os usuários de fato têm o problema que o grupo identificou (e não apenas disseram ter durante as entrevistas); a solução proposta resolve o problema de forma satisfatória do ponto de vista do usuário; e existe uma disposição real de uso (e, eventualmente, de pagamento) pelo produto. Validar uma hipótese significa estar disposto a descobrir que ela está errada — e ter a honestidade de comunicar esse resultado com a mesma clareza com que se comunicaria uma validação positiva.
O modelo de negócios da HealthTech será estruturado a partir do Business Model Canvas, que organiza os nove componentes de qualquer negócio: os segmentos de clientes atendidos; a proposta de valor entregue a cada segmento; os canais pelos quais o produto chega ao cliente; o tipo de relacionamento que a empresa mantém com o cliente; as fontes de receita; os recursos-chave necessários para operar; as atividades-chave que a empresa precisa realizar; as parcerias-chave que tornam o modelo viável; e a estrutura de custos.
Para HealthTechs, o canvas ganha camadas adicionais de complexidade que o grupo deve considerar com atenção. A questão de quem paga pelo produto é especialmente delicada no setor saúde: o usuário final raramente é o pagador; com frequência, o pagamento vem do plano de saúde, do hospital, da unidade de saúde pública ou de um programa governamental. Cada um desses pagadores tem critérios, processos de compra e horizontes de tempo muito diferentes. Ignorar essa distinção é um dos erros mais comuns em propostas de HealthTech elaboradas por quem ainda não tem experiência no setor.
flowchart TD
subgraph BMC["Business Model Canvas"]
direction TB
P["Parceiros-<br/>chave"] --- A["Atividades-<br/>chave"]
A --- V["Proposta<br/>de Valor"]
V --- R["Relacionamento<br/>com Clientes"]
R --- S["Segmentos<br/>de Clientes"]
A --- Re["Recursos-<br/>chave"]
Re --- V
C["Estrutura<br/>de Custos"] -.- P
C -.- A
C -.- Re
Rc["Fontes de<br/>Receita"] -.- R
Rc -.- S
V --- Ch["Canais"]
Ch --- S
end
Entrega
O grupo deve postar no Moodle: o Business Model Canvas completo da HealthTech (preenchido com base no que foi aprendido ao longo do semestre e nas validações realizadas), um texto dissertativo que explica as escolhas feitas em cada bloco do canvas — especialmente as mais difíceis, como a fonte de receita e os segmentos de cliente —, e uma seção sobre as hipóteses que ainda precisam ser validadas e que o grupo levaria às próximas etapas se o projeto continuasse além do semestre.
A apresentação final: o pitch
A última semana do curso é dedicada integralmente à apresentação dos projetos em formato pitch para uma banca avaliadora. O pitch é uma forma de apresentação oral que combina clareza, densidade e persuasão em um tempo estritamente limitado. Não é uma defesa de tese, nem uma aula sobre o tema da startup: é a história do percurso que o grupo realizou ao longo do semestre, contada de forma que faça sentido para quem a ouve pela primeira vez.
Estrutura narrativa do pitch
Cada grupo terá 8 minutos para apresentar e 2 minutos para responder perguntas da banca. Os 8 minutos são poucos: cada palavra e cada slide devem ganhar o direito de estar ali. A estrutura narrativa mais eficaz para um pitch de HealthTech segue a lógica do problema antes da solução, da evidência antes da conclusão, da história antes dos dados.
flowchart LR
A["O Problema<br/>(1,5 mim)"] --> B["O Usuário<br/>(1 min)"]
B --> C["A Solução<br/>(2 min)"]
C --> D["A Proposta<br/>de Valor<br/>(1 min)"]
D --> E["O Mercado<br/>(1 min)"]
E --> F["O Modelo<br/>de Negócios<br/>(1 min)"]
F --> G["Próximos<br/>Passos<br/>(0,5 min)"]
G --> H["Perguntas<br/>(2 min)"]
style A fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
style B fill:#d1ecf1,stroke:#17a2b8,color:#0c5460
style C fill:#d4edda,stroke:#28a745,color:#155724
style D fill:#d4edda,stroke:#28a745,color:#155724
style E fill:#fff3cd,stroke:#ffc107,color:#856404
style F fill:#fff3cd,stroke:#ffc107,color:#856404
style G fill:#f8d7da,stroke:#dc3545,color:#721c24
style H fill:#f8d7da,stroke:#dc3545,color:#721c24
O problema deve ser apresentado de forma concreta e humana. O recurso mais eficaz é contar uma história: a história de uma pessoa real (ou composta a partir de pessoas reais que o grupo entrevistou) que experimenta o problema que a HealthTech pretende resolver. A história deve provocar reconhecimento no ouvinte — a sensação de “sim, esse problema é real, eu já vi isso” — antes de qualquer dado estatístico. Os dados vêm depois, para confirmar que o caso individual não é uma exceção, mas representativo de uma situação ampla.
O usuário deve ser apresentado com precisão. Não “pacientes”, mas o perfil específico de usuário identificado nas entrevistas e sintetizado no Mapa de Empatia e na Jornada do Usuário. A banca avaliará se o grupo realmente entendeu quem é seu usuário ou se está operando com estereótipos.
A solução deve ser apresentada de forma direta: o que o produto faz, em linguagem acessível, sem jargão técnico desnecessário. Se o grupo construiu um protótipo navegável ou um vídeo de demonstração, essa é a hora de mostrá-lo. Demonstrações valem mais do que descrições.
A proposta de valor é o momento de responder à pergunta que todo avaliador tem em mente: por que este produto em vez de nada, ou em vez do que já existe? A resposta deve ser precisa e honesta — incluindo o reconhecimento de produtos concorrentes e a articulação clara do diferencial.
O mercado não precisa ser detalhado com profundidade: o grupo deve apenas demonstrar que existe um número relevante de usuários com o problema identificado e que, portanto, a startup tem potencial de escala.
O modelo de negócios deve responder, de forma direta, como a startup ganha dinheiro. No contexto da saúde, isso inclui necessariamente explicar quem paga, como e por quê — mesmo que a resposta ainda seja uma hipótese a ser validada.
Os próximos passos devem demonstrar que o grupo pensa no projeto além do semestre: o que seria necessário para levar o produto a um próximo nível de validação? Qual seria o próximo experimento? Qual seria o recurso mais importante a buscar?
Preparação da apresentação
A qualidade de um pitch depende tanto do conteúdo quanto da forma de apresentá-lo. Sobre o conteúdo, tudo já foi dito: ele é produto do trabalho de todo o semestre. Sobre a forma, algumas orientações são relevantes.
Os slides devem ser simples e visuais. Uma imagem que evoca o problema, um diagrama que explica a solução, um slide com uma única métrica impactante — esses elementos comunicam mais do que páginas de texto. O texto nos slides deve ser mínimo: ele existe para ancorar a fala do apresentador, não para substituí-la. Slides com muitas palavras transformam o ouvinte em leitor e retiram a atenção de quem está falando.
A apresentação deve ser ensaiada — não decorada, mas ensaiada. Há uma diferença importante: decorar cria uma dependência do texto memorizado que se quebra ao menor imprevisto; ensaiar constrói familiaridade com o conteúdo e com a sequência narrativa, de forma que qualquer membro do grupo possa retomar a fala se necessário. Cada grupo deve fazer ao menos dois ensaios cronometrados antes da apresentação final.
Todos os membros do grupo devem participar ativamente da apresentação. A divisão de partes entre os membros deve ser natural — seguindo a estrutura narrativa — e não artificial. A banca observará não apenas o que é dito, mas a coesão do grupo: se os membros demonstram conhecer igualmente bem o projeto ou se há um ou dois que claramente concentram todo o trabalho.
Durante as perguntas, o grupo deve ouvir com atenção antes de responder. Se a pergunta for sobre algo que o grupo não sabe, a resposta honesta é “ainda não sabemos, mas acreditamos que…” — seguida da hipótese mais razoável que o grupo tem. Fingir certeza onde há incerteza é o erro que mais prejudica a credibilidade de um “pitcheiro” diante de uma banca experiente.
Critérios de avaliação
A avaliação do projeto das startups divide-se em duas componentes, conforme descrito na seção de Sistema de Avaliação da disciplina: a Avaliação Contínua (peso 4), composta pelas entregas dos módulos de startup ao longo do semestre, e a Avaliação Final (peso 6), correspondente ao pitch.
pie title Composição da Nota Final
"Avaliação Contínua (entregas dos módulos)" : 40
"Pitch Final (banca avaliadora)" : 60
Avaliação Contínua
As entregas dos módulos compõem a avaliação contínua. Cada entrega é avaliada segundo três dimensões: completude (todos os elementos solicitados foram entregues?), qualidade do raciocínio (o grupo demonstra que pensou com profundidade sobre o problema e as alternativas, ou apenas preencheu os campos formalmente?) e evolução (o trabalho do módulo se constrói sobre o que foi aprendido nos módulos anteriores, incorporando feedback e refinando a direção?).
Entregas incompletas ou realizadas fora do prazo impactam a nota da avaliação contínua. A plataforma Moodle registra o horário de postagem: o prazo de cada entrega é o final da sessão correspondente, salvo indicação explícita do professor.
Avaliação Final — Pitch
O pitch é avaliado por uma banca composta pelos professores da disciplina e por avaliadores convidados do ecossistema de inovação. Os critérios de avaliação são os seguintes.
A profundidade da pesquisa de usuário avalia se o grupo demonstra conhecimento genuíno do usuário identificado: se as entrevistas foram conduzidas e sintetizadas com rigor, se o Mapa de Empatia e a Jornada do Usuário revelam compreensão real da experiência do usuário, e se o enunciado do problema é preciso e ancorado em evidência empírica.
A adequação da solução ao problema avalia se há uma lógica coerente entre o problema identificado e a solução proposta: se a solução endereça especificamente as dores e os ganhos do usuário identificado, se ela é tecnicamente plausível no contexto das tecnologias estudadas na disciplina, e se o Value Proposition Canvas demonstra encaixe real entre produto e usuário.
A viabilidade do modelo de negócios avalia se o Business Model Canvas é internamente consistente e se as escolhas sobre segmento de cliente, fonte de receita e canais demonstram compreensão das especificidades do mercado de saúde. A banca não espera que o modelo seja definitivo — espera que ele seja pensado e justificado.
A qualidade do protótipo e do processo de teste avalia se o grupo construiu um protótipo adequado à hipótese que pretendia testar, se conduziu um teste com usuário real e se demonstrou capacidade de aprender com os resultados desse teste.
A clareza e o impacto da apresentação oral avalia a estrutura narrativa do pitch, a distribuição equitativa da apresentação entre os membros, a qualidade dos slides, a capacidade de responder perguntas da banca com honestidade e fundamentação, e a habilidade de comunicar ideias complexas de forma acessível para um público não especializado no tema específico da startup.
A nota final de cada grupo é única para todos os membros. Não há avaliação individual das contribuições de cada membro dentro do grupo — a responsabilidade pelo projeto é coletiva, o que significa que cada membro tem o dever de garantir que todo o grupo esteja igualmente engajado e informado. Grupos em que um ou dois membros concentram todo o trabalho estão, portanto, assumindo um risco coletivo.
Uma palavra final sobre o que este projeto realmente é
É tentador avaliar o sucesso do projeto pela qualidade do produto final — se a ideia é original, se o protótipo é bonito, se o modelo de negócios parece convincente. Mas o critério mais importante não é esse. É o aprendizado incorporado ao longo do caminho.
Um grupo que identificou um problema real, ouviu seus usuários com genuína curiosidade, gerou ideias com ousadia, prototipou com humildade, testou com rigor e ajustou a direção quando os dados contradisseram as hipóteses — esse grupo aprendeu o que a disciplina se propôs a ensinar, independentemente de quão elegante seja a solução final. Um grupo que chegou ao pitch com uma ideia impressionante que nunca foi testada com nenhum usuário real, cujo modelo de negócios é uma projeção otimista sem contato com a realidade do mercado de saúde, e cujo protótipo nunca provocou uma reação genuína de ninguém — esse grupo não aprendeu o essencial, por mais polido que seja o deck de slides.
A medicina que você exercerá não é a medicina dos livros. É a medicina do encontro com o paciente real, com o sistema real, com as limitações reais. O projeto da HealthTech é, em última análise, um treino para esse encontro: a prática de levar a sério a perspectiva de quem você está tentando ajudar, de testar suas hipóteses antes de agir sobre elas, e de ter a honestidade intelectual de reconhecer quando está errado. São habilidades que poucos cursos de medicina ensinam diretamente. Esta disciplina escolheu fazê-lo por meio de uma startup.