O “Job to Be Done” e a guerra de funcionalidades

A melhor maneira para fugirmos da briga de features é entender o Job to Be Done do nosso produto

Avatar

Por Pedro Waengertner

17 de junho de 2015 às 10:43 - Atualizado há 5 anos

“Qual a sua vantagem em relação a empresa X”, pergunta o investidor.

“O nosso produto possui a feature Y, que o faz ser o melhor do setor.”, responde o empreendedor.

Já vi esta conversa acontecer muito mais vezes do que gostaria. A pergunta do investidor tem dois propósitos. O primeiro é para entender se existe alguma vantagem competitiva real no produto/empresa apresentada. A segunda é para entender como pensa o empreendedor. Quando a resposta é como a acima, geralmente a réplica é mais ou menos assim:

“Se eu colocar um milhão na mão do concorrente, em quanto tempo ele te copia?”

Esta é uma pergunta retórica, obviamente. Sabemos que tecnologia é copiável, cada dia mais. Hoje conseguimos construir um produto inteiro com um PC e uma conexão internet. Ou seja, o conceito de vantagem competitiva sustentável raramente se prova verdadeiro com a facilidade existente hoje para copiar qualquer coisa. E isso acaba gerando uma ansiedade enorme nos empreendedores a cada feature lançada pelos concorrentes.

“Estamos ficando para trás! Precisamos reagir! Vamos virar a noite para colocar essa funcionalidade de pé.”, diz o empreendedor.

O problema é que raramente isso resolve. Raramente mesmo… E por quê?

Por que estamos tirando da equação a figura mais importante. Você notou que até agora não falamos de clientes? O propósito do nosso produto é atendê-los, certo? E onde está o papel dele nesta história toda?

A melhor maneira para fugirmos da briga de features é entender o Job to Be Done do nosso produto. Este conceito foi criado por Clayton Christensen como uma forma de entender melhor o papel dos produtos para atender as necessidades dos clientes. A moral da história é bem simples: o cliente tem um trabalho a ser feito e o nosso papel é entendê-lo e atendê-lo melhor que a concorrência. Por exemplo: qual o JTBD da pessoa que está chamando um taxi? É basicamente chegar do ponto A ao B, certo? Neste caso, temos várias formas de resolver: podemos criar um aplicativo de Taxi para fazer com que ele consiga chamar a qualquer momento um taxi, em qualquer lugar, integrando-o a frota existente na cidade. É possível pensar de outra forma: e se criassemos uma frota alternativa, oferecendo uma forma de pagamento mais simples e mais conforto? No primeiro exemplo, estamos falando de aplicativos de Taxi, como 99Taxis e EasyTaxi. No segundo, falamos do Uber.

É claro que o público destes dois tipos de empresa é diferente, com algumas intersecções. Portanto o primeiro passo é entender com quem estamos falando. E esquecer as features neste primeiro momento.

“Como assim? Esquecer as features?”

É isso mesmo! O primeiro ponto é entender quais os passos que o cliente (o cara que você quer atingir) dá para resolver aquele trabalho específico. Fazemos isso conversando com clientes, vários deles, fazendo as perguntas certas, e desenhando estes passos. Depois de um bom número de conversas, começamos a identificar os padrões. E é a partir daí que podemos entender melhor como podemos fazer este trabalho melhor do que ele faz hoje, a ponto de ele (ou alguém) pagar por isso.

Algo mais ou menos assim no caso do taxi:

Necessidade do Taxi >> Ir até a rua movimentada (ou telefonar para a cooperativa) >> Pegar o Taxi >> Informar o Local >> Pagar >> Sair do Carro

  • E se houvesse uma maneira bem mais rápida e prática de chamar o carro?
  • E se o destino já estivesse com o motorista?
  • E se a experiência dentro do carro fosse melhor do que a média?
  • E se o pagamento já estivesse pré configurado?
  • E se o cliente conseguisse avaliar cada viagem de taxi, melhorando a qualidade do serviço?

A partir daí podemos desenhar um serviço para começar a fazer este trabalho de forma melhor que a disponível hoje. Obviamente, como somos uma startup, é difícil montarmos tudo de uma vez, então priorizamos aqueles pontos que trazem mais valor e vamos testando.

E as features? As features servem apenas para atendermos a este propósito. A nossa decisão passa a ser muito simples: Ajuda o cliente a realizar melhor o trabalho dele? Coloca no produto. “Não ajuda, mas é legal.” Não faz. “Mas é muito legal!” Não faz!

Tenho certeza que as melhores empresas do mundo pensam exatamente desta forma. As decisões ficam claras e a forma de vender o produto também.