"Vamos construir primeiro as funcionalidades mais pedidas." Essa decisão, que à primeira vista parece certa, costuma sair pela culatra no desenvolvimento de produto. O motivo é que "a funcionalidade que faz a satisfação disparar quando existe" e "a funcionalidade que é óbvia ter e que, quando falta, enfurece o cliente" funcionam por lógicas completamente diferentes. Por mais que você lapide a primeira, a insatisfação não some; por mais que lapide a segunda, a satisfação não sobe.
A satisfação tem uma assimetria. Capturar isso em cinco tipos de qualidade e mudar a aposta para cada funcionalidade é o que faz o modelo Kano. Proposto pelo japonês Noriaki Kano na década de 1980, ele continua sendo usado em desenvolvimento de produto e desenho de serviço no mundo inteiro. Neste artigo, organizamos com o tato da prática desde o significado das cinco categorias, passando pela forma de perguntar em "dois numa só" exclusiva do modelo Kano, a classificação na tabela de avaliação, a visualização pelo coeficiente Better-Worse, até a conexão com a IPA e a análise de key drivers.
1. Por que a "assimetria da satisfação" importa
Normalmente, pensamos de forma ingênua que "se a qualidade sobe, a satisfação sobe junto". Mas a realidade não é assim. Kano et al. (1984) mostrou que existem atributos de qualidade em que a relação entre o grau de atendimento (o quanto está entregue) e a satisfação não é uma linha reta.
Pense num exemplo. "A bateria do celular durar o dia todo" é óbvio ter. Durar não emociona ninguém, mas não durar gera uma insatisfação enorme. Já uma "funcionalidade conveniente inesperada" não faz falta a ninguém quando não existe, mas quando existe faz a satisfação disparar com um "ó, que bacana". Essas duas coisas, embora ambas sejam "funcionalidades", afetam a satisfação de formas opostas.
Ignorar essa assimetria e decidir a ordem de prioridade do desenvolvimento só pelo "número de pedidos" ou pela "satisfação média" leva a reforçar a qualidade obrigatória sem que a satisfação suba, num esforço em vão, ou a deixar passar a qualidade atrativa e ser ultrapassado pelo concorrente. O modelo Kano é a ferramenta para distinguir como cada funcionalidade afeta a satisfação.
Tanto na análise de importância-desempenho (IPA) quanto na análise de key drivers tocamos na "assimetria da satisfação (Matzler 2004)", mas o que é exclusivo do modelo Kano é ir medir essa assimetria diretamente já na etapa das perguntas.
2. As cinco categorias de Kano — separar funcionalidades pelo modo como afetam a satisfação
O modelo Kano classifica os atributos de qualidade em cinco tipos.
Os cinco tipos de qualidade de Kano
A aposta que cada classificação indica
- Qualidade obrigatória: atender com segurança como "linha mínima". Competir aqui não eleva a satisfação (defesa)
- Qualidade unidimensional: a satisfação cresce conforme o volume de investimento. É o campo de batalha contra o concorrente (fazer crescer)
- Qualidade atrativa: mesmo em pequena quantidade, se acerta o alvo, vira diferenciação. É o próximo destaque (ataque)
- Qualidade indiferente e reversa: decisão de não fazer / cortar. Economia de recursos e remoção de funcionalidades em excesso
Não é "muito pedido = deve ser construído"; o cerne de Kano é que o sentido do investimento muda conforme o tipo.
3. A forma de perguntar em "dois numa só" exclusiva do modelo Kano
O que torna o modelo Kano decisivamente diferente das outras pesquisas é que para cada funcionalidade você faz duas perguntas em par. Chamamos isso de pergunta funcional (functional) e pergunta disfuncional (dysfunctional).
O formato das perguntas
Para uma dada funcionalidade, você faz as duas perguntas a seguir.
[Pergunta funcional] Se essa funcionalidade "existir", como você se sente?
[Pergunta disfuncional] Se essa funcionalidade "não existir", como você se sente?
As opções de resposta usam, em ambas as perguntas, a mesma escala de 5 pontos.
- Eu gosto (satisfeito)
- É natural que seja assim (deveria ser assim)
- Não sinto nada de especial (neutro)
- Posso conviver com isso (tolerável)
- Eu não gosto (insatisfeito)
A partir da combinação das respostas de "se existir" e "se não existir", determina-se de que tipo é aquela funcionalidade. "Se existir → eu gosto / se não existir → não sinto nada" é qualidade atrativa; "se existir → é natural / se não existir → eu não gosto" é qualidade obrigatória, e assim por diante.
Por que são necessárias duas perguntas
Se você medir a satisfação com uma única pergunta — "essa funcionalidade é importante?" —, a assimetria não aparece. Mesmo que a pessoa responda que é importante, não dá para distinguir se é "faz falta sem ela (obrigatória)" ou "é bom tê-la (atrativa)". Só ao cercar pelos dois lados, funcional e disfuncional, é que se revela o tipo de efeito sobre a satisfação. É esse o miolo do desenho de perguntas de Kano.
A forma de redigir as perguntas afeta o resultado. Para o princípio de evitar indução e dupla negativa, consulte o guia completo de redação de perguntas de pesquisa.
4. Classificar na tabela de avaliação
A combinação de pergunta funcional (5 opções) × pergunta disfuncional (5 opções) dá 25 possibilidades. Aplicando isso à tabela de avaliação de Kano, classifica-se cada respondente e cada funcionalidade por tipo.
Como ler as células representativas:
| Funcional (se existir) | Disfuncional (se não existir) | Classificação |
|---|---|---|
| Eu gosto | Eu não gosto | Qualidade unidimensional (O) |
| Eu gosto | Não sinto nada | Qualidade atrativa (A) |
| É natural | Eu não gosto | Qualidade obrigatória (M) |
| Não sinto nada | Não sinto nada | Qualidade indiferente (I) |
| Eu não gosto | Eu gosto | Qualidade reversa (R) |
- Base da tabulação: para cada funcionalidade, adota-se "o tipo classificado com mais frequência (a moda)" como o tipo daquela funcionalidade
- Respostas questionáveis (Questionable, Q): combinações logicamente contraditórias, como "se existir → eu gosto / se não existir → eu gosto". São candidatas a exclusão na limpeza de dados. Quando há muitas, pode haver um problema na compreensão da pergunta (guia de limpeza de dados de pesquisa)
Tirar, por funcionalidade, a distribuição dos tipos (quantos % de A, quantos % de M…) e representá-la pelo tipo de maior frequência é a tabulação padrão.
5. Visualizar com o coeficiente Better-Worse
A classificação pela moda é simples, mas a gente fica em apuros com funcionalidades que se dividem por pouca diferença, do tipo "atrativa 45% / unidimensional 40%". Aí entra o coeficiente Better-Worse (coeficiente CS / coeficiente de satisfação do cliente) proposto por Berger et al. (1993), que visualiza como grandeza contínua.
Fórmula de cálculo
- Coeficiente Better (de satisfação) = (A + O) / (A + O + M + I)
- Coeficiente Worse (de insatisfação) = −(O + M) / (A + O + M + I)
(A = atrativa, O = unidimensional, M = obrigatória, I = indiferente — o número de respostas de cada uma)
- Better é "o quanto a satisfação sobe quando aquela funcionalidade é oferecida" (0 a 1; quanto maior, maior o efeito de elevar a satisfação)
- Worse é "o quanto a insatisfação aumenta quando aquela funcionalidade falta" (−1 a 0; quanto maior o valor absoluto, maior o impacto da ausência)
Em quatro quadrantes no gráfico de dispersão
Desenhando um gráfico de dispersão com Better no eixo horizontal e Worse (valor absoluto) no eixo vertical, as funcionalidades se separam em quatro zonas.
- Better alto · Worse alto → qualidade unidimensional (campo principal, que rende quanto mais se faz crescer)
- Better alto · Worse baixo → qualidade atrativa (candidata a destaque de diferenciação)
- Better baixo · Worse alto → qualidade obrigatória (a base a ser protegida)
- Better baixo · Worse baixo → qualidade indiferente (deixar para depois)
Essa forma de mostrar tem uma ideia próxima dos 4 quadrantes da IPA e permite discutir "em qual funcionalidade investir quanto" numa única tela na reunião de diretoria. Para montar o gráfico de dispersão, veja o guia de visualização de resultados de pesquisa.
6. Quando usar Kano, IPA ou análise de key drivers
O modelo Kano é complementar aos outros métodos de análise de satisfação. Sem confundir, use cada um conforme o objetivo.
- Modelo Kano: classifica diretamente, já na etapa das perguntas, o tipo de efeito de cada funcionalidade sobre a satisfação (atrativa / obrigatória / unidimensional). Bom para a seleção de novas funcionalidades e o desenho de roadmap
- Análise de key drivers (KDA): a partir de dados de satisfação já existentes, deriva os fatores que estatisticamente movem a satisfação geral. É baseada em regressão. Boa para identificar fatores de melhoria de um serviço já em operação
- Análise de importância-desempenho (IPA): mapeia a prioridade de melhoria em 4 quadrantes de importância × satisfação. Boa para fazer o inventário da situação atual
Combinações de praxe
- Avaliação antes do lançamento / de novas funcionalidades → use Kano para discernir o tipo da funcionalidade e, atendendo à qualidade obrigatória, embuta uma ou duas qualidades atrativas
- Melhoria de algo em operação → use a KDA para identificar os fatores que rendem e a IPA para mapear a prioridade. Com a ótica de "obrigatória / atrativa" de Kano, enxergue a "qualidade obrigatória que, mesmo corrigida, não eleva a satisfação"
Enquanto KDA / IPA "analisam a estrutura de satisfação do que já existe", Kano é a ferramenta voltada ao pré-lançamento e ao planejamento, para "discernir o tipo da funcionalidade que se vai criar / embarcar" — essa é a divisão de papéis. Na priorização de funcionalidades antes do lançamento, ele também é usado junto com MaxDiff e análise conjunta.
7. A visão da redação — os 5 erros a não cometer no modelo Kano
Na posição de quem acompanha continuamente casos do setor e a voz de quem está na prática, eis cinco acidentes que se repetem com o modelo Kano.
1. Esperar que "reforçar" a qualidade obrigatória eleve a satisfação
É o equívoco mais frequente. A qualidade obrigatória é o tipo que é natural atender e, quando falta, gera insatisfação. Por mais que você a lapide mais que ninguém, a satisfação não sobe. "Levar a estabilidade do login ao limite vai emocionar o cliente" não acontece. A qualidade obrigatória é a defesa de "não deixar faltar", não um alvo para fazer crescer. Se for atacar, vá para a unidimensional e a atrativa.
2. Achar que toda "funcionalidade muito pedida" é qualidade unidimensional
Boa parte das funcionalidades que o cliente diz "querer" é qualidade unidimensional, mas entre elas há também qualidade atrativa (que é difícil de verbalizar) e qualidade obrigatória (que não aparece nos pedidos justamente por ser óbvia demais para mencionar). Decidir o desenvolvimento só pelo ranking de número de pedidos faz a falha da qualidade obrigatória ou o esquecimento da qualidade atrativa acontecer. Julgue pelo tipo de Kano, não pela quantidade de pedidos.
3. Deixar as respostas contraditórias (Questionable) passarem
Misturar na tabulação, sem excluir, respostas logicamente contraditórias como "se existir → eu gosto / se não existir → eu gosto". Uma funcionalidade com muitos Q é sinal de que a explicação da pergunta não está chegando. É preciso decidir entre revisar o texto descritivo da funcionalidade ou tirá-la da análise. Pular a limpeza faz a classificação oscilar.
4. Confiar demais na qualidade atrativa como "diferenciação eterna"
A qualidade atrativa de hoje vira a qualidade obrigatória de amanhã (o próprio Kano apontou isso como "obsolescência da qualidade"). A câmera do celular era qualidade atrativa quando surgiu; hoje é qualidade obrigatória. A classificação de Kano é um instantâneo de um momento e, se você não remede periodicamente, deixa passar o ponto em que o antigo destaque passou a ser "óbvio ter".
5. Ignorar os segmentos e decidir uma classificação única para o todo
Para o usuário pesado pode ser qualidade atrativa e, para o usuário leve, qualidade indiferente — isso acontece normalmente. Arredondar tudo para um único tipo na tabulação geral apaga as diferenças entre segmentos. Para as funcionalidades importantes, combine com a segmentação de clientes e olhe a classificação de Kano por segmento.
8. Pesquisa de modelo Kano na ferramenta de pesquisa Kicue
A pesquisa de modelo Kano se divide na fase de "desenhar as perguntas em dois numa só e coletar as respostas" e na fase de análise de "classificar na tabela de avaliação e calcular o coeficiente Better-Worse". O que a Kicue assume é a primeira.
- Desenho das perguntas em dois numa só (funcional e disfuncional): suporta a estrutura de enfileirar, para cada funcionalidade, a pergunta funcional e a disfuncional com a mesma escala de 5 pontos (tipos de pergunta). Dá para montar pares na quantidade de funcionalidades
- Apresentação da descrição da funcionalidade: é possível desenhar para apresentar o texto descritivo de cada funcionalidade antes de fazer as duas perguntas
- Exportação de CSV com ID de respondente: emite as respostas funcional e disfuncional em uma linha por resposta. Estrutura pronta para alimentar diretamente a classificação na tabela de avaliação e o cálculo dos coeficientes
- Triagem de público: triagem inicial para perguntar apenas ao cliente-alvo (guia de perguntas de triagem)
⚠️ O que está fora do alcance da Kicue
- Não há classificação automática pela tabela de avaliação de Kano: a classificação na matriz de 25 células se faz, após a exportação do CSV, em Excel / R (ex.: pacotes como Kained) / Python. A própria Kicue não tem função de classificação de Kano
- Também não há cálculo do coeficiente Better-Worse nem criação do gráfico de dispersão: o cálculo dos coeficientes e a visualização se fazem em Excel / R / Python
- Também não há detecção automática das respostas contraditórias (Q): a limpeza e a exclusão são processamento posterior à exportação
- Também não há classificação de Kano por segmento: a tabulação por segmento se faz em ferramenta externa
Como artigos relacionados, ler junto o guia de análise de importância-desempenho (IPA), o guia de análise de key drivers, o guia de design de MaxDiff, a prática de análise conjunta e o guia de pesquisa de teste de conceito faz aparecer o panorama completo da pesquisa de pré-lançamento e desenvolvimento de produto: "discernir o tipo da funcionalidade (Kano) → medir a prioridade (MaxDiff/conjunta) → avaliar o conceito".
Conclusão — 6 pontos para dominar o modelo Kano
- A satisfação é assimétrica — lapidar a qualidade obrigatória não eleva a satisfação. O ataque é na unidimensional e na atrativa
- Perguntar em dois numa só — determine o tipo pela combinação da pergunta funcional e da disfuncional. Com uma única pergunta a assimetria não aparece
- Decidir pelo tipo, não pelo número de pedidos — mesmo com muitos pedidos, se for qualidade obrigatória a satisfação não sobe
- Visualizar com o coeficiente Better-Worse — transforme em grandeza contínua as funcionalidades que se dividem na moda e decida o investimento nos 4 quadrantes
- A classificação de Kano é um instantâneo de um momento — a qualidade atrativa um dia se torna óbvia. Remeça periodicamente
- Olhar por segmento — não arredonde tudo para uma classificação única; para as funcionalidades importantes, combine com a segmentação
O modelo Kano não é um "método de análise sofisticado", e sim uma ferramenta que traduziu para o desenho de perguntas uma única percepção: "a satisfação tem assimetria". Bastando desenhar corretamente essa forma peculiar de perguntar em dois numa só, dá para elevar um patamar a qualidade da decisão no desenvolvimento de produto — de "construir na ordem do mais pedido" para "discernir o tipo e investir".
Quem quer desenhar uma pesquisa de modelo Kano de produtos e funcionalidades, que tal experimentar a ferramenta de pesquisa gratuita Kicue? O desenho das perguntas em dois numa só (funcional e disfuncional), a apresentação da descrição da funcionalidade e a exportação de CSV com ID de respondente — a parte de criar os dados de entrada da pesquisa de Kano você pode começar em uma única conta (a classificação pela tabela de avaliação, o cálculo do coeficiente Better-Worse e a criação do gráfico de dispersão ficam como operação combinada com Excel / R / Python).
Referências
- Kano, N., Seraku, N., Takahashi, F., & Tsuji, S. (1984). Attractive Quality and Must-Be Quality. Journal of the Japanese Society for Quality Control, 14(2), 147-156.
- Berger, C., Blauth, R., Boger, D., Bolster, C., Burchill, G., DuMouchel, W., ... Walden, D. (1993). Kano's Methods for Understanding Customer-Defined Quality. Center for Quality Management Journal, 2(4), 3-36.
- Matzler, K., & Hinterhuber, H. H. (1998). How to make product development projects more successful by integrating Kano's model of customer satisfaction into quality function deployment. Technovation, 18(1), 25-38.
- Mikulić, J., & Prebežac, D. (2011). A critical review of techniques for classifying quality attributes in the Kano model. Managing Service Quality, 21(1), 46-66.