Plano de Aula — Módulo 02: Startup — Conceituar a HealthTech
Documento exclusivo para o professor | Módulo 02 | Formato: Módulo de Projeto
Este plano de aula é o guia pedagógico completo para a condução do Módulo 02. Ele detalha a visão geral da sessão, os objetivos de aprendizagem, a preparação prévia necessária, o sumário dos conceitos para revisão rápida, o roteiro da exposição de 30 minutos, o roteiro dos 170 minutos de trabalho em grupo com tutoria, as orientações sobre as atividades avaliativas e os pontos críticos de tutoria. Leia-o integralmente na semana anterior ao módulo e mantenha-o acessível durante toda a sessão.
1. Visão geral do módulo
O Módulo 02 é o primeiro módulo de projeto da disciplina e marca uma transição importante: do modo expositivo para o modo construtivo. Diferentemente dos módulos de conteúdo técnico, cuja estrutura reserva 50 minutos para exposição e 150 minutos para atividades em laboratório, os módulos de projeto comprimem a exposição teórica em 30 minutos e destinam os 170 minutos restantes ao trabalho real dos grupos sobre suas startups. Essa assimetria é intencional e reflete a filosofia pedagógica da disciplina: o professor apresenta o quadro conceitual mínimo suficiente para que os grupos possam trabalhar com autonomia; a maior parte do aprendizado ocorre no processo de construção, não na escuta.
Nos primeiros 30 minutos, o professor apresenta os conceitos fundamentais que ancoram todo o semestre: o que distingue uma startup de uma empresa tradicional, o ciclo Lean Startup de construir-medir-aprender, a lógica do MVP como experimento (não como produto simplificado), as especificidades das HealthTechs e o instrumento de trabalho central desta aula, o canvas de hipóteses. Essa exposição deve ser conduzida de forma dialogada, com perguntas dirigidas à turma, exemplos concretos de startups de saúde brasileiras e uma transição natural para o briefing do trabalho em grupo.
Nos 170 minutos subsequentes, o professor atua como tutor ativo, circulando entre os grupos em rodadas estruturadas. A sessão tem quatro estágios principais: formação definitiva dos grupos com definição de nome provisório da startup, escolha do domínio de problema, elaboração colaborativa do canvas de hipóteses inicial e validação pelo professor de ao menos uma hipótese por grupo. Ao final da sessão, cada grupo deve ter postado no Moodle o nome provisório da startup, um parágrafo dissertativo justificando o domínio escolhido e o canvas preenchido.
Este módulo cumpre uma função estruturante para todo o semestre: os grupos que saem dele com um domínio bem escolhido, um canvas formulado como hipótese genuína e uma equipe coesa terão base sólida para os módulos subsequentes. Os grupos que saem com um domínio vago, um canvas preenchido com certezas ou um problema confundido com solução enfrentarão dificuldades crescentes. A tutoria nesta sessão é, portanto, determinante.
2. Objetivos, competências e habilidades
Objetivo central do módulo
Introduzir os conceitos fundamentais de startup e HealthTech, conduzir a formação definitiva dos grupos e iniciar o processo de escolha do domínio de problema de cada equipe. Ao final desta aula, cada grupo deve ter sua composição definida, um nome provisório de trabalho e um canvas de hipóteses inicial registrado no Moodle.
O objetivo central desdobra-se em três competências que o estudante deve desenvolver ao longo do módulo. A primeira competência é compreender o que distingue uma startup de uma empresa tradicional e o que distingue uma HealthTech de outras startups, reconhecendo as especificidades regulatórias e de mercado que tornam o setor de saúde singular. A segunda competência é internalizar a lógica da metodologia Lean Startup como quadro de referência para o semestre inteiro, especialmente a ideia de que o trabalho do grupo consiste em testar hipóteses sobre problema, usuário e solução, e não em construir um produto. A terceira competência é ser capaz de situar a ideia inicial do projeto dentro do ecossistema de inovação em saúde no Brasil, considerando os atores envolvidos, os caminhos regulatórios possíveis e as fontes de evidência exigidas.
Do ponto de vista das habilidades práticas, ao fim da sessão o estudante deve ser capaz de articular uma hipótese de problema de forma estruturada, distinguindo o que o grupo já sabe do que o grupo apenas supõe; de preencher um canvas de hipóteses com enunciados genuinamente hipotéticos em vez de certezas disfarçadas; e de iniciar a dinâmica de colaboração em equipe com clareza sobre responsabilidades e papéis.
3. Preparação do professor
A preparação para este módulo deve começar pelo menos dois dias antes da aula. O primeiro passo é ler o material do estudante em sua totalidade, prestando atenção especial à seção sobre canvas de hipóteses e à seção sobre especificidades das HealthTechs, pois esses são os dois pontos que os grupos mais costumam tratar superficialmente na primeira vez.
Exemplos de startups para usar durante a exposição. Prepare ao menos três exemplos de HealthTechs brasileiras que possam ser usados na aula de forma concreta. Recomenda-se selecionar exemplos de diferentes categorias: uma startup de diagnóstico (como uma empresa de IA para análise de imagens médicas), uma startup de gestão (como um sistema de agendamento para clínicas), e uma startup de monitoramento remoto (como um dispositivo wearable conectado). Para cada exemplo, esteja preparado para responder: qual era a hipótese de problema inicial, como foi o primeiro MVP, qual era o usuário primário e quem aprovava e pagava.
Exemplos de canvas bem feitos e mal feitos. Prepare mentalmente ou em um rascunho pessoal dois exemplos contrastantes de canvas de hipóteses. Um canvas bem feito contém enunciados como “acreditamos que médicos de atenção primária perdem mais de 30 minutos por consulta em tarefas administrativas” (hipótese testável sobre o usuário e o problema). Um canvas mal feito contém enunciados como “o problema é que a saúde é ineficiente” (demasiado amplo, não testável) ou “a solução será um aplicativo com IA” (confunde solução com hipótese sobre problema). Ter esses exemplos mentalmente preparados permite ao professor identificar rapidamente em qual categoria cada grupo se encontra durante a circulação.
Organização do espaço físico. O espaço deve ser preparado para trabalho em grupos de 5 a 6 estudantes. Idealmente, mesas são agrupadas em ilhas, com cadeiras dispostas ao redor de cada ilha. Se a sala não permitir rearranjo, os grupos devem se organizar de forma que todos os membros consigam ver os materiais de trabalho simultaneamente. Recomenda-se disponibilizar papel A3 ou folhas grandes para rascunho do canvas, pois a externalização visual facilita a discussão e torna mais fácil para o professor avaliar o trabalho durante a circulação.
Definição dos grupos. O professor tem duas abordagens disponíveis. A primeira é preparar uma lista de grupos antes da aula, o que garante diversidade de perfis e impede a formação de grupos excessivamente homogêneos, mas pode gerar resistência. A segunda é deixar a formação livre com monitoramento ativo, intervindo apenas quando perceber grupos muito homogêneos. Em qualquer caso, o número ideal por grupo é 5 a 6 estudantes. Grupos menores têm dificuldade de cobrir a diversidade de perfis necessária ao longo do semestre; grupos maiores tornam a tutoria e a avaliação mais difíceis. Recomenda-se que o professor já tenha uma lista de nomes dos estudantes matriculados e a consulte durante a formação dos grupos.
Perguntas de abertura. Prepare ao menos duas perguntas para lançar ao início da exposição. Uma pergunta produtiva é: “O que Amazon, Nubank e Airbnb têm em comum que as diferencia de um consultório médico tradicional ou de um hospital?” Outra é: “Alguém conhece uma startup de saúde brasileira? O que ela faz?” Essas perguntas ativam o conhecimento prévio dos estudantes e criam um ponto de ancoragem para a definição formal que se segue.
4. Sumário de conteúdo — referência rápida
Esta seção apresenta uma síntese densa dos conceitos-chave do módulo para revisão rápida do professor antes da aula. Não é um roteiro de apresentação; é um mapa conceitual comprimido.
Startup: definição canônica
Para Steve Blank, uma startup é uma organização temporária que busca um modelo de negócio repetível e escalável. Para Eric Ries, é uma instituição humana projetada para criar novos produtos e serviços sob condições de incerteza extrema. O que define a startup não é o tamanho, a idade nem o setor: é a condição de incerteza radical sobre o modelo de negócio. Uma empresa tradicional executa um plano de negócios já validado; uma startup busca descobrir qual plano é viável.
Lean Startup: o ciclo central
O ciclo construir-medir-aprender é a unidade básica de trabalho de uma startup. A startup parte de uma hipótese (de valor: “alguém quer isso?”; de crescimento: “conseguimos escalar?”), constrói o menor experimento que testa essa hipótese (o MVP), mede os resultados e aprende: ou valida a hipótese (perseverar) ou a refuta (pivotar). O MVP não é uma versão simplificada do produto final; é o experimento mais barato capaz de testar a hipótese mais importante.
Pivô: tipos relevantes para HealthTechs
Pivô de segmento: o produto é o mesmo, mas o usuário-alvo muda. Pivô de problema: o usuário é o mesmo, mas o problema que se resolve muda. Pivô de canal: a solução é a mesma, mas o modo de entregá-la muda. Pivô de modelo de receita: a proposta de valor permanece, mas a forma de capturar valor financeiro muda. Em HealthTechs, o pivô de segmento e o pivô de problema são os mais frequentes nas fases iniciais.
HealthTech: definição e categorias
Uma HealthTech é uma startup que tem a saúde como mercado primário e opera com modelo de negócio escalável. As sete categorias principais são: diagnóstico e monitoramento; gestão de clínicas e hospitais; plataformas de telemedicina; dispositivos médicos conectados; saúde mental digital; bem-estar e prevenção; e saúde baseada em dados e inteligência artificial. Cada categoria implica um conjunto diferente de requisitos regulatórios e de evidência.
Especificidades regulatórias
Quatro marcos regulatórios são essenciais: a ANVISA, que regula Softwares como Dispositivos Médicos (SaMD) pela RDC 657/2022; o CFM, cuja Resolução 2.314/2022 normatiza a telemedicina; a ANS, que regula planos de saúde e sua cobertura de tecnologias; e a LGPD, que regula o tratamento de dados pessoais sensíveis (dados de saúde são dados sensíveis por definição). O ciclo de validação clínica em saúde é tipicamente de 5 a 10 anos, o que impõe planejamento de longo prazo desde a fase de hipótese.
Canvas de hipóteses: estrutura
O canvas de hipóteses tem três colunas. A primeira, “o que acreditamos sobre o problema”, deve conter hipóteses sobre a dificuldade específica que o grupo identificou: quem sofre com ela, em que situação, com que frequência e com que consequência. A segunda, “o que acreditamos sobre o usuário”, deve conter hipóteses sobre comportamentos, motivações e restrições do usuário primário. A terceira, “o que acreditamos sobre a solução”, deve conter hipóteses sobre como o grupo imagina que o problema pode ser resolvido e por que acredita que o usuário adotaria essa solução. A distinção entre fatos verificáveis e hipóteses a testar é a dimensão pedagógica mais importante do canvas.
A distinção entre fato e hipótese merece atenção especial. Um fato verificável é uma afirmação que o grupo pode checar com dados existentes antes de sair da sala: “o Brasil tem 50 milhões de hipertensos diagnosticados” é um fato verificável. Uma hipótese é uma crença que o grupo tem sobre o problema ou o usuário e que precisa de investigação para ser confirmada ou refutada: “acreditamos que hipertensos com mais de 60 anos têm dificuldade em seguir o regime medicamentoso por falta de lembretes adequados” é uma hipótese. A hipótese mais arriscada é aquela que, se refutada, inviabiliza todo o projeto. Essa deve ser testada primeiro.
5. Roteiro da exposição — 30 minutos
A exposição de 30 minutos está organizada em três blocos que devem fluir de forma contínua, sem transições bruscas. O objetivo não é cobrir exaustivamente o conteúdo do material, pois os estudantes já o estudaram na semana anterior; o objetivo é construir coletivamente, com a participação da turma, a estrutura conceitual que servirá de andaime para o trabalho em grupo.
Bloco 1 — O que é uma startup
O professor abre a sessão com uma pergunta direta à turma: “O que Amazon, Nubank e Airbnb têm em comum que as diferencia de uma empresa tradicional como um hospital ou uma clínica médica?” A pergunta deve ser lançada sem resposta imediata, dando ao menos 60 segundos para que os estudantes pensem e, eventualmente, respondam. As respostas típicas girarão em torno de tecnologia, crescimento rápido e inovação. O professor deve acolher todas as respostas sem corrigi-las imediatamente, construindo a resposta a partir das contribuições da turma.
A resposta que o professor deve construir a partir do diálogo é esta: o que essas empresas tinham em comum em seus momentos iniciais não era o tamanho nem a tecnologia, mas a condição de incerteza radical sobre o modelo de negócio. Elas não sabiam ainda quem era o cliente exato, qual era o problema que realmente resolvia e quanto as pessoas pagariam. Elas foram construídas para descobrir essas respostas por meio de experimentos, não para executar um plano pronto. Essa distinção, entre executar um plano e buscar um modelo, é a essência da diferença entre empresa tradicional e startup.
O professor deve então apresentar as definições formais de Blank e Ries de forma breve, sem entrar em detalhes biográficos. O ponto que deve ficar na memória dos estudantes é o seguinte: uma startup não é uma empresa pequena. É uma empresa em modo de busca. Assim que ela encontra seu modelo de negócio e começa a escalá-lo, ela deixa de ser uma startup e torna-se uma empresa em modo de execução.
Bloco 2 — Lean Startup e HealthTechs
O professor apresenta o ciclo construir-medir-aprender não como uma teoria abstrata, mas por meio de um exemplo clínico concreto. Um exemplo eficaz é o seguinte: imagine que um grupo acredita que médicos de atenção primária perdem muito tempo com triagem por telefone antes de confirmar consultas. A hipótese de valor é: “médicos pagariam por um sistema que automatize essa triagem”. Como testar isso da forma mais barata possível, antes de construir qualquer software? A resposta é: com uma planilha e um atendente humano fazendo a triagem manualmente enquanto o grupo observa e conta. Esse é um MVP. Não é um produto. É um experimento.
Esse exemplo deve ser explorado com a turma por cerca de três minutos, discutindo o que seria medir nesse experimento (quantos médicos participaram, quanto tempo foi economizado, quantos pagariam pela solução) e o que seria aprender (a hipótese foi confirmada? A triagem automatizada realmente resolve o problema? O problema era, na verdade, outro?).
Em seguida, o professor apresenta as especificidades das HealthTechs em bloco temático. O ponto mais importante é a regulação, e deve ser dito de forma direta: em saúde, o caminho do MVP ao produto aprovado é mais longo do que em qualquer outro setor. Uma startup que desenvolve um software de apoio à decisão clínica provavelmente precisará passar por um processo regulatório na ANVISA, por validação clínica com pacientes reais e por aprovação de comitê de ética. Isso não é um obstáculo a contornar; é parte do produto. O professor deve também mencionar brevemente o conceito de “venda de três cabeças”: em saúde, o usuário final (paciente), o pagador (plano de saúde ou gestor hospitalar) e o aprovador (médico ou comitê institucional) raramente são a mesma pessoa, o que torna a lógica comercial das HealthTechs mais complexa do que em outros mercados.
Bloco 3 — Transição para o trabalho em grupo
O professor apresenta brevemente as três tarefas do projeto para a sessão: formação dos grupos com definição de nome provisório, elaboração do canvas de hipóteses inicial e postagem no Moodle ao final da sessão. Não é necessário detalhar cada tarefa; o detalhamento ocorrerá durante a circulação. O que importa neste momento é que os estudantes entendam a sequência e o resultado esperado ao final.
O professor explica o canvas de hipóteses com o seguinte enquadramento: “Vocês não vão construir uma startup hoje. Vocês vão registrar, de forma honesta, o que acreditam sobre o problema, o usuário e a solução. Tudo o que estiver no canvas é hipótese, não plano. A diferença entre hipótese e certeza é o que tornará o semestre produtivo ou frustrante.” Após essa fala, o professor abre para perguntas rápidas (no máximo dois minutos) e instrui os estudantes a iniciarem a formação dos grupos.
6. Roteiro do trabalho em grupo — 170 minutos
Os 170 minutos de trabalho em grupo são estruturados em quatro estágios. A duração de cada estágio é indicativa; o professor deve ajustá-la conforme o ritmo real da turma. O que não pode ser comprimido é o Estágio 4 (validação e encerramento), que deve ter ao menos 15 minutos.
Estágio 1 — Formação dos grupos e briefing inicial
Este estágio ocupa aproximadamente os primeiros 20 minutos do trabalho em grupo. O professor orienta a formação dos grupos: cada grupo deve ter entre 5 e 6 estudantes, e o professor deve monitorar ativamente para evitar grupos excessivamente homogêneos. A homogeneidade problemática manifesta-se de duas formas: grupos formados exclusivamente por estudantes do mesmo círculo de amizades, que tendem a ter os mesmos interesses e a evitar conflitos produtivos; e grupos que sinalizam desde o início que todos querem trabalhar com o mesmo tema (todos querem fazer “algo com IA” ou todos vêm da mesma cidade e querem resolver um problema local específico).
Quando o professor identificar um grupo potencialmente homogêneo, a intervenção recomendada não é impor uma realocação, mas fazer uma pergunta: “Quem aqui tem vivência em gestão de saúde? Quem tem experiência em design? Quem já trabalhou em área de dados?” Se todos responderem da mesma forma, o professor pode sugerir abertamente que a diversidade de perfis fortalece o projeto e propor uma realocação voluntária.
Após a formação dos grupos, o professor realiza um briefing de cinco minutos com toda a turma, explicando as três entregas da sessão de forma concisa. O briefing deve incluir uma explicação clara do que se entende por “domínio de problema”: não é uma solução, não é um setor (como “saúde mental” ou “oncologia”), mas uma dificuldade específica vivida por um grupo específico de pessoas em um contexto específico. O professor pode usar o seguinte exemplo: “Idosos hipertensos que moram sozinhos e esquecem de tomar medicamentos” é um domínio de problema. “Saúde do idoso” não é.
Estágio 2 — Escolha do domínio de problema
Este estágio ocupa aproximadamente 40 minutos. O professor realiza a primeira rodada de circulação entre os grupos, com objetivo de apoiar e questionar a escolha do domínio.
A pergunta mais produtiva para abrir a conversa com cada grupo é: “Alguém do grupo já viveu esse problema pessoalmente ou conhece alguém que viveu?” Essa pergunta tem dupla função: verifica se há founder-problem fit (conexão pessoal ou profissional do grupo com o problema) e ativa narrativas concretas que ajudam o grupo a sair da abstração. Se ninguém no grupo tem nenhuma experiência com o problema escolhido, o professor deve sinalizá-lo como fator de risco, não como veto.
O padrão mais frequente e mais problemático neste estágio é o grupo que começa pela solução. Quando o professor ouve frases como “vamos fazer um aplicativo de IA para triagem” ou “queremos criar uma plataforma de telemedicina”, deve intervir com uma sequência de três perguntas: “Que problema específico esse aplicativo resolve?”, “Para quem esse problema existe?” e “Como vocês sabem que esse problema existe?” Essas três perguntas, feitas com tom genuinamente curioso (não hostil), redirecionam o grupo sem resolver o problema por ele. O grupo precisa chegar à resposta; o professor não deve fornecê-la.
Para grupos indecisos que apresentam múltiplos problemas candidatos sem conseguir escolher um, a intervenção recomendada é a pergunta de priorização: “Qual desses problemas vocês conseguiriam testar em duas semanas sem construir nenhum software?” A pergunta força o grupo a pensar em testabilidade imediata, que é um critério prático e poderoso de seleção.
Estágio 3 — Elaboração do canvas de hipóteses
Este estágio ocupa aproximadamente 80 minutos. O professor realiza a segunda rodada de circulação, agora com foco na qualidade do preenchimento do canvas. O objetivo não é corrigir o canvas, mas fazer perguntas que levem o grupo a perceber por si mesmo o que está bem formulado e o que precisa ser revisitado.
O primeiro sinal de alerta é o canvas com certezas em vez de hipóteses. Esse padrão se manifesta quando o grupo escreve afirmações categóricas: “os médicos perdem tempo com burocracia” ou “os pacientes querem um aplicativo fácil de usar”. Essas frases soam como fatos, mas são, na verdade, crenças não verificadas. O professor deve perguntar: “Vocês sabem isso, ou acreditam nisso? Se sabem, de onde vem esse dado? Se acreditam, como formulam isso como hipótese que pode ser testada?”
O segundo sinal de alerta é o canvas com soluções tecnológicas na coluna do problema. Esse padrão ocorre quando o grupo preenche a primeira coluna com “acreditamos que a solução ideal é um aplicativo com algoritmo de IA” em vez de uma hipótese sobre a dificuldade enfrentada pelo usuário. Quando isso acontece, o professor deve pedir ao grupo que cubra mentalmente a terceira coluna (solução) e releia apenas a primeira: “O que está escrito aqui descreve um problema vivido por uma pessoa, ou descreve uma tecnologia que vocês querem construir?” A pergunta geralmente basta para o grupo perceber o equívoco.
O terceiro sinal de alerta é o canvas com hipóteses excessivamente genéricas na coluna do usuário. Frases como “o usuário é qualquer pessoa que usa o sistema de saúde” ou “médicos e pacientes” não identificam um usuário específico o suficiente para ser investigado. O professor deve pedir ao grupo que descreva uma pessoa concreta: nome fictício, idade, especialidade médica, contexto de trabalho, frequência do problema. Esse exercício de especificação transforma um usuário abstrato em uma persona investigável.
Durante este estágio, o professor deve também observar a dinâmica interna de cada grupo. Grupos em que uma pessoa domina toda a conversa e os demais apenas concordam são grupos em risco. O professor pode, discretamente, dirigir perguntas diretamente a membros silenciosos: “E você, o que acha da hipótese de problema que o grupo formulou?”
Estágio 4 — Validação e encerramento
Este estágio ocupa os últimos 30 minutos da sessão. O professor realiza a terceira rodada de circulação com um objetivo específico: validar pessoalmente ao menos uma hipótese de cada grupo, verificando se ela é testável e formulada como hipótese (não como certeza).
A hipótese a ser validada deve ser escolhida pelo próprio grupo como a mais importante. O professor pergunta: “Se essa hipótese for falsa, vocês abandonariam o projeto?” Se a resposta for sim, é a hipótese mais arriscada e deve ser a primeira a ser testada. A validação do professor não é uma aprovação do projeto; é uma confirmação de que o grupo compreende a distinção entre hipótese e fato e que a hipótese está formulada de forma investigável.
Com cinco minutos restantes, o professor realiza um encerramento rápido com a turma reunida. O objetivo é criar visibilidade coletiva: o professor pede que cada grupo anuncia seu nome provisório e o domínio escolhido em uma ou duas frases. Não há tempo para detalhes; o objetivo é que todos na sala saibam no que cada grupo está trabalhando, criando um senso de compromisso público com a escolha. O professor finaliza com a orientação sobre a postagem no Moodle: nome provisório, parágrafo dissertativo justificando o domínio e canvas preenchido, até o final da sessão.
7. Orientações sobre as atividades
As atividades devem ser apresentadas aos estudantes não como tarefas a serem feitas após a aula, mas como guias para aprofundar o trabalho iniciado nesta sessão e que continuará nas semanas seguintes. O professor deve mencionar as atividades brevemente ao final do Estágio 1, explicando que elas são ferramentas de apoio ao desenvolvimento do projeto, não avaliações independentes do conteúdo teórico.
A Turma A trabalha com três tarefas diretamente ligadas à estruturação interna do canvas. A tarefa básica pede que o grupo articule o enunciado de problema seguindo um formato estruturado com quatro elementos: usuário específico, situação concreta, dificuldade identificável e dimensão de consequência. Essa tarefa formaliza o que o grupo iniciou na sessão presencial e obriga uma reflexão mais cuidadosa sobre a escolha do domínio. A tarefa intermediária aprofunda o canvas exigindo que o grupo distingua explicitamente, célula a célula, o que é fato verificável e o que é hipótese a testar, e justifique as escolhas. A tarefa desafiadora pede que o grupo identifique a hipótese mais arriscada do canvas e projete um experimento mínimo de aprendizagem para testá-la, aplicando explicitamente o ciclo construir-medir-aprender. Essa tarefa é deliberadamente conectada ao Módulo 09, que introduzirá o Design Thinking e a empatia, antecipando a necessidade de pesquisa com usuários reais.
A Turma B trabalha com três tarefas que expandem o canvas para o contexto externo. A tarefa básica pede um mapa de stakeholders: todos os atores relacionados ao problema escolhido (usuários, pagadores, aprovadores) e seus interesses. Essa tarefa mobiliza o conceito de “venda de três cabeças” apresentado na exposição e prepara o grupo para os módulos de startup subsequentes. A tarefa intermediária aplica as especificidades das HealthTechs ao projeto concreto do grupo: qual caminho regulatório seria aplicável, que tipo de evidência clínica seria exigida e como o modelo de “venda de três cabeças” se manifesta no contexto do problema escolhido. A tarefa desafiadora pede que o grupo posicione sua startup no espectro de inovação incremental versus disruptiva (tema do Módulo 01) e desenvolva um pitch de três minutos do canvas de hipóteses, conectando o trabalho atual ao vocabulário da aula anterior.
O resultado das atividades alimenta diretamente os Módulos 09 e 10 (Design Thinking, Mapa de Empatia e Jornada do Usuário), nos quais o grupo precisará de um canvas de hipóteses sólido para conduzir pesquisa com usuários reais. Grupos que completarem as atividades do Módulo 02 com qualidade chegarão ao Módulo 09 com uma hipótese de usuário bem formulada, o que tornará a pesquisa de empatia muito mais focada e produtiva.
8. Pontos críticos e estratégias de tutoria
Esta seção descreve os três erros mais frequentes dos grupos neste módulo, como o professor os identifica, que perguntas pode fazer e como redirecionar sem resolver o problema pelo grupo. A eficácia da tutoria depende de o professor identificar esses padrões rapidamente durante a circulação e intervir com perguntas, não com respostas.
Erro 1 — Domínio de problema muito amplo
Este é o erro mais comum e o mais fácil de identificar. O grupo escolhe um domínio como “saúde mental no Brasil”, “acesso à saúde no interior” ou “gestão hospitalar ineficiente”. São temas legítimos e importantes, mas não são problemas; são setores. Um domínio de problema suficientemente específico deve ser descrito em uma frase que identifica quem sofre (pessoa concreta), em que situação (contexto específico) e com que consequência (resultado mensurável do problema).
O professor identifica esse erro quando o grupo usa substantivos abstratos para descrever o problema: “a saúde mental está em crise”, “a gestão hospitalar é precária”, “os pacientes não têm acesso”. A intervenção recomendada começa com uma pergunta de zoom: “Quem especificamente sofre com isso? Não a população em geral, mas uma pessoa com um nome, uma idade, uma ocupação e uma rotina.” Depois: “Em que momento do dia esse problema aparece para essa pessoa? O que ela está tentando fazer quando o problema surge?” Essas perguntas forçam o grupo a descer do nível de setor para o nível de experiência individual, que é onde o MVP pode ser testado.
O professor não deve resolver esse problema dizendo ao grupo qual deveria ser o domínio específico. A especificação deve emergir do grupo, ainda que com apoio de perguntas. Se o grupo insiste em permanecer no nível abstrato, o professor pode fazer uma pergunta de consequência: “Se vocês mantiverem esse domínio amplo como está, como vão testar a hipótese em duas semanas? Com quem vão falar? O que vão perguntar?” A impossibilidade de responder concretamente a essas perguntas geralmente convence o grupo da necessidade de especificação.
Erro 2 — Grupo que começa pela tecnologia
Este erro é conceitualmente mais profundo do que o anterior e tende a ser mais resistente à tutoria. O grupo já chega à sessão com uma solução formada: “queremos usar IA para diagnóstico”, “vamos criar uma plataforma de telemedicina”, “vamos desenvolver um wearable para monitoramento de sinais vitais”. A tecnologia vira o ponto de partida, e o grupo então busca um problema que justifique a solução já escolhida, invertendo a lógica da metodologia Lean Startup.
O professor identifica esse erro quando o grupo descreve o projeto em termos de funcionalidades tecnológicas antes de mencionar qualquer usuário ou problema: “a gente vai fazer um app com machine learning que processa exames de sangue”. A intervenção recomendada é a sequência de três perguntas já mencionada na seção do Estágio 2: “Que problema específico isso resolve?”, “Para quem esse problema existe?” e “Como vocês sabem que esse problema existe?” A terceira pergunta é a mais reveladora: se o grupo não sabe como respondê-la, ainda não tem uma hipótese de problema, apenas uma hipótese de solução.
Uma variação eficaz desta intervenção é pedir ao grupo que descreva o dia de vida do usuário sem mencionar nenhuma tecnologia: “Me descrevam um dia típico na vida da pessoa que vocês querem ajudar, do momento em que ela acorda até o momento em que dorme, focando na parte que envolve o problema que vocês identificaram.” Esse exercício desacopla o grupo da solução tecnológica e forçaa observar o problema do ponto de vista da experiência vivida do usuário.
Erro 3 — Canvas preenchido com certezas em vez de hipóteses
Este erro é o mais sutil e o mais pedagógico dos três. O canvas está formalmente preenchido, as colunas têm conteúdo, o grupo demonstra segurança. Mas ao ler as células, o professor percebe que tudo está formulado como fato estabelecido: “médicos perdem tempo com burocracia” (afirmação como se fosse dado), “pacientes querem uma solução digital” (generalização sem evidência), “o SUS não tem capacidade de escalar esse serviço” (julgamento apresentado como premissa).
O professor identifica esse erro relendo o canvas junto ao grupo e perguntando, célula por célula: “Como vocês sabem isso? Isso é algo que vocês verificaram, ou algo que vocês acreditam ser verdade?” A intenção não é desafiar o grupo de forma agressiva, mas instalar a dúvida produtiva que é o motor do método científico e, por extensão, do Lean Startup. Em muitos casos, os estudantes perceberão que nunca conversaram com um médico sobre o problema escolhido, nunca leram um estudo sobre o comportamento do usuário e nunca verificaram se o SUS realmente não oferece aquele serviço. Essa percepção é o aprendizado mais valioso do módulo.
A reformulação correta de uma certeza em hipótese segue o padrão: “Acreditamos que [afirmação] porque [razão], e planejamos testar isso [método]. Se essa hipótese for falsa, [consequência para o projeto].” O grupo não precisa chegar a esse nível de formalização ainda nesta sessão; mas deve sair da sessão sabendo que a diferença existe e que ela importa.
9. Recursos e materiais de apoio
O material de referência primário para este módulo, disponibilizado aos estudantes na semana anterior à aula. O professor deve conhecê-lo integralmente, com atenção especial às seções 6 (Como escolher um problema) e 7 (Canvas de hipóteses), que são os conteúdos mais diretamente mobilizados durante o trabalho em grupo.
A seção Startups contém a descrição completa do Projeto da Startup, incluindo a descrição de cada entrega ao longo do semestre, os critérios de avaliação e as instruções para a apresentação em formato pitch. O professor deve estar familiarizado com esse documento para poder responder a perguntas dos grupos sobre o escopo total do projeto e para contextualizar as tarefas de cada sessão dentro da trajetória do semestre.
O template do canvas de hipóteses deve ser disponibilizado em formato físico (folha A3 impressa com as três colunas) ou em formato digital no Moodle antes da aula. O canvas físico tem a vantagem de estimular o trabalho colaborativo e de ser visível para o professor durante a circulação; o canvas digital tem a vantagem de facilitar a postagem no Moodle ao final da sessão. O professor pode optar por um formato híbrido: rascunho físico durante a sessão e transcrição digital para postagem.
Conexões com outros módulos
O domínio de problema escolhido e o canvas de hipóteses elaborados neste módulo são retomados diretamente nos Módulos 09 (Design Thinking e Empatia), 10 (Mapa de Empatia e Jornada do Usuário) e 12 (Ideação). A qualidade do trabalho realizado nesta sessão tem impacto direto na capacidade do grupo de realizar pesquisa de empatia com profundidade e de gerar ideias relevantes nas sessões de ideação. O professor deve enfatizar isso no encerramento da sessão.
As seções 4 (Especificidades das HealthTechs) e 5 (Ecossistema de saúde digital no Brasil) do material do estudante oferecem conteúdo de contextualização que o professor pode mobilizar durante a tutoria para grupos que escolhem domínios com implicações regulatórias claras (dispositivos médicos, diagnóstico auxiliado por IA, telemedicina). Conhecer esses conteúdos permite ao professor antecipar obstáculos que os grupos enfrentarão nos módulos seguintes e orientá-los desde agora a considerar o contexto regulatório como parte do design do projeto, não como um complicador externo.