Design Thinking, Lean Startup e Agile: como combinar cada método em projetos universitários

Por que existem três métodos “certos” ao mesmo tempo?

Se você já se pegou em uma reunião de projeto ouvindo alguém defender Design Thinking com a mesma paixão com que outra pessoa defende Lean Startup, enquanto um terceiro jura que só existe Agile, você não está sozinho. Para o estudante que circula entre disciplinas de Administração, Design, Engenharias e Comunicação, a sensação é de ter três manuais de instruções diferentes para montar o mesmo móvel.

O ponto é que Design Thinking, Lean Startup e Agile nasceram em contextos distintos, com perguntas diferentes em mente. Em vez de disputar qual é a “melhor” metodologia, faz mais sentido perguntar: qual delas responde melhor ao tipo de incerteza que o meu projeto tem hoje? Em alguns momentos, você não sabe ainda qual problema vale a pena resolver. Em outros, já tem uma hipótese de solução e quer testar se alguém pagaria por isso. Em fases mais avançadas, a questão vira: como entregar isso de forma confiável, rápida e contínua?

Este post parte dessa lógica: cada abordagem é uma lente. Olhar um TCC, uma disciplina de projeto interdisciplinar ou uma iniciativa de startup universitária por lentes diferentes muda o tipo de pergunta que você faz, o tipo de experimento que conduz e, por consequência, o tipo de resultado que consegue. Em vez de decorar jargões, a proposta aqui é entender como pensar como um designer, como um empreendedor enxuto e como um time ágil — e, principalmente, quando ativar cada “modo mental” ao longo do seu projeto.

Design Thinking: quando o problema ainda é nebuloso

Design Thinking é, essencialmente, uma metodologia para reduzir a incerteza sobre o problema. Seu foco não é código, não é planilha, e muitas vezes nem é tecnologia. O foco é gente: entender comportamentos, motivações, obstáculos invisíveis no cotidiano de usuários reais. Quando um projeto nasce com um enunciado genérico — “melhorar a experiência do aluno com a biblioteca da universidade”, por exemplo —, o Design Thinking entra como um telescópio apontado para a vida real, não para o plano de negócios.

Nesse contexto, etapas como imersão, pesquisa qualitativa, cocriação e prototipagem rápida deixam de ser palavras da moda e passam a ser ferramentas pragmáticas para uma pergunta central: o que realmente está acontecendo aqui? Em um projeto de extensão sobre mobilidade no campus, por exemplo, entrevistas em profundidade com alunos, motoristas de aplicativo, funcionários e professores podem revelar que o maior “problema de transporte” não é a falta de ônibus, mas a insegurança em determinados trajetos à noite. Essa descoberta raramente aparece em um formulário de múltipla escolha.

Uma característica importante para o estudante é que Design Thinking aceita e até exige ambiguidade no começo. Os primeiros protótipos muitas vezes são toscos: roteiros de serviço desenhados à mão, fluxos em papel colados na parede, simulações encenadas em sala de aula. Isso é intencional. Ao manter tudo barato e reversível, você pode testar rapidamente se as pessoas entendem a proposta, se se sentem confortáveis, se veem valor. Em um curso de Design ou Publicidade, isso pode significar prototipar uma jornada de atendimento da clínica-escola; em Engenharia, pode ser simular com LEGO o fluxo de um laboratório de prototipagem.

Use Design Thinking quando: a definição do problema é vaga, há muitos atores envolvidos, os impactos são mais comportamentais do que puramente técnicos, e você precisa descobrir o problema certo antes de se apaixonar por uma solução.

Lean Startup: quando a dúvida é se alguém vai querer (e pagar)

Se o Design Thinking ajuda a esclarecer qual problema é relevante para quem, o Lean Startup entra em cena quando surge a pergunta econômica: há um modelo viável de negócio aqui? Ele foi concebido em um ambiente de startups de tecnologia, mas seus princípios funcionam muito bem para TCCs, empresas juniores e projetos incubados em universidades que já têm uma hipótese de solução e de cliente em mente.

O coração do Lean Startup é o ciclo Construir–Medir–Aprender. Em vez de passar meses elaborando um plano de negócios detalhado, a lógica é: crie um Produto Mínimo Viável (MVP) — a menor versão da sua solução capaz de gerar uma medição confiável sobre interesse e comportamento do usuário —, lance para um grupo pequeno de pessoas e observe o que acontece. A ênfase não é construir “algo completo”, mas construir algo suficientemente bom para testar uma hipótese crítica. Essa hipótese geralmente tem a forma: “Se oferecermos X para o perfil Y, então eles irão realizar a ação Z”.

Em um contexto universitário brasileiro, isso pode ser um aplicativo para gestão de ligas acadêmicas. Em vez de desenvolver o sistema inteiro, um grupo de alunos de Sistemas de Informação pode começar com uma landing page explicando o serviço, um formulário de cadastro e um protótipo de interface navegável sem backend completo. Se poucas ligas se cadastram, o problema pode não estar no código, mas na proposta de valor, no canal de aquisição ou até no fato de que o “cliente” certo não é a liga, e sim a coordenação de curso.

Lean Startup exige uma postura quase científica: definir hipóteses, operacionalizar em métricas, rodar experimentos e decidir com base em dados. Métricas de vaidade — número de curtidas, por exemplo — têm pouco valor se não estiverem ligadas a comportamentos que sustentam o modelo de negócio, como cadastros que viram uso recorrente, testes gratuitos que viram contratos, ou pilotos com a universidade que viram contratos pagos com outras instituições.

Use Lean Startup quando: o problema já está relativamente bem entendido, você tem uma proposta de valor minimamente clara, e precisa descobrir se existe tração de mercado, disposição a pagar, canais de aquisição e um caminho para sustentabilidade econômica do projeto.

Agile: quando o desafio é entregar com cadência e qualidade

Enquanto Design Thinking e Lean Startup estão muito preocupados com o que vale a pena criar, Agile foca em como organizar o trabalho para entregar valor de forma contínua e adaptável. Ele nasceu no desenvolvimento de software, mas os seus princípios têm se espalhado por laboratórios, agências experimentais de comunicação, núcleos de inovação de cursos de saúde e até por projetos interdisciplinares que precisam coordenar muitos entregáveis em pouco tempo.

Na prática, isso significa dividir o trabalho em ciclos curtos (sprints), com objetivos claros e um conjunto de tarefas priorizadas (backlog). Em vez de um plano semestral rígido, o time assume que haverá mudanças de entendimento, ajustes nos requisitos e imprevistos técnicos. A resposta não é tentar controlar tudo, mas criar uma cadência de inspeção e adaptação: ao fim de cada ciclo, revisa-se o que foi entregue, recolhe-se feedback dos usuários ou professores-orientadores, e replaneja-se a próxima iteração.

Em um projeto de disciplina de Engenharia de Software envolvendo uma solução para a secretaria acadêmica, por exemplo, um time ágil poderia organizar o semestre em sprints de duas semanas. Cada sprint teria um objetivo palpável — como implementar e testar o módulo de agendamento de atendimentos. Ao fim de cada ciclo, o time demonstra o que foi feito para os funcionários e anota comentários: telas confusas, campos faltando, relatórios pouco úteis. Isso retroalimenta o backlog e aumenta a chance de, ao final do semestre, entregar algo realmente utilizável, não apenas uma demonstração para banca.

Agile também é, em grande medida, sobre gestão de risco e de pessoas. Times ágeis transparentes em relação a impedimentos, débito técnico e capacidade de trabalho conseguem negociar escopo de forma honesta com orientadores e parceiros externos. Métodos como Scrum e Kanban fornecem rituais (reuniões rápidas diárias, revisões, retrospectivas) e artefatos visuais (quadros de tarefas, burndown charts) que ajudam a manter o grupo alinhado e a reduzir a famosa correria desesperada na última semana de aula.

Use Agile quando: o problema e a solução-base já são conhecidos, mas a implementação é complexa, envolve múltiplos componentes ou equipes, e você precisa de um sistema de gestão de fluxo de trabalho que acomode mudanças sem perder qualidade de entrega.

Como escolher: critérios práticos para projetos universitários

Na prática cotidiana de cursos de graduação, os três métodos se encontram em contextos muito específicos. Em um projeto de inovação em saúde pública conduzido por uma universidade federal, por exemplo, o ciclo pode começar com oficinas de Design Thinking em uma unidade básica de saúde, migrar para experimentos de Lean Startup ao testar a adesão a uma nova solução digital, e então estabilizar em um time ágil mantido pelo hospital universitário para evoluir a ferramenta. Para o estudante, a dificuldade é saber onde entrar em cada fase quando o tempo é curto e a nota depende de entregas bem definidas.

Uma forma objetiva de escolher a abordagem é mapear o tipo dominante de incerteza do seu projeto em cada momento:

• Incerteza sobre o problema: você não sabe se está atacando a dor mais relevante, ou se está enxergando o contexto real dos usuários. Aqui, o investimento em pesquisa qualitativa, observação em campo, cocriação e prototipagem exploratória — o território do Design Thinking — costuma ser o mais produtivo.
• Incerteza sobre o modelo de valor: você já tem um recorte claro de problema e uma hipótese de solução, mas não sabe se as pessoas usariam regularmente, pagariam por isso ou recomendariam. É nesse ponto que experimentos de Lean Startup com MVPs, landing pages, pilotos controlados e métricas comportamentais se tornam centrais.
• Incerteza sobre a execução: o valor é reconhecido, há usuários interessados, talvez já exista até um convênio ou contrato; o risco maior é atrasar, entregar com baixa qualidade ou não conseguir adaptar o sistema às mudanças de requisito. Aí faz sentido ativar práticas Ágeis, com sprints, backlog priorizado e revisões constantes.

Além do tipo de incerteza, considere também restrições típicas da vida universitária: calendário acadêmico, disponibilidade limitada de usuários reais, dependência de infraestrutura da instituição. Se você tem apenas um semestre para um projeto aplicado em uma escola pública parceira, talvez precise condensar a fase de Design Thinking em poucas semanas bem planejadas, definindo hipóteses-chave rapidamente para poder testar alguma forma de MVP ainda dentro do período letivo. Se está em uma empresa júnior com vários clientes pequenos, métodos Ágeis podem ser o “sistema operacional” do trabalho diário, enquanto atividades de Design Thinking e Lean Startup aparecem em momentos específicos de descoberta e proposição de novos serviços.

Construindo um roadmap híbrido: combinando Design Thinking, Lean Startup e Agile

Em vez de tratar Design Thinking, Lean Startup e Agile como se fossem religiões concorrentes, é mais útil enxergá-los como módulos de um mesmo sistema de inovação. Em um projeto complexo — por exemplo, desenvolver e implementar uma solução digital para apoiar a permanência estudantil em uma universidade brasileira —, é improvável que uma única metodologia dê conta de todas as fases, do entendimento da evasão à sustentação técnica da plataforma. O caminho mais robusto passa por articular as três abordagens em sequência, com sobreposições calculadas.

Um roadmap híbrido típico poderia começar com uma fase intensa de Design Thinking, em que estudantes de diferentes cursos realizam imersões com bolsistas, alunos trabalhadores, estudantes de primeira geração no ensino superior e setores administrativos. A partir dessas narrativas e mapeamentos de jornada, emergem problemas prioritários: dificuldades financeiras pontuais, falta de informação sobre serviços de apoio, sensação de isolamento. Em seguida, o grupo formula hipóteses de soluções e passa para uma fase Lean Startup, criando MVPs de serviços, como um canal digital simplificado para acesso a bolsas ou um sistema de alertas antecipados para riscos de evasão, e testando esses MVPs com grupos-piloto bem definidos.

À medida que algumas dessas soluções demonstram tração — mais alunos usando o canal, redução de desistências em determinados cursos, feedback qualitativo positivo —, um time menor pode assumir a responsabilidade de manter e evoluir o sistema em ciclos Ágeis. Nesse estágio, o foco desloca-se para priorizar funcionalidades no backlog, garantir estabilidade técnica, integrar com sistemas legados da universidade e responder a demandas de novos campi ou cursos. O que era um experimento de disciplina passa a ter vida própria no ecossistema da instituição.

Para o estudante, dominar esse raciocínio híbrido significa ser capaz de narrar o percurso metodológico do projeto: explicar por que começou com pesquisa empática, como traduziu descobertas em hipóteses de valor e quais ciclos de entrega iterativa sustentaram a implementação. Essa narrativa, além de fortalecer relatórios de TCC e apresentações para bancas, aproxima a prática acadêmica da forma como problemas de inovação são, de fato, tratados em empresas, órgãos públicos e organizações do terceiro setor no Brasil contemporâneo.

Conclusão

Ao enxergar Design Thinking, Lean Startup e Agile como peças complementares de um mesmo sistema, você ganha um vocabulário mais preciso para desenhar e justificar o percurso metodológico dos seus projetos universitários. Em vez de repetir rótulos, você passa a escolher conscientemente a ferramenta que melhor dialoga com o tipo de incerteza que enfrenta a cada etapa, aproximando sua prática acadêmica da forma como a inovação é conduzida em contextos profissionais.

A próxima oportunidade de aplicar esses conceitos pode estar no seu próximo TCC, em uma disciplina de projeto integrado ou em uma iniciativa de empreendedorismo dentro da universidade. Comece mapeando onde estão as maiores dúvidas do seu desafio atual, selecione a lente mais adequada para esse momento e avance em ciclos curtos de aprendizado: é assim que metodologias deixam de ser teoria de sala de aula e se tornam aliadas concretas na construção de soluções relevantes para a sociedade.