A ideia é falhar ou aprender rápido?

Daniel Salengue
Feb 6, 2019 · 4 min read
Image for post
Image for post
Foto por Quino Al disponível em Unsplash

Posso estar generalizando, mas da última vez que observei (uns 10 minutos antes de começar a escrever esse texto), “falhar rápido” era o mantra. Isto ainda mais se estamos estamos falando de software. Se for startup + software então é quase pré requesito ter essa frase tatuada no peito.

Mas, 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.

É claro que a intenção original por trás da frase nunca foi essa, mas como muitas coisas que vemos no mercado, o conceito foi interpretado do jeito fácil e confortável.

Aliás, se falhar rápido seja a verdadeira intenção, alguém precisa urgente avisar o pessoal da InVision, Intercom, Basecamp e Google que eles estão fazendo justamente o contrário. Em vez de sair “fazendo” e falhando rápido, eles estão cada vez mais investindo em pesquisa.

Analisar dados de uso de aplicativos, montar sistemas de análise e coleta de feedbacks e falar constantemente com clientes são alguns dos exemplos de pesquisa aplicada ao desenvolvimento de produto que essas empresas fazem com maestria.

“Pesquisa é coisa de empresa gigante! Olha os exemplos que o próprio texto traz.”

Hum, 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 prática. Muito pelo contrário, enquanto ainda se está constantemente levantando e testando hipóteses, a pesquisa pode trazer ainda mais valor.

E é 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, mas aprender. E 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 (e eu posso falar porque ajudei pessoalmente com um item nessas listas — Route).

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:

  1. Pesquisa com possíveis clientes (com JTBD, por exemplo).
  2. Priorização das funcionalidades com base na pesquisa.
  3. Escolha do período em que as primeiras interações com cliente (testes) serão feitas.
  4. Definição das métricas que serão avaliadas ao término do período de testes.

Tem mais com certeza, mas essas são comuns de faltarem.

E sabe o que eu vejo sendo feito no lugar dessas atividades importantes deixadas de lado?

  1. Muitas hipóteses da cabeça de quem vai criar o MVP.
  2. Priorização com base no que é “fundamental” nos produtos da categoria do MVP (concorrência).
  3. Testes com clientes que não são devidamente monitorados (falta de coleta de feedback e mais pesquisa).
  4. 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 neve de problemas. O famoso entra lixo, sai lixo.

Mas 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.

Nesse 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 estavam notoriamente erradas.

Mas o que se pode tirar de acionável disso tudo?

Então, posso dizer que é muito válido refletir 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, mas vai ser recompensador com a prática.

Na Umbler, nós estamos bastante satisfeitos em priorizar pesquisa nos nossos processos de produto e design.

Mas e você, como tem sido a sua relação com falhar vs aprender rápido?

Curtiu o conteúdo? Deixe seu e-mail pra receber novidades! 👇

Image for post
Image for post

JTBD+

Sua comunidade oficial sobre Jobs To Be Done no Brasil.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store