Falhar rápido é o mantra do momento.
Principalmente se estamos falando de software. Sinceramente, se esse é o grande propósito, basta desenvolvermos produtos exclusivamente a partir de adivinhações e crenças próprias. O fracasso vai ser garantido, depois só precisamos fazer isto rapidamente e, consequentemente, de qualquer jeito.
Mas embora falhar rápido seja o mantra, empresas que muito bem sucedidas e orientadas ao design como InVision, Intercom, Basecamp e Google estão fazendo justamente o contrário. Em vez de sair “fazendo” e falhando rápido, elas estão investindo cada vez mais em pesquisa.
Analisar dados de uso de seus aplicativos, montar sistemas de análise e coleta de feedbacks e falar constantemente com clientes são exemplos de pesquisa aplicada ao desenvolvimento de produto.
Pesquisa? Isso não é coisa de empresas grandes?
Sim… e não.
De fato, empresas mais consolidadas usualmente investem mais em pesquisa. Mas isto não quer dizer que startups e empresas menores não possam desfrutar dessa fonte. Muito pelo contrário, enquanto ainda se está constantemente levantando e testando hipóteses, a pesquisa pode trazer muito valor.
Tudo é uma questão de escolher adequadamente a técnica de pesquisa e saber incorporá-la ao lean.
Já leu o livro “A Startup Enxuta“?
Se não leu e está com pressa, recomendo essa resenha aqui 😉
É justamente a pesquisa que traz um peso importante para a pergunta desse post.
Então…
É para falhar rápido ou para aprender rápido?
Acredito que sempre devemos estar motivados pelo propósito do que fazemos. Sendo assim, o propósito de falhar no desenvolvimento de produtos nunca foi falhar e, na verdade, aprender. Aprender rápido, é claro.
O problema é que com o tempo, o propósito foi ficando em segundo plano e a interpretação do mantra ficou mais parecido com:
Sair desenvolvendo meio produto rapidamente e de qualquer jeito, porque é pra falhar mesmo e ajustar o que precisar.
Pelo menos é o que parece quando olhamos listas como as do ProductHunt e BetaList.
O que poderia ser feito vs o que é comumente feito.
Quase todo material sobre como trabalhar com MVP’s deixa claro que o mínimo produto viável não é o fim. Entretanto, na prática isso acaba sendo mais complicado. Muitos falham em começar pequeno e ir transformando o MVP num produto de maneira iterativa.
Há algumas atividades fundamentais no desenvolvimento de um MVP que comumente eu não vejo sendo executadas:
- Pesquisa com possíveis clientes (JTBD de preferência).
- Priorização das funcionalidades com base na pesquisa.
- Escolha do período em que as primeiras interações com cliente (testes) serão feitas.
- Definição das métricas que serão avaliadas ao término do período de testes.
Tem mais com certeza, mas essas como eu disse são comuns faltarem.
E sabe o que eu vejo sendo feito no lugar dessas atividades importantes deixadas de lado?
- Muitas hipóteses da cabeça de quem vai criar o MVP.
- Priorização com base no que é “fundamental” nos produtos da categoria do MVP (concorrência).
- Testes com clientes que não são devidamente monitorados (falta de coleta de feedback e mais pesquisa).
- Produtos pela metade que levam os criadores a pensarem que “não deu certo” porque está faltando funcionalidades.
O principal problema nisso, é que assim como no processo adequado, o “processo” equivocado também se retro alimenta e também potencializa os resultados.
Então se por um lado, podemos ter ciclos que aos poucos transformam um MVP num produto que entrega progresso para os clientes, atividades ruins criam uma bola de merda neve de problemas. O famoso entra lixo, sai lixo.
O pior. Quando se está no olho do furacão é mais difícil de perceber o que está errado.
Eu já participei do desenvolvimento de um produto que falhou. Já falei sobre essa história um pouco e também já recomendei a leitura do post de um colega de trabalho que também participou desse projeto. O post é esse aqui.
Quando eu participei desse projeto que fracassou, o Route, eu não percebi que estávamos no caminho errado, em outras palavras, nas iterações que só geravam mais produto inútil. Tudo bem que eu era mais novo e menos experiente, mas algumas questões estava notoriamente erradas.
Hoje, o importante é que esse fracasso me ensinou, afinal, como diria meu sócio, Luiz:
“O sucesso inspira, o fracasso ensina” – Luiz.
Mas o que se pode tirar de acionável disso tudo?
Então, o que posso dizer aqui é que é muito válido que você reflita sobre a questão de falhar rápido. Não caia na armadilha de “desenvolver produtos rapidamente”, criando funcionalidades de qualquer jeito e estufar o peito dizendo que falha rápido.
Pesquise.
Às vezes vai ser chato, vai demandar estudo, vai parecer que você não está no caminho certo ou então que não está fazendo algo concreto de verdade, mas vai ser recompensador com a prática.
Na Umbler, eu tenho tido bons resultados com pesquisa, em especial, com pesquisas atráves do framework Jobs To Be Done.