Na aula passada, o dever era observar problemas reais no cotidiano. Hoje, esses problemas viram matéria-prima. Quem quer compartilhar, em uma frase, um problema que observou durante a semana?

Vocês formaram times e assinaram um contrato na Aula 1. Hoje é a primeira vez que esse contrato é testado de verdade: vocês vão precisar decidir, como time, quais problemas valem a pena perseguir.

Da aula passada

Hoje: de problema a oportunidade

dos fracassos de startups, segundo levantamento da CB Insights sobre centenas de casos reais, acontecem pela mesma razão: "ninguém precisava daquilo". Não é sobre execução ruim. É sobre validar o problema antes de construir.

Boas ideias raramente nascem de brainstorm. Nascem de alguém que vive um problema de perto, como Chesky e Gebbia viveram a falta de dinheiro para o aluguel, e decide resolver aquilo especificamente.

Em inglês, validated learning. Termo de Eric Ries, do movimento Lean Startup: o que você descobre testando com gente real vale mais do que qualquer opinião, por mais experiente que seja quem opina.

Antes de pensar em "o que eu vou construir", pergunte "que problema real eu observo, no meu dia a dia ou no de alguém perto de mim". A solução só faz sentido depois dessa resposta.

Chesky e Gebbia não escolheram hospedagem porque pesquisaram o mercado. Escolheram porque era o problema na frente deles naquela semana. Problemas próximos são mais fáceis de validar do que problemas distantes.

Cinco é uma referência, não uma regra rígida. Toyoda observou que, na prática, a causa raiz costuma aparecer por volta da quinta pergunta — nem antes (sintoma), nem depois (detalhe demais).

Um exemplo, passo a passo

1. 01"Meu aplicativo trava." Por quê?
2. 02A tela demora para carregar.
3. 03Por quê?
4. 04Busca dados demais de uma vez.
5. 05Por quê?
6. 06Não existe filtro.
7. 07Por quê?
8. ↳Ninguém perguntou ao usuário o que ele precisa ver primeiro.

A primeira resposta a um "por quê" quase sempre é um sintoma, não uma causa. Quem para aí resolve o problema errado, e ele volta a aparecer semanas depois, de outra forma.

Antes de decidir qual problema atacar primeiro, o time avalia cada ideia em 3 critérios: o tamanho do impacto na vida de quem sofre, a frequência com que o problema aparece, e a proximidade do time com aquele problema.

O quanto a vida de quem sofre o problema melhora se ele for resolvido. Um problema que economiza 5 minutos tem menos impacto que um que evita perder dinheiro todo mês, como as taxas bancárias que motivaram o Nubank.

Com que regularidade o problema aparece na vida de quem sofre. Cartão de crédito é usado todo mês, por quase todo adulto — frequência altíssima. Um problema raro, mesmo que grave, compete pior nesse critério.

O quanto o time já vive ou entende aquele problema de perto. Vélez enfrentava a burocracia bancária brasileira na própria rotina — não precisou imaginar a dor do cliente, ele era o cliente.

Levantamento de problemas

1. 1Cada integrante compartilha, um de cada vez, os problemas que observou durante a semana.
2. 2O time anota todos, sem descartar nenhum ainda — mesmo os que parecem bobos.

Nome do time. As 3 ideias priorizadas. Qual delas o time acredita mais, e por quê.