No CustDev existe uma coisa chamada "feature-value gap"

É quando aparentemente estamos falando sobre valor, mas na verdade - caímos em uma lista de desejos de funcionalidades.

E então a equipe desenvolve mais 7 botões. Mas o dinheiro não aumenta.

Por exemplo,

Na entrevista o cliente diz:
"Preciso de integração com X"

E você registra isso como valor.

Embora o valor possa ser completamente diferente. Digamos,

"..para que os dados não transitem manualmente entre sistemas, porque por isso frequentemente erramos e perdemos dinheiro"


Seu produto é apenas uma das formas possíveis de entregar valor.

(às vezes não a melhor)

O feature-value gap pode ocorrer por vários motivos

1. Os clientes geralmente pensam em funcionalidades

Porque é mais fácil de dizer.

Para falar sobre valor, é preciso lembrar de casos, calcular tempo/riscos, admitir o problema.

Já nomear uma funcionalidade é fácil: "Seria legal se pudesse fazer isso"


2. Nós mesmos provocamos com perguntas

"Quais funções você precisa?"
"O que falta no produto?"

Essas formulações quase garantidamente geram um backlog de desejos, não valor


3. Os clientes confundem "conveniente" com "importante"

Alguém pode realmente querer um dashboard bonito. Porque é agradável.

Mas ele pagará por algo que reduz risco, aumenta dinheiro, economiza tempo, ajuda a passar por compliance etc.


4. Não consideramos diferentes papéis

O usuário dirá "quero um botão".

Mas seu chefe pagará por "controle, risco, velocidade, economia".

Se a entrevista for apenas com usuários, é fácil ficar preso em funcionalidades.


Acho que algo disso certamente aparecerá em suas entrevistas.

E se é assim..

Algumas regras da experiência sobre como evitar isso com mais frequência

Regra 1: comece não pelo produto, mas pela situação real

Em vez de "o que precisa?" pergunte "quando foi a última vez que aconteceu tal coisa?"

O que foi mais desagradável/caro nessa situação? Como terminou? Quanto dinheiro (tempo, nervos) foi gasto?


Seu objetivo é extrair contexto + consequências

Regra 2: "quero uma funcionalidade" sempre traduza para "e para quê?"

A velha "escada do porquê"..

Precisa de integração? Ótimo! E para quê?

O que será diferente se ela existir? E se não existir - o que quebra? Quem sofre?


Após 3-4 "porquês" geralmente surge o valor real

Regra 3: registre o valor no formato "resultado", não "solução"

Formulação ruim de insight: precisa de exportação para PDF

Formulação boa: precisa em X minutos montar relatório para o cliente sem edição manual, caso contrário perdemos prazos e recebemos multas


A funcionalidade pode ser PDF.
Ou pode ser um link
Ou API, template, envio automático

O importante é o resultado.

Regra 4: verifique a importância do valor através do preço do erro

Se isso não for resolvido nos próximos 3 meses - o que acontecerá?

E o pior cenário? E quanto custa (aproximadamente)?


Se ouvir como resposta "é desagradável, mas dá para aguentar" - provavelmente não é valor, é conveniência.

E por último..

Lembre-se de que após a 100ª entrevista algo ficará um pouco mais claro

Bons insights para você!

#busca_de_valor