Palestra e Consolidação e Revisão das Hipóteses

Ao final deste módulo, você será capaz de:

Sintetizar os conceitos centrais dos Módulos 1 a 4 e articulá-los com o estágio atual do canvas de hipóteses do seu projeto; distinguir os três tipos de atualização possível num canvas de hipóteses e aplicar essa distinção de forma crítica à situação real do seu projeto; compreender a definição rigorosa de pivô na metodologia Lean Startup, identificar os diferentes tipos de pivô e reconhecer quando pivotar é a resposta metodologicamente correta.

---

Por que este módulo é diferente — e por que isso importa

Você chegou ao quinto módulo desta disciplina. Nos quatro anteriores, percorreu um caminho que começou na história da tecnologia médica e na crítica à ideia de que ferramentas são neutras, passou pela metodologia Lean Startup e pelas especificidades das HealthTechs, atravessou os fundamentos da inteligência artificial aplicada à medicina e chegou à telemedicina com toda a sua complexidade regulatória e ética. Em paralelo, o seu grupo começou a construir o canvas de hipóteses da startup que desenvolverá ao longo do semestre.

Se você seguiu o percurso de forma ativa — e espero que tenha —, algo interessante deve ter acontecido: o seu projeto mudou. Não necessariamente de tema, mas de profundidade. O problema que o grupo escolheu resolver no início do semestre provavelmente está mais nítido agora, ou revelou camadas de complexidade que não eram visíveis na primeira semana. Algumas hipóteses que pareciam sólidas talvez tenham começado a mostrar rachaduras. Outras, que eram vagas, foram ganhando contorno. Isso é exatamente o que deveria estar acontecendo.

O quinto módulo existe precisamente nesse momento — depois de quatro semanas de construção conceitual e antes de quatro semanas de tecnologias avançadas e aprofundamento do projeto — porque é o momento em que faz sentido parar, integrar e recalibrar. Mas este módulo não é um módulo de revisão no sentido passivo de rever conteúdo. É um módulo de síntese ativa: você vai usar o que aprendeu para olhar para o seu próprio projeto com olhos mais críticos e mais informados do que tinha quando começou.

O formato da aula reflete isso. Em vez de uma exposição teórica sobre um novo tema, você ouvirá um médico que percorreu o caminho do empreendedorismo em saúde — não em teoria, mas na prática, com todas as dificuldades, surpresas e aprendizados que a prática produz. E depois disso, o seu grupo terá tempo para revisar o canvas de hipóteses à luz de tudo o que aprendeu até aqui.

O que um praticante sabe que os livros não ensinam

Existe uma diferença fundamental entre o conhecimento teórico e o conhecimento experiencial — e essa diferença não é um clichê motivacional, é uma distinção epistemológica com consequências práticas importantes para a sua formação como médico empreendedor.

O conhecimento teórico é aquele que pode ser transmitido por palavras, fórmulas, modelos e frameworks. Você aprendeu, no Módulo 2, que startups operam sob incerteza radical e que o método adequado para navegar essa incerteza é o ciclo construir-medir-aprender. Aprendeu que o MVP não é um produto mínimo viável no sentido de qualidade ruim, mas um experimento projetado para gerar aprendizado máximo com investimento mínimo. Aprendeu que o pivô é uma mudança de estratégia sem mudança de visão. Tudo isso é conhecimento teórico legítimo, rigoroso e útil. É a base sem a qual a prática não tem ancoragem.

Mas o conhecimento experiencial é diferente. Ele não é melhor do que o teórico — é de outra natureza. Um médico que atravessou o processo de fundar uma HealthTech, levantar capital, enfrentar a Agência Nacional de Vigilância Sanitária com regulamentações inesperadas, negociar com co-fundadores em momentos de crise, perder um contrato grande para um concorrente que copiou a ideia com mais recursos, e conseguir sobreviver para contar a história — esse médico tem acesso a dimensões da experiência que nenhum livro captura completamente.

A razão é simples: a experiência não é apenas informação; é informação com peso emocional, temporal e contextual. Saber, em abstrato, que “pivôs são dolorosos” é muito diferente de ter vivido o momento em que uma equipe de quatro pessoas percebe, depois de oito meses de trabalho, que o produto que construíram não é o que os clientes precisam. Saber que “barreiras regulatórias são um desafio específico das HealthTechs” é muito diferente de ter recebido uma intimação da ANVISA perguntando se o seu software é um dispositivo médico — uma pergunta que, se respondida de forma incorreta, pode inviabilizar anos de desenvolvimento.

O pensador americano Michael Polanyi chamou de “conhecimento tácito” aquele que não pode ser completamente formalizado em regras explícitas. Polanyi usava o exemplo do ciclismo: você pode ler todos os livros de física sobre equilíbrio e forças centrífugas, mas isso não te ensina a andar de bicicleta. Andar de bicicleta exige um tipo de conhecimento que só o corpo aprende, fazendo. O empreendedorismo tem muito de conhecimento tácito nesse sentido — há dimensões da experiência fundacional que só ficam disponíveis para quem as viveu.

A boa notícia é que a exposição reflexiva à experiência de um praticante — especialmente quando você está com o próprio projeto em mente — é uma das formas mais eficazes de desenvolver antecipadamente alguns aspectos desse conhecimento tácito. Não é o mesmo que ter vivido. Mas é muito melhor do que não ter tido nenhum contato com o que a prática realmente parece.

A diferença entre assistir a uma palestra e ouvir com o projeto em mente

Há uma distinção importante entre duas formas de presença numa palestra, e essa distinção vai determinar o quanto você aproveita o que o Dr. Vitor Barion tem a dizer.

A primeira forma é a escuta passiva. Nela, você está presente fisicamente, ouve as palavras, registra informações interessantes e guarda memórias de episódios marcantes. Essa forma de escuta é perfeitamente adequada para uma aula sobre um tema que você está estudando pela primeira vez, sem nenhum comprometimento pessoal com o conteúdo. Ela produz aprendizagem — mas do tipo que os psicólogos da aprendizagem chamam de aprendizagem declarativa: você sabe que algo aconteceu, pode reproduzir o conteúdo se perguntado, mas não necessariamente o integra à sua forma de agir.

A segunda forma é a escuta estratégica. Nela, você está presente com um problema concreto na cabeça — no caso, o seu projeto de startup. Enquanto o palestrante fala, você está constantemente fazendo uma pergunta implícita: “o que isso significa para o meu canvas?” Quando o médico empreendedor descreve como teve que pivotar o modelo de distribuição do produto por causa de uma barreira que não tinha previsto, a escuta estratégica ativa imediatamente a pergunta: “nosso grupo já pensou em como o produto chegaria até o usuário final? Qual barreira de distribuição poderíamos não ter previsto?” Quando ele menciona que o maior conflito com o co-fundador não foi sobre visão do produto, mas sobre velocidade de execução, você se pergunta: “nosso grupo tem alinhamento sobre ritmo? Onde estão as tensões não ditas?”

A diferença entre essas duas formas de escuta não é de atenção ou inteligência — é de preparação e intenção. Por isso, uma parte significativa deste material pré-aula é dedicada a preparar você para a segunda forma de escuta. Você vai chegar ao módulo 5 com o canvas de hipóteses na cabeça, com perguntas formuladas e com uma disposição ativa de extrair do que o palestrante diz aprendizados concretos para o projeto do grupo.

O mentor imaginário e a tomada de decisão sob incerteza

A literatura sobre aprendizagem experiencial descreve um fenômeno interessante chamado de “mentor imaginário”: o processo pelo qual alguém incorpora perspectivas de praticantes admirados ao próprio processo de tomada de decisão, mesmo na ausência física desse praticante. Não se trata de imitação acrítica, mas de um diálogo interno que enriquece a deliberação.

Pesquisadores de cognição e tomada de decisão observam que profissionais experientes — médicos, pilotos, bombeiros, empreendedores — tomam decisões sob pressão não através de análise racional explícita de opções, mas através de um reconhecimento de padrões acumulados ao longo de anos de prática. O médico experiente entra no quarto do paciente e sente que “algo não está certo” antes de conseguir articular exatamente o quê — e essa intuição, formada por centenas de encontros anteriores, é geralmente confiável. O empreendedor experiente ouve a descrição de um modelo de negócio e sente imediatamente onde estão as fragilidades, porque já viu variações daquele modelo falharem de formas específicas.

O que a exposição reflexiva a experiências de praticantes faz é começar a construir, em você, os primeiros fragmentos dessa biblioteca de padrões. Não com a profundidade que décadas de prática produziriam, mas com um valor real: quando você estiver diante de uma decisão difícil no projeto da startup, você vai ter acesso a algo como “o médico empreendedor disse que o maior erro que cometeu foi não conversar com usuários reais cedo o suficiente — o que isso significa para a decisão que estou tomando agora?”

Esse é o valor pedagógico profundo do formato deste módulo. Aproveite-o.

---

Dr. Vitor Barion: quem é e o que esperar

O Dr. Vitor Barion é um médico com experiência em empreendedorismo e inovação em saúde. O que isso significa, concretamente, é que ele percorreu um caminho que a maioria dos médicos não percorre: decidiu, em algum momento da carreira, que além de exercer a medicina clinicamente, queria contribuir para transformar o sistema de saúde através da criação de novas soluções tecnológicas. Esse caminho tem especificidades que o tornam particularmente relevante para o que você está aprendendo nesta disciplina.

Um médico empreendedor não é apenas um médico que “entende de tecnologia”, nem é apenas um empreendedor que “entende de medicina”. É alguém que precisou aprender a transitar entre dois mundos muito diferentes — o mundo da prática clínica, com sua lógica de cuidado, responsabilidade e regulamentação, e o mundo do empreendedorismo, com sua lógica de risco calculado, iteração rápida e busca por escalabilidade. Essa tradução entre mundos raramente é fácil, e as tensões que ela produz são fontes extraordinárias de aprendizado.

O que perguntar a um médico empreendedor — e o que não perguntar

Existe uma diferença significativa entre o que faz sentido perguntar a um professor e o que faz sentido perguntar a um praticante. Ao professor, você pergunta para entender conceitos, clarificar dúvidas sobre modelos teóricos, aprofundar sua compreensão de um framework. Ao praticante, você pergunta para acessar dimensões da experiência que não estão nos livros — os pontos de inflexão, as decisões que parecem óbvias só depois, os padrões que só se veem depois de muita prática.

Perguntas que não aproveitam bem o tempo de um médico empreendedor são aquelas que poderiam ser respondidas por um livro. “O que é um MVP?” é uma pergunta para o módulo 2, não para uma palestra com um praticante. “Como funciona a regulamentação de software de saúde pela ANVISA?” é uma pergunta que tem uma resposta técnica verificável em documentos regulatórios — não exige a perspectiva única de quem viveu aquilo.

As perguntas que realmente aproveitam a presença de um médico empreendedor são aquelas que tocam no que a experiência produz de insubstituível. Algumas sugestões de tipos de pergunta que valem ser formuladas:

Perguntas sobre julgamento diante de ambiguidade: “Quando você percebeu que precisava pivotar — e o que te fez ter confiança de que era o momento certo, e não uma fuga do problema?” Essa pergunta não tem uma resposta certa que pode ser encontrada num livro. Ela acessa o julgamento prático que só se desenvolve com experiência.

Perguntas sobre o que surpreendeu: “O que você descobriu na prática que mais contradiz o que aprendeu na teoria — ou o que esperava com base nos exemplos que conhecia?” Essas perguntas são valiosas porque revelam gaps entre modelos e realidade que raramente aparecem em materiais didáticos.

Perguntas sobre o lado humano do processo: “Como você lidou com a pressão de investidores quando os resultados não vieram no ritmo esperado? Como manteve a equipe coesa num momento de crise?” O empreendedorismo é uma atividade profundamente humana, e as dimensões emocionais e relacionais raramente aparecem em frameworks teóricos.

Perguntas estratégicas para o seu projeto: “Dada essa descrição [do nosso projeto], qual é a primeira coisa que você verificaria sobre as premissas que estamos fazendo? Qual hipótese te parece mais frágil?” Essa categoria de pergunta é a mais valiosa de todas, porque usa a perspectiva do praticante diretamente como ferramenta de análise do seu trabalho.

A etiqueta da escuta produtiva

Ouvir bem é uma habilidade ativa, não uma ausência de comportamento. Há algumas práticas que fazem diferença real na qualidade do que você extrai de uma palestra.

Anotar o que surpreende é mais valioso do que anotar o que confirma o que você já sabia. O que confirma suas crenças você já sabe. O que surpreende é novo — é onde o aprendizado está. Se o palestrante disser algo que contradiz uma hipótese do seu canvas, anote imediatamente e escreva, ao lado, qual hipótese ele está contradizendo. Esse é o tipo de nota que tem valor direto para a sessão de revisão que se segue.

Ouvir sem interromper é uma demonstração de respeito ao raciocínio do palestrante, mas também tem valor epistêmico: ideias complexas precisam ser desenvolvidas antes de serem criticadas. A interrupção prematura frequentemente mata no nascedouro um pensamento que, se completado, teria uma qualidade que a versão interrompida não deixa adivinhar. Guarde suas perguntas para o momento dedicado a elas.

Distinguir o que é específico do contexto do palestrante do que é generalizável é uma habilidade de escuta crítica. O Dr. Barion viveu uma experiência concreta, num contexto específico, com um produto específico, num momento específico do mercado. Nem tudo o que funcionou para ele funcionará para o seu projeto — e o inverso também vale. Escutar criticamente significa extrair os princípios gerais de experiências concretas, não copiar receitas.

---

Síntese integradora: o que os Módulos 1 a 4 significam para o seu projeto

Esta é a seção mais densa e mais importante deste material. Ela não introduz conteúdo novo — ela pede que você use o conteúdo que já aprendeu para olhar de forma mais sofisticada para o projeto que está construindo. Se você ler esta seção com o canvas do seu grupo aberto ao lado, o aproveitamento será muito maior.

Do Módulo 1: tecnologia, inovação e o framework crítico aplicados ao seu projeto

O Módulo 1 estabeleceu uma premissa que pode parecer filosófica, mas tem consequências práticas diretas para qualquer pessoa que está desenvolvendo uma solução tecnológica em saúde: a tecnologia não é neutra.

Recapitule o argumento. Toda tecnologia médica carrega embutida uma teoria sobre o que é o corpo, o que é a doença, o que é o cuidado. O estetoscópio de Laennec não apenas amplificou sons cardíacos — ele reorganizou a relação entre médico e paciente, inaugurou a ausculta mediada por instrumento como forma de diagnóstico e criou uma assimetria informacional que permanece estrutural até hoje. O prontuário eletrônico não apenas digitalizou fichas de papel — ele transformou o encontro clínico em evento documentável, rastreável, auditável, e trouxe consigo toda uma nova política de privacidade e propriedade dos dados. A inteligência artificial diagnóstica não apenas acelera laudos — ela redistribui o trabalho cognitivo entre humanos e máquinas e cria riscos de viés sistêmico que podem aprofundar desigualdades.

Agora aplique isso ao seu projeto. Que teoria sobre o corpo, a doença ou o cuidado está embutida na solução que o seu grupo está desenvolvendo? Quem ganha e quem perde com essa teoria? A solução pressupõe que o paciente é um sujeito ativo ou um objeto de intervenção? Ela pressupõe que o cuidado é melhor quando mediado por tecnologia ou quando tecnologia serve de suporte ao cuidado presencial? Essas não são perguntas retóricas — são perguntas que têm respostas concretas para a sua solução específica, e que afetam decisões de design, de público-alvo e de modelo de negócio.

O framework de cinco perguntas que o Módulo 1 apresentou — qual problema, para quem, a que custo, com qual evidência, quem ganha e quem perde — é uma ferramenta de análise que fica mais poderosa na medida em que você conhece melhor o problema que está tentando resolver. Quando o seu grupo preencheu o canvas pela primeira vez, no início do Módulo 2, respondia a essas cinco perguntas com conhecimento limitado do problema. Você conhecia o problema como alguém que leu sobre ele ou ouviu falar dele. Agora, quatro semanas depois, o grupo deveria conhecê-lo mais profundamente — especialmente se realizou alguma conversa com pessoas que vivem esse problema.

Portanto, uma das tarefas desta semana é revisar as cinco perguntas do framework com o olhar de quem tem mais informação do que tinha em fevereiro. A pergunta “qual problema?” provavelmente ficou mais precisa: o grupo agora sabe não apenas que existe um problema, mas em que contexto específico ele ocorre, com que frequência, para quem ele é mais grave, que soluções parciais as pessoas já usam e por que essas soluções são insuficientes. A pergunta “quem ganha e quem perde?” provavelmente ficou mais complexa: talvez o grupo tenha descoberto que a solução, se implementada de certa forma, beneficia um grupo às custas de outro — e isso é uma escolha que precisa ser feita conscientemente.

Há também o espectro incremental-disruptivo, que o Módulo 1 apresentou como ferramenta de posicionamento estratégico. Inovação incremental melhora o que já existe; inovação disruptiva cria um mercado novo ou transforma radicalmente um existente. A maioria das HealthTechs começa com pretensões disruptivas e, com o tempo, descobre que está fazendo inovação incremental — o que não é necessariamente um problema, mas precisa ser reconhecido porque tem implicações para o modelo de negócio, para o ciclo de adoção e para o argumento de valor que a startup apresenta a clientes e investidores.

Onde está o projeto do seu grupo nesse espectro hoje? E mais importante: mudou desde o Módulo 2? Se o grupo começou com a ambição de “transformar completamente a forma como a triagem de emergência é feita no Brasil” e agora, depois de aprender mais sobre o problema e o ecossistema, percebe que está desenvolvendo “uma melhoria na interface de um processo de triagem que já existe em algumas unidades avançadas”, isso é uma mudança de posicionamento que precisa ser reconhecida — não como fracasso, mas como aprendizado que afeta todas as outras premissas do canvas.

Do Módulo 2: o canvas de hipóteses e as especificidades das HealthTechs

O Módulo 2 introduziu dois conjuntos de ferramentas que continuam sendo centrais para o seu trabalho nesta semana: o canvas de hipóteses como instrumento de gestão do aprendizado da startup, e as cinco especificidades das HealthTechs como mapa de riscos que sua solução precisa navegar.

Sobre o canvas: ele foi apresentado não como um plano de negócios, mas como um documento vivo de hipóteses. A distinção importa. Um plano de negócios é um compromisso com uma visão do futuro — é redigido com linguagem de certeza porque seu propósito é convencer leitores externos (investidores, bancos) de que a empresa sabe o que está fazendo. Um canvas de hipóteses é o oposto: é redigido com linguagem de probabilidade porque seu propósito é o interno, ajudar a equipe a saber o que ainda não sabe e a priorizar o que precisa ser testado primeiro.

O que é normal que já tenha mudado no canvas neste ponto do semestre? Mais do que o seu grupo provavelmente mudou. A maioria dos grupos de estudantes, nesse estágio, tem canvas muito similares ao que preencheu no início — com hipóteses iniciais ligeiramente refinadas, mas sem mudanças significativas baseadas em aprendizado. Isso acontece por várias razões: resistência natural a admitir que uma premissa estava errada, dificuldade de encontrar tempo para conversar com usuários reais, incerteza sobre como conduzir entrevistas de descoberta de problema. Mas acontece, acima de tudo, porque nenhuma hipótese foi testada ainda. E canvas que não testa hipóteses não aprende.

Reflita honestamente: o grupo fez alguma entrevista com usuários ou potenciais clientes desde que o projeto começou? Falou com algum profissional que trabalha no contexto do problema que está tentando resolver? Observou o problema acontecendo no ambiente real em que ele ocorre? Se a resposta for não, o canvas que o grupo tem hoje é o mesmo canvas de quatro semanas atrás — e a revisão que precisará ser feita neste módulo é mais fundamental do que uma mera atualização.

As cinco especificidades das HealthTechs apresentadas no Módulo 2 — regulamentação complexa e incerta, ciclos de adoção longos, evidência clínica como pré-requisito de credibilidade, sensibilidade especial dos dados de saúde e a necessidade de integração com sistemas legados — funcionam como um mapa de riscos que qualquer solução de saúde digital precisa percorrer. A tarefa desta semana não é ter respostas para todos esses riscos, mas identificar qual deles representa o maior risco para o projeto específico do seu grupo — e ser honesto sobre o quanto o grupo já pensou sobre ele.

Se o seu projeto usa dados clínicos de pacientes, por exemplo, a questão da regulamentação de dados de saúde sob a Lei Geral de Proteção de Dados não é um detalhe técnico-jurídico que pode ser deixado para depois: ela afeta o modelo de negócio, os custos de operação, os parceiros que o projeto precisará ter e os usuários que terão ou não acesso à solução. Se o projeto depende de adoção por profissionais de saúde dentro de instituições, a questão dos ciclos longos de adoção e da necessidade de integração com sistemas já existentes é central para qualquer projeção de crescimento que o grupo tenha feito no canvas.

Há também uma pergunta que o Módulo 2 colocou de forma provocativa e que esta semana é o momento de retomar: o grupo está construindo para aprender ou construindo para construir? A distinção pode parecer sutil, mas é o coração da metodologia Lean Startup. Um grupo que está construindo para aprender se pergunta, a cada decisão sobre o produto, “o que isso vai me ensinar sobre a hipótese que mais preciso testar?” Um grupo que está construindo para construir se pergunta “o que é mais fácil de implementar com as habilidades que temos?” O primeiro grupo usa o MVP como experimento. O segundo usa o MVP como protótipo — e frequentemente descobre, tarde demais, que construiu algo que não resolve o problema que se propôs a resolver.

Do Módulo 3: inteligência artificial e o componente tecnológico do projeto

O Módulo 3 cobriu os fundamentos da inteligência artificial aplicada à medicina: aprendizado supervisionado, não supervisionado e por reforço; redes neurais profundas e seus tipos; as aplicações clínicas já em uso ou em fase avançada de desenvolvimento; as métricas de avaliação de modelos de classificação — sensibilidade, especificidade, curva ROC, AUC — e as implicações de diferentes pontos de corte para diferentes contextos clínicos; e, talvez mais importante, as questões éticas e os riscos de viés algorítmico.

A pergunta para esta semana não é acadêmica — é estratégica: o que o grupo aprendeu sobre IA que deveria mudar, ou que já mudou, o componente tecnológico do projeto?

Se o projeto usa IA de alguma forma, o Módulo 3 deveria ter dado ao grupo ferramentas para pensar com mais precisão sobre o componente tecnológico. Qual paradigma de aprendizado é o mais adequado para o problema específico que a solução está tentando resolver? Um sistema de alerta para deterioração clínica de pacientes internados é diferente de um sistema de triagem de exames de imagem, que é diferente de um sistema de recomendação de conduta terapêutica — e cada um desses casos tem implicações distintas para o tipo de dado necessário, para a arquitetura de modelo adequada e para a métrica de avaliação que deve ser prioritária.

A questão dos dados de treinamento é particularmente importante e frequentemente subestimada por grupos que estão propondo soluções de IA sem ter experiência prévia com desenvolvimento de sistemas de aprendizado de máquina. Que dados seriam necessários para treinar o modelo que o projeto propõe? Esses dados existem num formato utilizável? Quem os possui? Há barreiras de privacidade, de propriedade ou de representatividade que limitariam o acesso? Um modelo treinado em dados de um hospital universitário de grande porte em São Paulo generaliza bem para uma unidade básica de saúde em Belém do Pará? Essas são perguntas que o grupo precisa ter pelo menos formulado — não necessariamente respondido — antes de afirmar que a solução usa IA.

A questão do viés algorítmico, discutida no Módulo 3, tem uma dimensão específica que é relevante para qualquer projeto de HealthTech: o problema que o grupo está resolvendo afeta grupos populacionais que são sub-representados em dados típicos de treinamento? Mulheres, pacientes idosos, populações negras e indígenas, pessoas em situação de pobreza, habitantes de regiões rurais — esses grupos são sistematicamente sub-representados nos grandes datasets clínicos que geralmente estão disponíveis para treinamento de modelos de IA em saúde. Um modelo treinado predominantemente em dados de homens brancos jovens de classe média pode ter desempenho significativamente inferior quando aplicado a outros grupos. Se a solução proposta pelo grupo será usada por ou para populações que podem estar sub-representadas nos dados disponíveis, isso precisa estar explícito nas hipóteses do canvas.

Se o projeto não usa IA, o Módulo 3 ainda é relevante de uma forma diferente: há alguma aplicação de IA que poderia adicionar valor ao problema que o grupo está resolvendo e que foi descartada por algum motivo? O descarte pode ser legítimo — talvez os dados não estejam disponíveis, talvez o problema não seja da natureza que a IA resolve bem, talvez o custo de desenvolvimento seja proibitivo para o estágio atual do projeto. Mas o descarte precisa ser consciente e fundamentado, não uma omissão por desconhecimento. O Módulo 3 deu ao grupo ferramentas para fazer essa avaliação de forma informada.

Do Módulo 4: telemedicina e o alcance da solução

O Módulo 4 abriu um mundo que muitos estudantes de medicina, ao iniciar a disciplina, subestimam em sua complexidade: a telemedicina não é simplesmente “fazer consulta por videochamada”. É um campo com modalidades distintas (teleconsulta, telediagnóstico, telemonitoramento, teleconsultoria, segunda opinião formativa), com diferentes arquiteturas de comunicação (síncrona, assíncrona, store-and-forward), com uma história regulatória brasileira marcada por avanços acelerados durante a pandemia seguidos de consolidação normativa, e com implicações profundas para o paradoxo da equidade em saúde.

Para o projeto do seu grupo, a questão central que o Módulo 4 coloca é: onde a dimensão de “distância” — no sentido mais amplo, que inclui distância geográfica, distância econômica, distância de acesso a especialistas — é relevante para o problema que o grupo está tentando resolver?

Se o projeto tem um componente explícito de telemedicina, o Módulo 4 deveria ter fornecido ao grupo vocabulário técnico e regulatório para pensar com precisão sobre esse componente. Qual modalidade se aplica ao projeto — é uma teleconsulta, um sistema de telemonitoramento, uma plataforma de segunda opinião formativa? Qual arquitetura de comunicação — a interação entre médico e paciente é síncrona, exigindo presença simultânea, ou assíncrona, permitindo que o profissional responda em momentos diferentes do envio? Quais são as obrigações regulatórias específicas que o projeto precisará cumprir, à luz da Resolução do CFM vigente e da legislação de proteção de dados?

Se o projeto não tem um componente explícito de telemedicina, a pergunta ainda vale ser feita: o problema que o grupo está tentando resolver ocorre predominantemente em contextos presenciais, ou há uma dimensão de acesso que poderia ser endereçada por alguma forma de atendimento remoto? Um sistema de apoio diagnóstico para clínicas de atenção primária pode ter um alcance muito maior se for acessível remotamente por unidades em regiões com menos infraestrutura tecnológica — mas essa possibilidade tem custos e complexidades regulatórias específicos.

O paradoxo da equidade é talvez o ponto mais importante que o Módulo 4 colocou na mesa para qualquer projeto de HealthTech. Soluções tecnológicas em saúde têm uma tendência estrutural de beneficiar primeiro quem já tem mais acesso: pessoas com smartphones de alta capacidade, com conectividade estável, com literacia digital, com acesso prévio a serviços de saúde. Quando uma HealthTech atinge escala, ela pode estar amplificando desigualdades existentes em vez de reduzi-las — não por má intenção dos fundadores, mas por uma lógica de adoção que privilegia quem já está bem servido.

O grupo precisa ser honesto sobre essa questão. A solução que está desenvolvendo beneficia quem, concretamente? Existe algum design do produto que poderia torná-la mais acessível aos grupos que mais precisam dela — mesmo que isso aumente a complexidade ou reduza as margens? E, se o projeto está conscientemente focado num segmento de mercado de alto poder aquisitivo (o que pode ser uma decisão estratégica legítima), isso está claro nas hipóteses do canvas?

---

Como revisar o canvas de hipóteses

A sessão de 140 minutos que se segue à palestra é o coração operacional deste módulo. Você e seu grupo terão tempo para fazer algo que a metodologia Lean Startup considera fundamental e que raramente acontece de forma estruturada sem um momento dedicado: revisar o canvas de hipóteses à luz do que foi aprendido.

Mas “revisar o canvas” precisa ser entendido com precisão, porque existem formas equivocadas de fazer isso que parecem revisão e não são.

O que significa revisar versus jogar fora

A primeira confusão a evitar é entre revisar e refazer do zero. Grupos que chegam ao quinto módulo com um canvas que não foi testado tendem, às vezes, a querer recomeçar do zero — mudar completamente o tema, abandonar o problema que escolheram, começar com um projeto diferente que parece mais promissor. Isso raramente é a resposta certa, e a razão é metodológica.

Recomeçar do zero não é pivotar — é fugir. Um pivô genuíno, que examinaremos em profundidade na seção seguinte, é motivado por aprendizado: o grupo descobriu que uma hipótese central era falsa, testou isso empiricamente e está mudando de direção com base nesse aprendizado. Recomeçar do zero sem ter testado nada é, na melhor das hipóteses, um reset que não incorpora o aprendizado acumulado. Na pior das hipóteses, é o mesmo ciclo repetido: novo projeto, novas hipóteses não testadas, novo conjunto de certezas sem fundamento.

O canvas que o grupo tem hoje, mesmo que cheio de imperfeições, tem um valor que o novo canvas não terá: ele representa quatro semanas de pensamento sobre um problema específico. Mesmo que algumas hipóteses estejam erradas, o ato de tê-las formulado e o processo de aprender mais sobre o problema produziram um conhecimento que precisaria ser reconstituído se o grupo começar do zero.

Os três tipos de atualização possível

Dentro da prática de revisão do canvas, existem três tipos de atualização qualitativamente diferentes, e reconhecer a diferença entre eles é importante para conduzir a revisão de forma produtiva.

O primeiro tipo é o refinamento de uma hipótese que era vaga. Neste caso, a hipótese original não estava errada — estava imprecisa. O grupo sabia que havia um problema de comunicação entre médicos de atenção primária e especialistas, mas não sabia exatamente em que ponto do processo a comunicação falhava com mais frequência. Depois de quatro semanas de estudo (e, idealmente, de algumas conversas com profissionais), o grupo agora sabe que o gargalo não é a comunicação em si, mas a ausência de um sistema estruturado para documentar a evolução do caso após o encaminhamento. A hipótese ficou mais precisa. Isso é refinamento.

O segundo tipo é a substituição de uma hipótese que se revelou falsa. Aqui, algo que o grupo acreditava ser verdadeiro mostrou-se incorreto — idealmente, porque o grupo coletou alguma evidência contrária. O grupo acreditava que médicos de atenção primária estariam dispostos a pagar diretamente por uma ferramenta de apoio à decisão clínica. Depois de aprender mais sobre como funciona o financiamento da atenção básica no Brasil, o grupo percebe que médicos de atenção primária raramente pagam por ferramentas de forma direta — o pagador relevante é o gestor municipal de saúde ou o plano de saúde que remunera os médicos. Isso não é um refinamento da hipótese original — é uma refutação que exige substituição por uma hipótese diferente sobre o cliente pagador. Isso é substituição.

O terceiro tipo é a adição de uma hipótese nova que não havia sido identificada antes. A estrutura do canvas nunca é exaustiva numa primeira versão — sempre há aspectos do problema, do mercado ou da solução que não foram capturados inicialmente. Depois de estudar os módulos de IA e telemedicina, o grupo percebe que a solução, para funcionar como proposto, depende de uma integração com o sistema de prontuário eletrônico usado pela rede de saúde onde seria implementada. Essa dependência técnica é uma hipótese nova — o grupo não tinha pensado nela antes — que precisa estar no canvas porque, se a integração for impossível ou muito custosa, isso compromete a viabilidade do produto. Isso é adição.

Cada um desses três tipos de atualização tem implicações diferentes para o trabalho subsequente do grupo. Refinamentos geralmente indicam que a validação da hipótese refinada pode continuar no caminho que já estava sendo planejado. Substituições indicam que o grupo precisa recomeçar a validação de uma hipótese desde o início. Adições indicam que há novas hipóteses a testar que o grupo ainda nem começou a explorar.

Os dois erros simétricos da revisão

Há dois erros opostos que grupos cometem quando revisam o canvas, e ambos prejudicam o aprendizado de formas diferentes.

O primeiro erro é a defensividade. Quando um grupo passou semanas desenvolvendo um canvas, há um investimento emocional e cognitivo naquelas hipóteses. Mudá-las parece, inconscientemente, admitir que o trabalho das semanas anteriores foi em vão. Grupos defensivos olham para novas informações que contradizem suas hipóteses e encontram justificativas para descartá-las: “esse caso é específico demais”, “essa fonte não é confiável”, “a nossa solução é diferente dos exemplos que contradizem a hipótese”. A defensividade é o maior inimigo do aprendizado numa startup — e é um inimigo que fica mais forte na medida em que o grupo investe mais tempo e energia no canvas original.

O segundo erro, aparentemente oposto, é a impulsividade. Grupos impulsivos mudam tudo a cada nova informação, sem ter testado nenhuma hipótese de forma sistemática. Ouviram que a regulamentação da ANVISA para software médico é complexa e mudaram todo o modelo de negócio antes de entender o que a regulamentação realmente exige do tipo específico de produto que estão desenvolvendo. Leram um artigo sobre um startup que fracassou com um modelo parecido e abandonaram o canvas inteiro antes de avaliar se as razões do fracasso se aplicam ao seu contexto. A impulsividade produz instabilidade — cada semana o canvas é diferente do anterior, e o grupo nunca acumula aprendizado suficiente sobre nenhuma hipótese específica.

A postura correta está entre os dois extremos: receber novas informações com abertura genuína, mas processá-las metodicamente antes de atualizar o canvas. A pergunta relevante, quando uma nova informação chega, não é “isso muda o meu canvas?” mas “isso é evidência suficientemente forte para refutar uma hipótese que eu ainda não testei diretamente, ou é mais informação que deveria influenciar como planejo testar essa hipótese?”

Como registrar o raciocínio por trás das atualizações

Uma prática que muitos grupos negligenciam, mas que tem valor alto para o aprendizado a longo prazo, é registrar não apenas o que mudou no canvas, mas por que mudou. Isso não precisa ser elaborado — pode ser uma nota curta junto a cada hipótese atualizada: “mudamos X porque Y nos levou a perceber Z”.

O valor desse registro é múltiplo. Ele força a equipe a ser explícita sobre o raciocínio que motivou a atualização — o que previne mudanças impulsivas baseadas em sensação, porque formular o raciocínio por escrito frequentemente revela que o raciocínio não é tão sólido quanto parecia na cabeça. Ele cria um histórico do processo de aprendizagem do grupo, que tem valor pedagógico e que pode ser útil para o professor entender como o grupo está evoluindo. E ele serve como âncora para conversas futuras: quando o grupo estiver tentando decidir, no Módulo 9, se deve pivotar ou perseverar, ter um registro de como chegou às hipóteses atuais e por que mudou as anteriores é uma ferramenta de deliberação inestimável.

O estado atual do conhecimento, não o estado das esperanças

Uma distinção útil para guiar a revisão do canvas é a distinção entre hipóteses confirmadas, hipóteses riscadas (refutadas) e hipóteses indecididas. Um canvas bem mantido deveria refletir, a qualquer momento, o estado atual do conhecimento do grupo — não o estado das suas esperanças ou dos seus planos.

Hipóteses confirmadas são aquelas para as quais o grupo coletou evidência suficiente para aumentar significativamente a confiança na premissa. Isso não significa certeza absoluta — significa que os dados disponíveis apontam consistentemente na mesma direção e que o custo de continuar investigando aquela hipótese específica provavelmente não se justifica em relação aos benefícios de investir o tempo em testar outras.

Hipóteses riscadas são aquelas que o grupo testou e que se revelaram falsas. Elas devem permanecer visíveis no canvas — não deletadas — porque têm valor informativo. Saber que uma hipótese foi testada e refutada é informação sobre o espaço de soluções. Se um grupo futuro perguntar “já pensaram em X?”, a hipótese riscada é a resposta documentada de que sim, pensaram, testaram, e descobriram que não se sustenta.

Hipóteses indecididas são a maioria num canvas bem honesto: premissas que o grupo acredita serem provavelmente verdadeiras, mas que ainda não testou de forma direta. Elas deveriam ser marcadas como tal — “acreditamos que X, mas ainda não testamos” — e o canvas deveria incluir pelo menos uma ideia de como a hipótese poderia ser testada.

O diagrama a seguir representa o ciclo de revisão do canvas como processo contínuo:

flowchart TD
    A([Hipótese inicial<br/>no canvas]) --> B{Há evidência<br/>disponível?}
    B -- Não --> C[Planejar<br/>experimento<br/>de teste]
    C --> D[Executar<br/>experimento]
    D --> E{Resultado}
    E -- Confirma --> F([Hipótese<br/>confirmada<br/>no canvas])
    E -- Refuta --> G([Hipótese<br/>riscada<br/>no canvas])
    E -- Inconclusivo --> H[Refinar<br/>experimento]
    H --> D
    B -- Sim --> I{Evidência<br/>suficiente?}
    I -- Não --> C
    I -- Sim --> J{Aponta qual<br/>direção?}
    J -- Confirma --> F
    J -- Refuta --> G
    G --> K([Nova hipótese<br/>formulada])
    K --> B
    F --> L{Há novas<br/>hipóteses<br/>derivadas?}
    L -- Sim --> K
    L -- Não --> M([Canvas<br/>atualizado<br/>e registrado])

---

O pivô: quando mudar de direção não é fracasso

Nenhum conceito da metodologia Lean Startup é mais mal compreendido — e mais mal usado — do que o pivô. Nas conversas cotidianas sobre startups, “pivotar” tornou-se um eufemismo para “desistir do que estava fazendo e tentar outra coisa”. Nessa versão popular, pivotar é o que startups fazem quando fracassam. Não é isso.

A definição rigorosa de Eric Ries é precisa: pivô é uma mudança estruturada de estratégia, baseada em aprendizado validado, que mantém um pé firme em alguma coisa que o time aprendeu que funciona. A palavra-chave da definição é “estratégia”, não “visão”. O pivô muda o como, não necessariamente o quê ou o porquê. Uma startup que pivota continua tentando criar o valor que se propôs a criar — ela está mudando a forma de criar esse valor porque aprendeu que a forma anterior não funcionava.

Os tipos de pivô segundo Eric Ries

Ries identificou, com base na observação de dezenas de startups, um conjunto de tipos de pivô que descreve as mudanças estruturais mais comuns que startups fazem. Conhecer esses tipos tem valor prático porque ajuda a distinguir, numa situação concreta de decisão, que tipo de mudança está sendo considerada — o que, por sua vez, ajuda a avaliar se a mudança é motivada por aprendizado genuíno ou por outras razões.

O pivô de zoom-in ocorre quando uma feature específica do produto se torna o produto inteiro. A startup percebeu que, de tudo o que estava construindo, havia uma funcionalidade específica que os usuários valorizavam de forma desproporcional e que resolvia, por si só, um problema suficientemente importante para justificar um produto dedicado. Em vez de continuar construindo o produto completo original, a startup foca toda a sua energia naquela funcionalidade específica.

O pivô de zoom-out é o inverso: o produto que estava sendo construído se revela insuficiente, e a startup percebe que precisa de uma plataforma mais ampla para resolver o problema adequadamente. O que era pensado como produto vira uma feature de algo maior.

O pivô de segmento de clientes ocorre quando a startup percebe que o produto que está construindo resolve um problema real — mas não para o segmento de clientes que originalmente imaginou. O produto funciona muito bem para um grupo diferente do previsto, e a startup decide focar nesse grupo diferente.

O pivô de necessidade do cliente é mais profundo: a startup descobre que o segmento de clientes com quem está trabalhando tem um problema real e urgente, mas que não é o problema que a startup estava tentando resolver. O grupo de usuários é o mesmo, mas o problema que vale a pena resolver é diferente. Isso exige repensar todo o produto, mas mantém o conhecimento acumulado sobre o segmento.

O pivô de plataforma acontece quando uma solução desenvolvida para uso interno pela startup — uma ferramenta, um algoritmo, uma infraestrutura — revela-se mais valiosa como plataforma para terceiros do que como produto para o usuário final que estava sendo imaginado originalmente.

O pivô de arquitetura de negócio captura uma mudança no modelo fundamental de como a empresa gera valor: de um modelo de alto volume e baixa margem para um modelo de baixo volume e alta margem, ou vice-versa. No contexto de HealthTechs, isso poderia ser a transição de um modelo baseado em volume de transações (muitas consultas de baixo custo) para um modelo baseado em contratos anuais de alto valor com sistemas de saúde.

O pivô de captura de valor aborda como a empresa monetiza o valor que cria — não o modelo de negócio em si, mas o mecanismo de geração de receita. Uma startup que começou tentando cobrar dos pacientes e descobre que quem paga de fato é o plano de saúde está fazendo um pivô de captura de valor.

O pivô de motor de crescimento identifica a mudança no mecanismo primário de expansão da startup: de crescimento viral (usuários trazem outros usuários) para crescimento pago (investimento em marketing e vendas) ou crescimento pegajoso (retenção de usuários existentes), ou entre qualquer combinação desses motores.

O pivô de canal ocorre quando a startup descobre que o canal de distribuição original não funciona para chegar ao cliente, mas que um canal diferente funcionaria. Uma HealthTech que estava tentando vender diretamente para médicos e descobre que o canal mais eficaz é uma parceria com distribuidores de equipamentos médicos está fazendo um pivô de canal.

O custo do pivô e a importância do timing

Uma das observações mais práticas de Ries é que o custo de pivotar cresce com o tempo e com o investimento. Pivotar nos primeiros meses de uma startup é relativamente barato — o produto ainda não foi completamente construído, nenhum contrato de longo prazo foi assinado, a equipe não está tão emocionalmente comprometida com uma direção específica. Pivotar depois de dois anos, com um produto completamente desenvolvido, uma equipe de vinte pessoas contratadas para aquele produto específico e clientes que pagam pelo que está sendo entregue, é muito mais custoso em todas as dimensões.

Isso cria um imperativo metodológico claro: testar as hipóteses mais frágeis e mais centrais o mais cedo possível. Quanto mais cedo um grupo descobre que uma premissa central é falsa, menor é o custo do pivô necessário. Quanto mais tarde essa descoberta acontece — frequentemente porque o grupo evitou testar premissas desconfortáveis —, maior é o custo.

A distinção entre uma hipótese “central” e uma hipótese “periférica” é importante aqui. Hipóteses centrais são aquelas cuja falsidade comprometeria toda a lógica do projeto. Se o projeto é construído sobre a premissa de que médicos de atenção primária têm tempo suficiente durante as consultas para interagir com um sistema de apoio à decisão, e essa premissa for falsa, toda a arquitetura do produto precisa ser repensada. Uma hipótese periférica, por sua vez, é aquela cuja falsidade exigiria ajustes, mas não uma mudança fundamental na lógica do projeto. Se a premissa sobre a cor da interface ou sobre o nome do produto for falsa, o ajuste é trivial.

A prioridade de teste deveria, portanto, ser inversamente proporcional à centralidade da hipótese: as hipóteses mais centrais — e mais arriscadas — deveriam ser testadas primeiro, mesmo que sejam as mais difíceis de testar.

Como distinguir um pivô legítimo de uma fuga da realidade

Há uma diferença qualitativa entre pivotar e fugir. O pivô é motivado por aprendizado: o grupo coletou evidência que refuta uma hipótese central e está mudando de direção porque sabe algo que não sabia antes. A fuga é motivada por dificuldade de execução: o grupo está tendo dificuldade de implementar o plano original e está mudando de direção não porque aprendeu que o plano estava errado, mas porque o plano está sendo difícil de executar.

A distinção importa porque fuga disfarçada de pivô não resolve o problema — ele segue o grupo para o próximo canvas, e para o próximo, e para o próximo. Um grupo que muda de direção porque “está difícil” tende a descobrir que o novo canvas também está difícil, e muda novamente. O padrão é o mesmo: hipóteses não testadas, dificuldade de execução percebida como invalidação da hipótese, mudança de direção sem aprendizado real.

A pergunta de controle é simples: “o que especificamente aprendemos que nos leva a acreditar que a direção anterior estava errada?” Se a resposta descreve evidência concreta — conversas com usuários, dados de uso, feedback de profissionais —, o pivô provavelmente é legítimo. Se a resposta descreve dificuldades de implementação, conflitos internos da equipe ou falta de motivação para o tema original, o pivô é provavelmente uma fuga.

Pivôs famosos e o que eles ensinam

Alguns dos pivôs mais conhecidos na história do empreendedorismo tecnológico são instrutivos precisamente porque mostram como mudanças de direção baseadas em aprendizado produziram empresas que não teriam existido sem elas.

O Instagram começou como Burbn, um aplicativo de check-in que permitia que usuários registrassem onde estavam, compartilhassem planos de atividades e fizessem check-in em locais específicos — muito similar ao que o Foursquare fazia na época. O produto tinha uma funcionalidade de compartilhamento de fotos que os usuários estavam utilizando muito mais do que qualquer outra. Os fundadores Kevin Systrom e Mike Krieger analisaram os dados de uso e fizeram um pivô de zoom-in: removeram quase todas as funcionalidades do Burbn, mantiveram apenas o compartilhamento de fotos com filtros, e lançaram um produto completamente focado — que virou o Instagram. O pivô foi motivado por dados concretos de uso, não por intuição ou por dificuldade de implementar as outras funcionalidades.

O Slack começou como a ferramenta de comunicação interna da empresa de jogos Glitch, desenvolvida para facilitar a comunicação entre a equipe distribuída que estava construindo o jogo. O jogo fracassou — não encontrou mercado suficiente —, mas a ferramenta de comunicação que a equipe havia construído para uso próprio revelou-se extraordinariamente valiosa. Os fundadores fizeram um pivô de plataforma: abandonaram o jogo, transformaram a ferramenta interna em produto para outras empresas e lançaram o Slack. O pivô não foi uma escolha diante do fracasso — foi um reconhecimento de que o valor que a equipe havia criado estava no lugar errado do que estava sendo construído.

O YouTube foi fundado em 2005 por Chad Hurley, Steve Chen e Jawed Karim como um serviço de vídeo para encontros românticos — uma espécie de versão em vídeo dos serviços de dating da época, com o slogan “Tune In, Hook Up”. O produto não decolou como serviço de dating, mas as métricas mostravam que as pessoas estavam usando a plataforma para compartilhar todo tipo de vídeo — não apenas vídeos de apresentação pessoal. Os fundadores fizeram um pivô de segmento de clientes e de necessidade do cliente simultaneamente: abriram a plataforma para qualquer tipo de vídeo e para qualquer usuário, não apenas para quem buscava relacionamentos. O YouTube que conhecemos é o resultado desse pivô.

Cada um desses exemplos compartilha uma característica: os fundadores olharam para os dados de comportamento real dos usuários, identificaram onde o valor estava sendo criado de forma não antecipada, e tiveram a disposição de abandonar o plano original para seguir o aprendizado. Nenhum deles mudou porque o plano era difícil de executar. Todos mudaram porque aprenderam algo concreto que apontava numa direção diferente.

Quando não pivotar: perseverar é também uma resposta metodológica

O pivô é frequentemente romantizado na cultura de startups como sinal de agilidade e abertura ao aprendizado. Mas a metodologia Lean Startup não prescreve pivotar com frequência — ela prescreve pivotar quando o aprendizado indica que uma hipótese central é falsa. Quando as hipóteses ainda não foram testadas, pivotar é prematuro.

Perseverar quando há hipóteses ainda não testadas não é teimosia — é metodologia. Se o grupo ainda não conversou com usuários reais, ainda não fez nenhum experimento que teste a hipótese de problema central, ainda não coletou nenhum dado sobre como potenciais clientes reagem à proposta de valor, então o canvas atual não foi refutado — simplesmente não foi testado. Mudá-lo nessa situação é pivotar sem aprendizado, o que, pela definição de Ries, não é pivotar. É apenas mudar.

O momento certo para considerar um pivô é quando o grupo tem evidência suficiente de que uma hipótese central é falsa — e quando a falsidade dessa hipótese é central o suficiente para que ajustes periféricos não sejam suficientes. Antes disso, a resposta metodológica é perseverar e testar.

---

Como se preparar para a aula

A aula do Módulo 5 tem dois blocos com finalidades muito diferentes. O primeiro bloco — 60 minutos de palestra com o Dr. Vitor Barion — exige de você uma postura de escuta ativa e orientada pelo projeto. O segundo bloco — 140 minutos de revisão do canvas — exige de você uma postura de análise crítica e disposição para ser honesto sobre o estado atual do seu projeto.

Ambos os blocos demandam preparação prévia, e essa preparação começa antes de entrar na sala de aula.

O que trazer para a aula

A versão atual do canvas de hipóteses do grupo é o artefato mais importante que você deve ter em mãos. Não uma versão que o grupo vai criar na manhã da aula, mas o canvas que foi sendo construído e atualizado ao longo dos módulos anteriores. Se o canvas existe apenas em formato digital, imprima-o ou garanta que todos os membros do grupo têm acesso a ele em seus dispositivos durante toda a aula. Trabalhar sem o canvas durante a sessão de revisão é como tentar reformar uma casa sem ter a planta em mãos.

A lista de perguntas para o palestrante. Cada estudante deveria chegar à aula com pelo menos três perguntas formuladas para o Dr. Barion — não genéricas sobre empreendedorismo, mas perguntas estratégicas que conectem a experiência do palestrante com desafios concretos do projeto do grupo. Escreva as perguntas antes da aula, depois de ter lido este material inteiro e de ter relido o canvas do grupo. Formular boas perguntas é um exercício de síntese: exige saber o que você já sabe, o que não sabe e o que o palestrante provavelmente sabe que você não saberia como descobrir de outra forma.

A anotação de pelo menos uma hipótese do canvas que ficou sem teste após os Módulos 1 a 4. Esta é uma forma de forçar uma reflexão honesta sobre o estado do projeto antes de chegar à aula. Qual hipótese do canvas o grupo formulou no início do semestre e que, até agora, não fez nada para testar? Por que não testou? O que seria necessário para testá-la? Ter essa hipótese identificada e na cabeça quando você ouvir a palestra do Dr. Barion aumenta muito a chance de que algo que ele diga seja diretamente relevante para aquela hipótese específica.

Como ouvir a palestra com o projeto em mente

A instrução mais importante para a palestra é também a mais simples: enquanto o Dr. Barion fala, mantenha o canvas do grupo como filtro ativo de escuta. Não apenas anote o que é interessante em abstrato — anote o que é relevante para o projeto específico do grupo.

Uma forma prática de fazer isso é dividir as anotações em três colunas. Na primeira coluna, o que o palestrante disse. Na segunda coluna, qual hipótese do canvas aquilo toca. Na terceira coluna, o impacto: aquilo confirma, refina ou contradiz a hipótese identificada? Este sistema simples de anotação obriga uma análise em tempo real que, de outra forma, frequentemente não acontece — você escuta a palestra toda, acha tudo muito interessante, e quando começa a sessão de revisão do canvas não consegue lembrar o que especificamente era relevante para o projeto.

A relação entre os módulos anteriores e o arco do semestre

Vale a pena, neste momento, ver o Módulo 5 não apenas como um ponto de parada, mas como um ponto de inflexão dentro de um arco maior. Os quatro módulos anteriores construíram um repertório conceitual: a crítica à neutralidade da tecnologia, a metodologia de gestão de incerteza das startups, os fundamentos da inteligência artificial aplicada à clínica e a complexidade regulatória e ética da telemedicina. Esse repertório não é uma coleção de informações separadas — é uma estrutura de perguntas que um médico inovador precisa saber fazer.

Os módulos que virão depois do Módulo 5 vão aprofundar tecnologias específicas — agentes de inteligência artificial, realidade virtual e aumentada, biotecnologia, segurança da informação — e, em paralelo, conduzirão o projeto da startup através de etapas que se tornam progressivamente mais exigentes: design thinking e empatia, mapa de empatia e jornada do usuário, ideação, solução e proposta de valor, prototipação, validação e modelo de negócio.

Para aproveitar bem esses módulos futuros, você precisa chegar a eles com o canvas em bom estado — não perfeito, mas honesto. Um canvas honesto é aquele que distingue o que o grupo sabe do que acredita, e que registra o estado atual do conhecimento em vez de registrar apenas as esperanças do grupo. O trabalho desta semana é, em grande medida, trazer o canvas a esse estado de honestidade.

Há também uma dimensão de aprendizagem coletiva que merece atenção. A sessão de revisão do canvas não é um trabalho individual — é um trabalho de grupo. E grupos têm dinâmicas que podem facilitar ou dificultar o aprendizado honesto. Grupos com hierarquias informais muito marcadas tendem a ter canvas que refletem a visão de uma pessoa, não o aprendizado coletivo. Grupos com excesso de consenso tendem a ter canvas que registram o que todo mundo já concordava, não o que as evidências apontam. Um bom exercício durante a sessão de revisão é identificar explicitamente quais hipóteses ainda não foram questionadas de forma crítica dentro do grupo — e garantir que cada membro da equipe tenha voz ativa na revisão de pelo menos uma hipótese que considera frágil.

A palestra do Dr. Barion, nesse sentido, pode funcionar como um catalisador externo. Às vezes, um questionamento que vem de fora do grupo — de alguém que não tem compromisso emocional com o canvas — é mais fácil de ser ouvido do que o mesmo questionamento vindo de dentro. Se o palestrante disser algo que um membro do grupo já havia dito internamente mas não havia sido levado suficientemente a sério, esse é o momento de retomar aquela observação com a atenção que ela merece.

O que fazer com o desconforto de ouvir algo que contradiz o seu projeto

É muito provável que, em algum momento da palestra, o Dr. Barion diga algo que contradiga diretamente uma premissa importante do seu canvas. Talvez ele descreva uma barreira que o seu grupo não havia considerado. Talvez ele relate um fracasso que é estruturalmente similar ao modelo que o grupo está propondo. Talvez ele questione, explícita ou implicitamente, a premissa de que o problema que o grupo identificou é suficientemente urgente para justificar uma solução tecnológica.

A reação natural é defensiva: “o contexto dele era diferente”, “nossa solução considera esse problema”, “ele não conhece o nosso projeto especificamente”. E pode ser que essas reações estejam corretas — a experiência do palestrante não é uma lei universal, e você tem o direito e o dever de pensar criticamente sobre o que ele diz.

Mas antes de ativar a defesa, faça uma pausa e considere a possibilidade de que ele esteja certo. Se um médico que percorreu o caminho do empreendedorismo em saúde está dizendo algo que contradiz uma premissa do seu canvas, isso é informação de alta qualidade — talvez a mais alta qualidade disponível naquele momento. A postura produtiva não é nem aceitar tudo acriticamente nem rejeitar de pronto o que contradiz suas crenças. É anotar a contradição com precisão, reservar o julgamento para a sessão de revisão, e tratá-la como uma hipótese a ser investigada: “o palestrante sugeriu que X. Nossa premissa é não-X. O que precisaríamos ver para confirmar ou refutar qual das duas está correta?”

O desconforto de ouvir algo que contradiz o projeto não é uma ameaça — é exatamente o tipo de informação que a metodologia Lean Startup chama de aprendizado validado em estado bruto. Trate-o como ouro.

---

Resumo do Módulo 5: o que você precisa levar para a aula

Este módulo foi diferente dos anteriores em estrutura, mas não em exigência. Para aproveitar ao máximo a aula, você precisará ter feito três coisas antes de entrar na sala.

A primeira é ter relido o canvas de hipóteses do grupo com os olhos dos Módulos 1 a 4. Não basta tê-lo em mãos — você precisa ter refletido sobre o que cada módulo significou para as hipóteses que o grupo formulou. A seção 3 deste material é o guia para essa reflexão.

A segunda é ter formulado pelo menos três perguntas para o Dr. Vitor Barion que conectem a sua experiência com desafios concretos do seu projeto. Perguntas genéricas são desperdício de um recurso escasso — o tempo de um praticante que percorreu o caminho que você quer percorrer.

A terceira é ter identificado pelo menos uma hipótese do canvas que permanece indecidida — que não foi confirmada nem refutada porque o grupo ainda não a testou. Essa hipótese é o ponto de entrada mais importante para a sessão de revisão do canvas que se segue à palestra.

---

Mapa dos tipos de pivô e os exemplos canônicos

O diagrama abaixo sintetiza os nove tipos de pivô identificados por Eric Ries, organizados por dimensão da mudança, com os exemplos históricos correspondentes. Use-o como referência ao avaliar se o seu projeto precisa de algum tipo de pivô neste momento do semestre.

mindmap
  root((Pivô))
    Produto
      Zoom-in
        Uma feature vira o produto inteiro
        Exemplo: Instagram vira apenas fotos
      Zoom-out
        O produto vira feature de algo maior
        Exemplo: produto específico se torna plataforma
      Plataforma
        Ferramenta interna vira produto externo
        Exemplo: Slack nasce da ferramenta interna do Glitch
    Mercado
      Segmento de clientes
        Mesmo produto, público diferente
        Exemplo: YouTube abre para todos, não só dating
      Necessidade do cliente
        Mesmo público, problema diferente
        A solução resolve outro problema do mesmo usuário
      Canal
        Mesmo produto, distribuição diferente
        Parceiros, revendedores, plataformas
    Modelo de negócio
      Arquitetura de negócio
        Alto volume e baixa margem versus baixo volume e alta margem
      Captura de valor
        Como a empresa é remunerada pelo valor que cria
      Motor de crescimento
        Viral versus pago versus pegajoso

---

Uma reflexão final antes da aula

Você chegou ao quinto módulo de uma disciplina que foi concebida para ser diferente de qualquer outra que você provavelmente fez até aqui. Não é uma disciplina de conteúdo acumulativo no sentido tradicional — ela é um percurso de construção de capacidade analítica e prática. O projeto da startup que o seu grupo está desenvolvendo não é um exercício separado do conteúdo: é o lugar onde o conteúdo se torna real.

O que este módulo pede de você é, em essência, a mesma coisa que a metodologia que você aprendeu pede de qualquer empreendedor: seja honesto sobre o que sabe e sobre o que não sabe, receba informação nova com abertura genuína e use o que aprender para tomar decisões melhores. Isso é mais fácil de escrever do que de fazer. Mas a prática começa aqui.