Ciclo de feedback

Modelo Kano: ordene pedidos pela emoção do cliente

6 min de leitura

O modelo Kano é uma forma de ordenar funcionalidades pela reação dos clientes a tê-las e a não tê-las, em vez de pelo número de pessoas que pediram. Foi proposto por Noriaki Kano em 1984 e coloca cada funcionalidade em um de cinco grupos: obrigatória, de desempenho, atrativa (de encantamento), indiferente e reversa. Para um time com uma pilha de pedidos de funcionalidades, a parte útil é que ele explica por que um pedido com dezenas de votos pode não acrescentar nada à satisfação, enquanto um pedido que ninguém votou pode mudar o jeito como as pessoas falam do produto.

CategoriaReação do cliente quando existeReação do cliente quando faltaPedido típico
ObrigatóriaNenhuma, já é esperadaForte insatisfaçãoRedefinição de senha, exportação de dados
DesempenhoA satisfação cresce com mais delaA satisfação cai com menos delaVelocidade, armazenamento, limites
AtrativaEncantamentoNenhuma, ninguém esperavaUma automação bem pensada
IndiferenteNenhumaNenhumaUma configuração que poucos tocam
ReversaIrritaçãoAlívioUm tour forçado ou um passo extra

Quais são as categorias do modelo Kano?

As funcionalidades obrigatórias são as que os clientes presumem que existem. Ninguém as elogia e todo mundo percebe quando quebram. As funcionalidades de desempenho são aquelas em que mais é melhor em linha reta, como relatórios mais rápidos ou limites mais altos. As funcionalidades atrativas são inesperadas, então a ausência delas não custa nada e a presença rende entusiasmo de verdade. As funcionalidades indiferentes não mexem em nada, em nenhuma direção, e as reversas deixam alguns clientes mais felizes quando são removidas.

A categoria é uma propriedade de uma funcionalidade para um grupo de clientes em um determinado momento, e por isso a mesma funcionalidade pode cair em grupos diferentes para segmentos diferentes.

Como aplicar uma pesquisa Kano?

Faça duas perguntas sobre cada funcionalidade. A pergunta funcional pergunta como o cliente se sentiria se o produto tivesse a funcionalidade. A pergunta disfuncional pergunta como ele se sentiria se o produto não a tivesse. As duas usam as mesmas cinco respostas: eu gosto, eu espero isso, tanto faz, eu aceito, eu não gosto.

Combine as duas respostas com a grade de avaliação padrão para classificar a visão de cada respondente sobre cada funcionalidade:

Funcional \ DisfuncionalGostoEsperoTanto fazAceitoNão gosto
GostoQAAAO
EsperoRIIIM
Tanto fazRIIIM
AceitoRIIIM
Não gostoRRRRQ

M é obrigatória (must-be), O é desempenho (unidimensional), A é atrativa, I é indiferente, R é reversa e Q é uma resposta questionável, que se contradiz. Conte as letras entre os respondentes para cada funcionalidade e tome a mais frequente como a categoria dela. Quando duas categorias estão próximas, reporte as duas, porque uma divisão de 40/38 mostra que o segmento está dividido, e não que uma resposta venceu.

Quais pedidos de funcionalidades entram em uma pesquisa Kano?

Apenas os que você consideraria construir de verdade e não consegue ordenar por intuição. De cinco a quinze funcionalidades é um tamanho viável de pesquisa, e cada uma precisa de uma descrição de uma frase que o cliente consiga imaginar sem um protótipo. Puxe os candidatos do seu backlog rastreado depois de agrupar as duplicatas, porque dez pedidos da mesma coisa devem chegar à pesquisa como uma só funcionalidade. A etapa de agrupamento está em rastreamento de pedidos de funcionalidades.

Deixe de fora correções de bugs e tudo o que já foi prometido em contrato. Uma pesquisa não diz se você deve corrigir uma falha.

Quem você deve pesquisar?

Pessoas que já usam o produto, separadas pelos segmentos que importam para você. Uma pesquisa enviada a toda a sua lista tende a produzir a média de vários grupos diferentes, e a média esconde o achado. Usuários gratuitos e pagantes, contas novas e antigas, equipes pequenas e grandes costumam colocar a mesma funcionalidade em categorias diferentes. Mantenha os resultados de cada segmento separados e decida para qual segmento será a próxima release.

Use as pessoas que escreveram os pedidos como público inicial e some uma amostra aleatória de usuários ativos, para que a pesquisa não seja só a minoria que fala alto. Como redigir e enviar o convite está em como pedir feedback aos clientes.

Como transformar os resultados do Kano em uma ordem de prioridade?

Construa nesta ordem: primeiro as lacunas obrigatórias, depois as funcionalidades de desempenho em que você está atrás das alternativas com que seus clientes comparam você, depois uma ou duas funcionalidades atrativas por release, e as indiferentes e reversas por último ou nunca. A ordem decorre do que cada categoria faz com a satisfação. Fechar uma lacuna obrigatória remove um motivo para ir embora, o trabalho de desempenho eleva a satisfação de forma constante, e uma funcionalidade atrativa é de onde vem a diferenciação.

O Kano diz que tipo de valor uma funcionalidade carrega, e não diz quanto ela custa. Combine a categoria com uma estimativa de esforço antes de colocá-la em um plano. Um método de pontuação como o de pontuação RICE cuida do lado do custo, e os dois funcionam bem juntos: o Kano escolhe a lista curta e o RICE a ordena. A decisão mais ampla está em como priorizar pedidos de funcionalidades.

As funcionalidades mudam de categoria com o tempo?

Sim, e esta é a coisa mais útil de lembrar sobre o modelo. Funcionalidades atrativas tendem a virar de desempenho e depois obrigatórias à medida que concorrentes as copiam e os clientes se acostumam. A autenticação em dois fatores já foi uma surpresa agradável e hoje é uma expectativa em software para empresas. O resultado de uma pesquisa é uma foto do momento, então repita-a para qualquer categoria em que você esteja apostando depois de um ano, ou sempre que um concorrente lançar algo parecido.

Avise os clientes quando você lançar uma funcionalidade de encantamento. Uma funcionalidade da categoria atrativa só encanta quem fica sabendo dela, o que faz do anúncio parte da funcionalidade. Fechar esse ciclo é o tema de como escrever o anúncio de uma funcionalidade nova.

Quais são os limites do modelo Kano?

Ele mede sentimentos declarados, não comportamento, então pode superestimar o que as pessoas dizem querer. Precisa de respondentes suficientes por segmento para mostrar um padrão, e algumas dezenas costumam ser o piso prático. Também avalia as funcionalidades uma a uma e não diz nada sobre como elas interagem. Trate o resultado como uma evidência forte para a conversa sobre o roadmap e coloque-o ao lado de dados de uso e de receita. Para transformar a lista ordenada em um plano, veja como criar um roadmap de produto.

FAQ

O que é o modelo Kano em termos simples? É um método que separa funcionalidades em grupos conforme o que os clientes sentem quando a funcionalidade existe e quando ela falta. Os grupos são obrigatória, de desempenho, atrativa, indiferente e reversa, e cada um aponta para uma prioridade de construção diferente.

De quantas pessoas você precisa para uma pesquisa Kano? Não há um número fixo, mas cada segmento que você quer ler separadamente precisa de respostas suficientes para mostrar uma categoria com maioria clara. Algumas dezenas por segmento é um mínimo prático comum, e um resultado dividido com poucas respostas deve ser lido como indefinido.

O modelo Kano é melhor que o RICE? Eles respondem a perguntas diferentes. O Kano classifica o tipo de valor que uma funcionalidade dá aos clientes, e o RICE ordena o trabalho por alcance, impacto, confiança e esforço. Muitas equipes usam o Kano para montar a lista curta e um método de pontuação para ordená-la.

Com que frequência repetir uma análise Kano? Uma vez por ano para produtos estáveis, e antes disso quando um concorrente lançar uma funcionalidade parecida. Funcionalidades de encantamento viram expectativas com o tempo, então um resultado antigo pode apontar para uma funcionalidade que já não diferencia.


As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Comparativo de ferramentas de changelog

changeloop
O time por trás de um changelog que fecha o loop. Os usuários pedem algo, sua equipe entrega, quem pediu fica sabendo.