Esse não é um daqueles textos chatos sobre “o erro que eu cometi e que você não precisa…” que na verdade só servem para inflar o ego de quem está escrevendo. A minha ideia é expôr uma experiência que realmente vale a pena 🙂
Eu vim da área de desenvolvimento e fui aos poucos migrando para produto. Estava acostumado a trabalhar por bastante tempo em funcionalidades e, até mesmo, em projetos inteiros sozinho. E quando minhas atribuições começaram a mudar e fui me direcionando para área de produto, nem passou pela minha cabeça mudar meu jeito de trabalhar.
Então, assim que estudei bastante sobre Jobs To Be Done e troquei vários emails com o Alan Klement e Bob Moesta (que a propósito não me alertaram sobre isto), comecei “rodar as entrevistas” sozinho. Embora eu já começasse a ter um ou outro insight eu tinha cometido um erro bastante comum:
Eu era o “cara de pesquisa” que “roda todas as conversas” sozinho e depois volta dizendo para o resto do time o que eles tinham que fazer.
Confesso que não sei ao certo porque ninguém me orientou a não fazer a pesquisa sozinho. Talvez fosse tão óbvio que é preciso incluir mais gente nesse processo que nem passou pela cabeça dos profissionais que consultei me alertar sobre.
Óbvio ou não, vejo outras pessoas cometendo o mesmo erro
Tenho conversado com muita gente sobre Jobs To Be Done. A maioria entra em contato comigo depois de acessar o Destruição Criativa e começa a trocar algumas ideias sobre assunto. As questões práticas são as mais recorrentes.
Mas assim que começo a entender o contexto do pessoal que quer incorporar JTBD ao trabalho, quase sempre percebo que eles estão sozinhos nessa iniciativa. Geralmente são um líder de design, um profissional de UX, um gerente de produto ou alguém responsável por um setor de inovação querendo conversar com clientes.
Além das pessoas que chegam até mim, se observarmos palestras e apresentações (quase sempre em meetups) sobre JTBD, o caso mais comum é o do profissional que leu sobre a teoria e “fez as entrevistas”. Na minha experiência essa abordagem de fato gera insights, mas não os melhores ou com mais chances de realmente serem utilizados.
Além disso, reunir-se com somente com alguns outros designers ou pesquisadores (um grupo específico) é quase a mesma coisa que trabalhar sozinho.
Os problemas em “tentar Jobs To Be Done” sozinho
Quando centralizamos o conhecimento sobre os clientes (qualquer conhecimento na realidade) numa só pessoa ou time, é criado um gargalo. Essa razão por si só já seria o suficiente para entendermos que é preciso disseminar o que é aprendido entre todos do time, mas mesmo assim, podemos identificar outras questões.
Interpretar o que é dito pelos clientes, mesmo que a conversa tenha sido muito bem fundamentada em fatos, pode ser bastante desafiador. Na minha experiência, diferentes olhares sobre o que é levantado tende a formar uma visão mais precisa sobre o que de fato significa tudo aquilo que o cliente está dizendo.
Na Umbler, por exemplo, colegas meus que já trabalharam em agências têm uma linguagem em comum muito mais parecida com esse segmento de clientes do que eu. Eles “sacam” mais rapidamente determinados contextos e preocupações, pois já as vivenciaram.
Além disso, algumas pessoas precisam ver para crer. Eu mesmo presenciei a diferença que existe entre dizer para o time o que o cliente disse e eles escutarem da boca dele. Alguns podem argumentar que é mais fácil então gravar, editar e mostrar para o resto do time os trechos mais interessantes das conversas. Mas quem já aplica Jobs To Be Done no seu trabalho sabe que anotar, procurar e editar uma conversa de quase 1 hora de duração dá muito mais trabalho que incluir colegas na conversa.
Mas se eu pudesse dar um só argumento, principalmente no que diz respeito execução das conversas em si, fazê-las sozinho (sozinho mesmo, só você e o cliente) é praticamente impossível. Saber o que perguntar, fazer as anotações certas, garantir que as coisas importantes sejam levantadas e, ainda assim, manter a conversa num tom descontraído (afinal de contas ninguém está sendo interrogado) é algo que nem o Bob Moesta faz. Talvez ele consiga, mas ele mesmo acha melhor fazer com pelo menos mais uma pessoa.
O entendimento contínuo e iterativo dos clientes
Embora os jobs tenham um caráter mais constante, tanto as soluções utilizadas quanto o progresso atingido pelos clientes são iterativos. O Sistema do Progresso deixa isso claro.
Então para que tenhamos uma visão mais precisa do que realmente nossos clientes estão procurando/tentando resolver, precisamos atualizar nossas hipóteses constantemente. Uma maneira bastante eficaz de fazer isto é disseminando o aprendizado sobre os clientes de maneira rápida e completa.
Um momento ótimo para se compartilhar o que foi aprendido é imediatamente após uma conversa, seja ela mais focada ou uma “reconstrução da linha do tempo” mais genérica.
Mas o que compartilhar tem a ver com o entendimento iterativo dos clientes?
Quanto mais valor seus colegas perceberem nos aprendizados a partir das conversas com clientes, mais eles sentirão a necessidade de validarem suas visões, hipóteses e soluções. E com o tempo, ficará claro para todos que para participar, afinar e executar essas conversas é necessário que elas sejam parte dos projetos.
Assim, Jobs To Be Done começa a ser realmente tratado com uma ferramenta dos processos relacionados a produto, marketing e/ou vendas em vez de algo a ser “feito” uma vez por uma pessoa.
Concorda que é difícil fazer tudo sozinho e que talvez não faça sentido fazer assim?