Tenho trocado muitos emails com outros entusiastas e praticantes de Jobs To Be Done que acompanham o blog. Dentre os diversos assuntos que tratamos, um tem, infelizmente, se mostrado bastante recorrente: as objeções em relação à pesquisa com Jobs To Be Done (em alguns casos, em relação a qualquer tipo pesquisa).
Incorporar pesquisa ao processo de design ou desenvolvimento de produto, embora bastante difundido em livros e relatos de empresas inovadoras, ainda não é algo muito comum. Mas não podemos pensar que essa é uma realidade local. Daniel Burka (Vital Strategies) diz o seguinte sobre a cultura vigente em startups em relação a produto:
“O jeito mais típico que vemos startups trabalharem é que você tem uma idéia, daí você constrói (codifica/desenvolve) uma solução a partir dessa idéia, você lança essa idéia e, então você a mede… mas esse jeito é falho desde o princípio.” – Daniel Burka
Como efeito, quando alguém propõe um trabalho de pesquisa surgem as objeções. Mas nem todas estão lá propositadamente para atrapalhar nosso trabalho. Muitas vezes elas são oriundas de dúvidas pertinentes ou de conclusões equivocadas. Sendo assim, decidi compilar um post com as mais recorrentes.
Seguidas de algumas dicas do que podemos fazer para superá-las, do contrário eu seria só mais um reclamão 🙂
Vamos às objeções…
“Já sabemos tudo o que precisamos.”
Há duas situações comuns onde esse objeção aparece:
- Quando estamos criando uma solução para um problema que nós mesmos temos (scratching our own itch).
- Quando estamos tentanto inovar numa indústria na qual já temos experiência.
Em ambos os casos, podemos acreditar que temos domínio completo sobre o que precisamos. Entretanto, isto não é necessariamente verdade. Mesmo que se tenha experiência e conhecimento sobre o problema (ou os usuários, ou a solução, ou o contexto), é sempre muito frutífero revisitar nossos pontos e, ainda mais importante, conhecer a perspectiva de outras pessoas.
Nem sempre a familiaridade sobre algo está a nosso favor. Pelo contrário, às vezes estamos tão imersos, seja num problema, numa indústria ou em soluções existentes que acabamos nos fechando para um olhar mais inovador.
Cuidar para não se ter essa visão, digamos, viciada, é um dos fundamentos do Shoshin (mente de principiante).
Trazer essas reflexões à tona quando surgir esse tipo de objeção pode ser o suficiente para incentivar o uso de pesquisa. Além disso, outra abordagem bastante útil é direcionar a razão da pesquisa para a disseminação de conhecimento entre as outras pessoas envolvidas no projeto. Algo na linha: “para que elas ouçam do próprio cliente/público alvo”.
“Ninguém aqui é cientista para fazer pesquisa.”
Primeiramente, precisamos dismistificar pesquisa no contexto de produtos, empresas e startups. Aqui, não estamos falando de pesquisa nos moldes acadêmicos. Na realidade, estamos coletando e gerando informações que nos auxiliem na tomada de decisões referentes a uma empresa e/ou produto.
Sendo assim, ninguém que deseja incorporar pesquisa no seu trabalho precisa ter conhecimentos acadêmicos e muito menos ser um cientista. Entretanto, de fato há algumas qualidades de um cientista que com certeza nos ajudariam caso as tivéssemos:
- Olhar analítico, imparcial e até mesmo um tanto cético. É muito importante não ser tedencioso e realmente levantar o que é mais verdadeiro em vez daquilo que se tem preferência.
- Boa comunicação e criticidade. Uma parte fundamental de qualquer pesquisa é a interação e conversa com outras pessoas.
- Curiosidade acima de confirmações. Procurar abertamente entender o que acontece é mandatório para se obter resultados relevantes. É necessário muito cuidado com tendência do ser humano em se provar certo sobre aquilo que ele presume.
“Isso aí não escala.”
Escalabilidade, escalabilidade, escalabiliblá, escabláblá, blá, blá, blá…
É um tanto frustrante quando um termo importante é tão mal compreendido. Assim como qualquer outra característica, escalabilidade deve ser incorporada, entretanto, no seu momento e não servir de desculpa (ou objeção) para não trabalharmos em outras coisas igualmente importantes.
O trabalho de pesquisa Jobs To Be Done não escala, tampouco precisa ou deveria escalar.
Quando se está a procura de entender as razões, os porquês, é necessário se trabalhar qualitativamente. Além disso, nunca em pesquisas com Jobs To Be Done estamos falando em pesquisar com muitas pessoas. Na realidade, com prática e visto que estamos procurando porquês, poucas pessoas tendem a revelar bastante sobre o que estamos investigando.
Existe uma dinâmica chamada “O tabuleiro de xadrez mutilado” que ilustra muito bem de como trabalhar com porquês pode desbloquear muitos outros trabalhos. Se quiser saber mais sobre essa dinâmica deixe um comentário que mostro ela 😉
Sendo assim, é importante dar tempo ao tempo e entender que sempre haverá trabalhos que não escalam.
“Podemos descobrir tudo o que precisamos no MVP.”
É indiscutível que muita coisa se descobre com um MVP (ou numa versão beta). Aliás, quando estamos falando em solução, de fato uma primeira versão de um produto é o melhor jeito de colocar as coisas à prova. Eu gosto muito de uma entrevista do Jason Fried (CEO do Basecamp) onde ele diz que um produto só é validado de verdade, quando ele é lançado para alguém usar.
Entretanto, pesquisa não depende de solução. Na realidade, muitas coisas valiosas podem ser descobertas muito antes de qualquer desenho de solução. Coisas essas que em muitos casos precisam muito serem levadas em consideração no MVP. Como o público alvo do seu produto resolve seus problemas hoje é um exemplo de algo muito importante que deve ser considerado desde o início.
Podemos dizer, então, que sem pesquisa o próprio MVP é na realidade prejudicado. Afinal de contas…
De que adianta você oferecer uma solução rápida e enxuta para algumas pessoas se ela for baseada em suposições não validadas com pesquisa?
Para não deixar que essa objeção então fique no seu caminho, é interessante levantar o questionamento da solução vs problema. Muitos adoram dizer que são agéis ou lean ou que querem resolver problemas, mas na prática partem direto para uma solução. Com pesquisa primeiro, você com certeza estará começando pelo problema.
“Nós não temos tempo para pesquisa.”
E para recomeçar um projeto do zero?
E se o caminho tomado no princípio tenha se mostrado equivocado?
Tempo no que diz respeito a trabalho é um questão de priorização e gerenciamento de riscos. Entretanto, a pressa e a ansiedade de “colocar alguma coisa rodando” tiram esse dissernimento de muitos. Como resultado, vemos vários produtos que precisam ser repensados desde seus princípios.
Mas sempre que entramos nessa reflexão alguém pode trazer a máxima: “errar rápido”. Aliás, para muitos esse é o principal mantra do mundo das startups. E realmente, errar rápido é muito bom, principalmente se for comparado com errar devagar.
Mas será que só existem essas duas opções? Errar rápido ou errar devegar?
Será que assim como escalabilidade o uso estressante do termo não o desviou do sua essência?
Pois é, eu penso que errar é um meio e não o fim. Sendo assim, prefiro um outro mantra:
“Aprender rápido”
E sim, pesquisa faz com que aprendamos rápido. É claro, não podemos ser ingênuos e acreditar que uma boa pesquisa vai nos livrar de errar. Isto nunca vai acontecer. Nós somos muito bons em errar. Mas pesquisar elimina alguns caminhos mais propensos ao erro.
Se pararmos para refletir, para todo problema (ou job, ou público alvo, ou mercado) há inúmeras maneiras de fazer um produto ruim que não serve para ele. Por isso é interessante eliminar algumas dessas maneiras mais cedo, em alguns casos antes mesmo de desenhar qualquer solução.
Faz parte do processo.
Pra quase toda abordagem fora do padrão haverá resistência. Entender as motivações por trás dessa resistência pode ajudar a superá-la. No mínimo é mais promissor do que usar isto como desculpa para não testar algo novo.
Essas foram algumas das objeções que apareceram mais vezes nas conversas que tive com profissionais que acompanham o blog. Mas quem trabalha com Jobs To Be Done sabe que pontos fora do padrão sempre têm uma história interessante para contar (vide “Os pontos fora da curva são os pontos que valem a pena”). Sendo assim, se você conhece alguma outra objeção em relação a pesquisa, tanto Jobs To Be Done ou em geral, não deixe de compartilhar com nós.