Atividades — Startup: Conceituar a HealthTech
Este conjunto de atividades orienta o trabalho do seu grupo neste módulo. Diferentemente dos módulos teóricos, as tarefas a seguir não têm uma resposta certa ou errada — têm uma qualidade de pensamento esperada. O que o professor avaliará não é se o problema que você escolheu é o melhor possível, nem se a solução que você imaginou é a mais inovadora. O que importa é se você pensou com rigor: se distinguiu o que sabe do que supõe, se articulou o problema com precisão suficiente para que ele seja investigável, e se construiu hipóteses testáveis. Leia o enunciado de cada tarefa com atenção antes de começar e retorne ao material do módulo sempre que precisar de orientação conceitual.
Tarefa 1 — Articulando o problema da sua startup
Contexto
O material deste módulo apresenta uma distinção que parece simples mas é difícil de aplicar: a diferença entre começar por um problema e começar por uma solução. A maioria dos grupos iniciantes começa pela tecnologia — “vamos fazer um aplicativo de IA” ou “vamos criar uma plataforma de telemedicina” — e então busca um problema que essa tecnologia poderia resolver. O material argumenta que essa ordem é problemática: a tecnologia não define o mercado nem o valor — o problema define.
Um problema bem articulado para uma startup tem quatro elementos: um usuário específico (não “pacientes em geral” ou “médicos no Brasil”), uma situação concreta (um contexto identificável no qual o problema ocorre), uma dificuldade ou dor claramente identificável (o que especificamente não funciona, falta ou causa sofrimento), e uma dimensão de consequência (o que acontece quando o problema não é resolvido — para o usuário, para o sistema de saúde, para a sociedade).
O que você deve fazer
Antes de preencher o canvas de hipóteses — que virá na próxima tarefa —, você e seu grupo precisam articular o problema que pretendem investigar com o máximo de precisão possível. Para isso, cada membro do grupo deve escrever individualmente, em texto dissertativo, um enunciado de problema segundo os quatro elementos descritos acima: quem é o usuário específico que vocês querem ajudar, em que situação concreta esse problema ocorre, qual é a dificuldade ou dor que esse usuário enfrenta, e quais são as consequências de o problema permanecer sem solução. Em seguida, o grupo se reúne, lê os enunciados individuais, discute as diferenças e convergências, e produz um enunciado coletivo — único, dissertativo — que o grupo considera o mais preciso e honesto possível no momento atual.
O enunciado coletivo deve ser escrito de forma que alguém de fora do grupo, sem conhecimento prévio da área, consiga entender com clareza qual é o problema, quem ele afeta, em que contexto ocorre e por que merece atenção. O enunciado não deve mencionar nenhuma solução tecnológica — apenas o problema. Se o grupo perceber que está difícil descrever o problema sem falar na solução, isso é um sinal importante: significa que o grupo ainda está pensando pela solução, não pelo problema.
Tarefa 2 — O canvas de hipóteses inicial
Contexto
O canvas de hipóteses é a ferramenta que o material apresenta para estruturar o pensamento de um grupo de startup antes de construir qualquer coisa. Sua função não é ter respostas definitivas — é organizar, de forma explícita e honesta, o que o grupo acredita sobre o problema, sobre o usuário e sobre a solução, separando claramente o que é fato verificado do que é hipótese (crença ainda não testada).
O material enfatiza que essa distinção é mais difícil do que parece. Uma afirmação como “pessoas com diabetes têm dificuldade de controlar a glicemia” pode parecer uma hipótese, mas é na verdade um fato verificável — há dados epidemiológicos que o confirmam. Já uma afirmação como “pacientes diabéticos prefeririam receber lembretes de medicação por aplicativo a receber ligações de um enfermeiro” é uma hipótese genuína — o grupo acredita nisso, mas não sabe com certeza; depende de quem é o paciente, de sua familiaridade com tecnologia, de sua preferência por contato humano, e assim por diante. O material também lembra que nem toda hipótese tem o mesmo peso: algumas, se falsas, invalidam todo o projeto; outras, se falsas, apenas exigem ajustes menores.
O que você deve fazer
Com base no enunciado de problema desenvolvido na Tarefa 1, o grupo elabora o canvas de hipóteses inicial, organizado em três colunas. A primeira coluna, “o que acreditamos sobre o problema”, deve conter as principais afirmações do grupo sobre a natureza, a frequência, a gravidade e as causas do problema identificado — distinguindo explicitamente, em cada afirmação, se ela é um fato verificável (com a fonte que o verifica) ou uma hipótese (crença do grupo não testada). A segunda coluna, “o que acreditamos sobre o usuário”, deve conter as afirmações do grupo sobre quem é esse usuário, o que ele faz, o que ele quer, o que o impede de resolver o problema por conta própria — novamente distinguindo fatos de hipóteses. A terceira coluna, “o que acreditamos sobre a solução”, deve conter o que o grupo imagina como solução possível, como ela funcionaria e por que seria melhor do que o que já existe — com a ressalva explícita de que essas afirmações são as mais especulativas das três colunas.
Ao final do canvas, o grupo deve escrever um parágrafo dissertativo respondendo à seguinte pergunta: das hipóteses listadas, qual é a mais arriscada — aquela que, se falsa, invalidaria o projeto inteiro? Esse parágrafo não pede uma solução; pede uma reflexão honesta sobre onde reside a maior incerteza do projeto.
Tarefa 3 — Desenhando o primeiro experimento de aprendizagem
Contexto
O material apresenta o ciclo construir-medir-aprender como a unidade básica de aprendizagem de uma startup. Mas o ciclo só tem valor se o que se constrói, o que se mede e o que se aprende estão conectados a uma hipótese específica. Um grupo que constrói um aplicativo completo para então descobrir que o problema que o aplicativo resolve não é tão relevante para o usuário fez o ciclo de trás para frente: construiu muito antes de aprender o suficiente para saber o que deveria construir.
O material apresenta o conceito de MVP — Produto Mínimo Viável — exatamente para resolver esse problema. Um MVP não é a versão mais simples do produto final; é o experimento que permite testar a hipótese mais importante com o menor custo e esforço possível. Um MVP pode ser uma página de internet que descreve o produto e mede quantas pessoas se cadastram, uma entrevista estruturada com usuários reais, um protótipo de papel que simula como o produto funcionaria, ou uma simulação manual do serviço antes de automatizá-lo. O que importa não é o produto em si, mas o aprendizado que ele gera sobre a hipótese testada.
O que você deve fazer
Partindo da hipótese mais arriscada identificada na Tarefa 2, o grupo deve projetar — em texto dissertativo — o experimento mais simples possível que permitiria saber, no menor tempo e com o menor custo possível, se essa hipótese é verdadeira ou falsa. Esse experimento é o MVP do grupo neste momento. O texto deve descrever com clareza: qual é a hipótese específica que o experimento testa; o que o grupo vai construir ou fazer para testá-la (não o produto final — o experimento mínimo); como o grupo vai medir o resultado (o que conta como confirmação e o que conta como refutação da hipótese, de forma que seja possível distinguir os dois sem ambiguidade); e o que o grupo vai aprender com o resultado — tanto se a hipótese for confirmada quanto se for refutada. O grupo também deve justificar por que esse experimento é mais eficiente do que simplesmente começar a construir o produto, aplicando os conceitos de aprendizagem validada discutidos no material.
Atenção: a pergunta não é “o que o grupo vai construir no semestre”. É “o que o grupo pode fazer nas próximas duas semanas, com os recursos que tem agora, para aprender se a hipótese mais importante é verdadeira”. O valor desta tarefa está na capacidade de pensar pequeno de forma inteligente — não na grandiosidade da visão.