O framework de priorização: Modelo Kano

O Modelo Kano é uma dos muitos frameworks de priorização, desenvolvido pelo Dr. Noriaki Kano, professor de gestão da qualidade na Universidade de Ciências de Tóquio 1984. O Modelo Kano se baseia na satisfacão dos clientes em relação as funcionalidades oferecidas, onde os recursos podem ser divididos em 4 categorias: performance, esperadas, atraentes e indiferente.

Você, como gerente de produto, se olhar para seu backlog, aposto que tem uma infinidade de features que precisam ser desenvolvidas – tem contribuições de sua equipe, stakeholders, clientes, clientes em potencial e qualquer pessoa com uma palavra a dizer sobre o produto.

Claro, que você não vai construir tudo que as pessoas estão solicitando. Você tem alguns palpites do que funciona e do que não é o ideal para o produto, mas você como um bom gerente de produto, você precisa de dados para tomar uma decisão.

Os dados existem para ajuda-lo a tomar uma decisão de impacto. Mas como você consegue saber:

• Como medir a satisfação do usuário?
• Como escolhemos o que construir para fornecê-lo?
• Como vamos além da satisfação para o  deleite ?

É aqui que uma ferramenta como o modelo Kano pode ser útil. É uma técnica simples e versátil para decidir quais recursos um produto ou serviço deve ter.

Neste artigo, examinamos as origens e os detalhes do Modelo Kano e exploramos um guia de cinco etapas para usá-lo para ajudá-lo a desenvolver um produto ou serviço que irá encantar seus clientes – sem levar seu negócio à falência!

O Dr. Noriaki Kano, professor de gestão da qualidade na Universidade de Ciências de Tóquio, criou o modelo em 1984. Como o autor Dave Verduynexplica, o Dr. Noriaki desenvolveu essa estrutura enquanto pesquisava os fatores que contribuíam para a satisfação e a lealdade do cliente.

Kano diz que um produto ou serviço envolve muito mais do que apenas funcionalidade. É também sobre as emoções dos clientes. Por exemplo, todos os clientes que compram um carro novo esperam que ele pare quando pisar no freio, mas muitos ficarão maravilhados com seu sistema de assistência ao estacionamento ativado por voz.

O modelo incentiva você a pensar sobre como seus produtos se relacionam com as necessidades de seus clientes, enquanto muda de uma abordagem “mais é sempre melhor” para o desenvolvimento de produtos para uma abordagem “menos é mais”. Os 3 princípios básicos são:

• O valor atrai clientes,
• A qualidade mantém os clientes e cria fidelidade,
• A inovação é necessária para se diferenciar e competir no mercado.

O Modelo Kano (pronuncia-se “kah-no”) é uma abordagem para priorizar recursos em um roadmap de produtos com base no grau em que eles provavelmente satisfarão os clientes. As equipes de produto podem avaliar um recurso de alta satisfação em relação aos custos de implementação, para determinar se a inclusão ou não no roadmap é uma decisão estratégica.

O modelo identifica cinco categorias de reações de clientes em potencial a um novo recurso, variando de insatisfação a indiferença, até o que muitos chamam de prazer ou excitação do cliente.

Usando o modelo, as equipes de produto reúnem uma lista de novas features em potencial que disputam recursos e espaço de desenvolvimento no roadmap. A equipe avaliará essas features de acordo com dois critérios concorrentes:

• Seu potencial para SATISFAZER os clientes.
• O INVESTIMENTO necessário para implementá-los.

O gráfico do modelo apresentado a seguir pode ser útil na definição de cada uma das categorias listadas. O eixo y é a satisfação do cliente e o eixo x é a implementação de features.

A estrutura do Modelo Kano é baseada em 3 fatores de analise:

• A satisfação dos clientes com as features de produto depende do nível de funcionalidade oferecido;
• As features podem ser classificados em quatro categorias ;
• Você identifica como os clientes se sentem atravês de um questionário de avaliação .

• Satisfação vs Funcionalidade

• Satisfação. O modelo Kano propõe uma dimensão que vai da satisfação total (também chamada de excitação) à total insatisfação (ou frustração), onde essa dimensão é anotada com diferentes níveis de satisfação.
• Funcionalidade. Também chamada de Investimento ou Implementação, ela representa quanto de uma determinada feature o cliente obtém, quão bem o implementamos ou quanto investimos em seu desenvolvimento. Essa dimensão vai desde a ausência de funcionalidade até a melhor implementação possível. É por isso que o termo “Investimento” também é muito bom para esse conceito.

Essas duas dimensões juntas são a base do Modelo Kano e determinam como nossos clientes se sentem sobre as features de nosso produto..

• As 4 categorias de features

Kano classifica as features em quatro categorias, dependendo de como os clientes reagem ao nível de funcionalidade fornecido.

1 – Performance (Performance)

A primeira categoria de features são as de perfomance. As características de perfomance são 1) cuidadosamente avaliadas pelo cliente e levadas em consideração ao fazer uma compra, 2) aumentam a satisfação do seu cliente quanto melhor você as implementar.

Por causa dessa relação proporcional entre Funcionalidade e Satisfação, essas features têm um efeito linear na satisfação do cliente (inclusive muitas vezes são chamadas de “linear”). Eles trarão satisfação para os usuários finais quando presentes e insatisfação quando ausentes.

Por exemplo, ao comprar um carro, o consumo de combustível geralmente é um atributo de desempenho. Outros exemplos podem ser a velocidade de sua conexão com a Internet; vida útil da bateria do laptop; ou o espaço de armazenamento em sua conta Dropbox. Quanto mais você tem de cada um deles, maior sua satisfação.

No gráfico do modelo, vemos a dinâmica de reação dos clientes a esse tipo de feature. Cada aumento na funcionalidade leva a uma maior satisfação. Também é importante ter em mente que quanto mais funcionalidades adicionamos, maior o investimento que temos que fazer (por exemplo, a equipe para construí-lo, os recursos necessários, etc.)

2 – Esperadas (Must-be)

A segunda categoria de features são as esperadas pelos clientes. Se o produto não os tiver, será considerado incompleto ou simplesmente ruim. Esse tipo de features é geralmente denominado  Obrigatório ou  Expectativas básicas . 

O problema com esse tipo de feature é: da perspectiva do cliente, os recursos de limite estão presentes ou não. Eles têm um efeito binário sobre a satisfação: se os usuários esperam uma certa capacidade e ela não funciona, eles ficam frustrados, mas quando funcionam bem, isso não os agradará. Essas características podem, no máximo, atingir uma satisfação neutra.

Além disso, eles não são fáceis de identificar, pois os usuários raramente os afirmam: eles simplesmente parecem óbvios demais para serem mencionados. Neste caso, repense a questão e em vez de perguntar, por exemplo:

Esperamos que nossos telefones sejam capazes de fazer chamadas. Nosso quarto de hotel deve ter água corrente e uma cama. O carro deve ter freios. Ter qualquer um deles não nos deixará felizes, mas a falta deles certamente nos deixará com raiva do produto ou serviço.

Observe como a curva de satisfação se comporta no gráfico acim. Mesmo o menor inveastimento contribui muito para aumentar a satisfação. Mas também observe como a satisfação nunca atinge o lado positivo – não importa o quanto investimos na feature, nunca deixaremos nossos clientes mais satisfeitos com o produto. A boa notícia é que, uma vez atingido um nível básico de expectativas, você não precisa mais investir nele.

3 – Atraente (Attractive)

Existem características inesperadas que, quando apresentadas, causam uma reação positiva. Essas são chamados de Atraentes. Podemos ter reações que variam de atratividade moderada a deleite absoluto, e ainda ter tudo se encaixando sob o nome “Atrativo”.

Esses tipos de features não resultam em insatisfação quando ausentes, e a experiência não é de forma alguma afetada negativamente, uma vez que nunca foram previstos. No entanto, se bem executado, surpreender os clientes com um atributo de prazer pode causar sua excitação excessiva com o produto (e possivelmente incentivar uma recomendação boca a boca).

A primeira vez que usamos um iPhone, não esperávamos uma interface de tela sensível ao toque tão fluida, e isso nos surpreendeu. Você sabe, aquela sensação que você tem quando experimenta algo além do que você conhece e espera de produtos semelhantes.

Um ponto muito importante ao avaliar features atraente” é fundamental avaliarmos o contexto do usuário e a experiência geral: os prazeres não funcionam com usuários frustrados cujas expectativas básicas não atendem. Você simplesmente precisam garantir as duas extremidades.

Além disso, investir em empolgação encanta os usuários, mas eles costumam ter vida curta.

O que costumava ser legal se torna ultrapassado em nenhum momento, especialmente na economia digital. O que antes era “a melhor coisa depois do pão fatiado” se torna comum, e o que costumava agradar os clientes se torna básico, esperado e necessário.

Depois que os concorrentes começam a implementá-los junto com todos os outros no mercado, os prazeres gradualmente mudam seu caminho para as expectativas básicas. Em conseqüência, novos devem ser fornecidos continuamente.

Dica: não precisamos ficar extremamente surpresos para que algo se enquadre nessa categoria. Pode ser qualquer coisa que te faça pensar:  “Ei, que legal!”.

Isso é melhor explicado graficamente. Veja como até mesmo algum nível de Funcionalidade leva ao aumento da Satisfação e com que rapidez ela aumenta. Esse fato é a chave para controlar o investimento que fazemos em um determinado recurso. Além de um certo ponto, estamos apenas exagerando.

4 – Indiferente (Indifferent)

Naturalmente, também existem características para as quais nos sentimos  indiferentes . Aquelas cuja presença (ou ausência) não faz diferença real na nossa reação ao produto.

Esses recursos estão no meio da dimensão Satisfação (onde o eixo horizontal os cruza). Isso significa que não importa quanto esforço colocamos neles, os usuários realmente não se importarão. Essa é outra maneira de dizer que devemos realmente evitar trabalhar nisso, porque você pode desperdiçar recursos valiosos.

Bonus: Reversas

O recurso é considerado reverso quando sua ausência traz a satisfação do cliente e sua presença resulta em insatisfação. Esses são os que você deseja identificar e manter fora do seu produto. A implementação de tais recursos aumenta os custos de design e desenvolvimento, enquanto diminui o valor do produto para os clientes.

Um pequeno exemplo desse tipo de qualidade foi o pequeno “ajudante de clipe de papel” da Microsoft. A maioria das pessoas não gostava e era ainda mais irritante porque era difícil desligá-lo, a menos que você soubesse o segredo para desativá-lo.

• O questionário de percepção Kano

Para descobrir as percepções de nossos clientes em relação aos atributos de nosso produto, precisamos usar  o questionário Kano. Ele consiste em um par de perguntas para cada feature que queremos avaliar:

1. Como se sentem SE possuem a feature; Essa primeira pergunta é chamada de forma funcional
2. Como se sentiriam SE NÃO tivessem a feature;  A segunda pergunta é chamada de forma disfuncional (também são chamadas de  positiva e negativa  por  Jan Moorman )

Essas perguntas não são aplicadas como uma pergunta aberta, na verdade, fazemos essa pergunta e usamos uma Escala Likert para a resposta. Para cada “como você se sentiria se tivesse / não tivesse essa feature”, as respostas possíveis são:

• Gosto disso;
• Espero isso;
• Sou neutro;
• Posso tolerar isso;
• Não gosto disso;

Com as respostas mapeadas, nós fazemos uso da tabela de avaliação que combina as respostas funcionais e disfuncionais em suas linhas e colunas (respectivamente) para chegar a uma das categorias descritas anteriormente. Cada par de respostas leva a uma dessas categorias e a mais algumas decorrentes do uso desse formato de pergunta.

Dado o fato de que estamos perguntando dos dois lados da mesma coisa, seremos capazes de dizer se:

• Alguém não entendeu totalmente as perguntas ou features que estamos descrevendo;
• O que propomos é na verdade o oposto do que eles querem.

Devemos tentar internalizar como cada categoria é derivada de um par de respostas, para entender melhor o modelo e evitar a necessidade de consultar a tabela todas as vezes:

• R – Reverso. Se alguém disser que “não gosta” da versão funcional e “gosta” da versão disfuncional, essa pessoa claramente não está interessada no que estamos oferecendo e talvez realmente queira o oposto.
• Q – Questionável. Ao obter respostas conflitantes (como “Gosta” e “Gosta”) para ambas as perguntas, você tem uma resposta questionável.
• P – Perfomance. São aqueles em que os clientes “Gosta” de tê-los e “Não gosta” de NÃO tê-los . Essa reação extrema traduz a relação linear “mais é melhor” entre essas duas dimensões.
• M – Must-be (obrigatórios). Features obrigatórios são os casos restantes em que o cliente  “não gosta de não tê-los”. Os clientes esperam ter a feature.
• A – Atraentes.Features atraentes são encontrados quando um cliente “gosta de ter” e não ficou surpreso pela sua existência. Essa é outra maneira de dizer que o que estamos propondo é novo e atraente.
• I – Indiferentes. Eles ocorrem para qualquer resposta “Eu sou neutro” ou “Eu posso tolerar isso”, para as questões Funcionais ou Disfuncionais. Ou seja, ocupam as células intermediárias da tabela.

Agora que temos uma compreensão da estrutura do Modelo Kano, é hora de entender o passo a passo para coloca-lo em prática e analisar os resultados. Nosso objetivo como gerentes de produto é determinar quais features levam a clientes mais satisfeitos e usar essas informações para nos ajudar a priorizar o que precisamos construir. 

Etapa 1 – Escolha as features e usuarios

• Escolhendo as features

As features que você escolhe são aquelas que o usuário vai receber um benefícios ao utiliza-la. Como estamos medindo a satisfação do cliente com nosso produto, precisamos avaliar features que ele irá fazer uso. Por isso, não adicione débitos técnicos, mudanças de framework ou fornecedor.

Faça uma lista com todas as features que você vai avaliar. Você pode ver um exemplo na tabela abaixo:

Dica: limite a quantidade de features que você inclui em sua pesquisa, especialmente se estiver fazendo o estudo com participantes voluntários. Isso deve melhorar seus níveis de participação e a atenção disponível de seus assuntos.

• Selecionando os clientes

Ao selecionar clientes (ou prospectos) para participar de seu estudo, você deve considerar algum grupo demográfico ou persona a que pertençam. Sua base provavelmente não é homogênea e o que eles pensam de sua feature também não é. Mas se você levar em consideração algum agrupamento ao qual eles pertencem, você pode reduzir significativamente o ruído em sua análise.

Por exemplo, suponha que você esteja trabalhando em um SaaS B2B. Se você está pensando em adicionar uma feature que permite aos usuários associar faturas a pedidos de compra, sua atratividade para uma pequena empresa é muito diferente de um cliente corporativo.

Etapa 2 – Obtenha os melhores dados dos usuários

• Escreva perguntas claras

Escreva suas perguntas o mais claras e sucintas possível. Cada um deve representar uma unica feature e se a feature for complexo e exigir várias etapas e subprocessos, você provavelmente deve analisar a questão.

Suas perguntas devem ser formuladas em termos de benefícios para o usuário , e não em termos do que o produto será capaz de fazer. Por exemplo, “se você pode melhorar automaticamente a aparência da sua foto, como você se sente?” é melhor que “se você tem MagicFix, como se sente?”.

Atenção: Tenha cuidado com as palavras polares dos pares de perguntas. Ou seja, a questão disfuncional não é necessariamente o oposto da funcional; é apenas a ausência da funcionalidade.

• Mostre as features

Sempre que possível, descreva os benefícios de uma feature, em seguida, mostrar um protótipo e wireframes, e por fim, faça a pergunta sobre como ele se sente. Por ter essa “explicação” visual e dinâmica, o usuário pode ter uma compreensão mais clara do que está sendo proposto a ele.

Dica: lembre de perguntar como ele se sentiria logo após o uso ou apresentaçao da feature. Dessa forma sua memória ainda esta fresca.

• Pergunte a importância da feature

Um acréscimo importante ao framework Kano^, é incluir a pergunta “pergunta aos clientes o quão importante um determinada feature é para eles” após o par funcional / disfuncional.  Esta informação é útil para saber quais features são as mais relevantes para os clientes.

A pergunta de importância pode ser feita no seguinte formato: “Quão importante é ou seria se: <requisito>?”. Por exemplo, “Quão importante é ou seria se: a exportação de vídeos sempre leva menos de 10 segundos?”.

Dica: As respostas devem ser na forma de uma escala de 1 a 9, indo de “Nada importante” a “Extremamente importante”.

Etapa 3 – Analise os resultados

Depois de tabular e processar os resultados, devemos ser capazes de categorizar as features e obter insights sobre a melhor maneira de priorizá-los.

Existem dois níveis de análise em que podemos entrar: discreta e contínua. Esses não são termos oficiais, mas foi o que eu encontrei nas minhas pesquisas. Ambos são referências a conceitos matemáticos e se relacionam com a forma como eles mapeiam as respostas dos participantes às categorias de Kano.

• Análise discreta

A maneira mais simples de trabalhar com os resultados do Kano é:

1. Divida os respondentes pelos critérios demográficos / pessoais que os definem;
2. Categorize as respostas de cada entrevistado usando a tabela de avaliação;
   1. Etapa 1 – Para cada feature que deseja avaliar;
   2. Etapa 1 – Faça as 2 perguntas para respondente;
   3. Etapa 1 – E categorize na tabela de avaliação;
3. Calcule o total de respostas em cada categoria;
4. O resultado será a resposta mais frequente;
5. No caso de resultados próximos entre categorias, use a seguinte regra (ganha mais à esquerda): Esperada (must-have) –> Performance –> Atrativa –> Indiferente;
6. Se você pediu aos entrevistados uma classificação de importância declarada (e deveria), faça a média para cada característica.

Você acabará com uma mesa como esta:

Se você estiver vendo vários resultados sem uma categoria clara, pode haver perfis de clientes ocultos que você não está considerando. Nesse caso, você provavelmente deve voltar às respostas do cliente para procurar padrões; tente verificar quais respostas dos clientes geralmente são iguais às de outros clientes, para encontrar “grupos demográficos” que você pode estar perdendo.

Este tipo de análise é ótimo para lhe dar um primeiro nível de compreensão e é útil em muitos contextos onde você não precisa de uma abordagem mais rigorosa. Por exemplo, testar ideias de design ou fazer um rascunho de seu roadmap.

RESULTADO: Na tabela de resultados, você pode classificar as features de acordo com sua importância. Depois disso, a regra geral a ser usada ao priorizar é ir atrás de todos os features “Esperada”, adicionar o máximo de features de “Perfomance” que puder e, finalmente, incluir alguns “Atrativas”.

• Análise continua

Primeiro, cada opção de resposta é traduzida em um valor numérico dentro de uma  escala de potencial de satisfação , indo de -2 a 4. Quanto maior o número, mais uma resposta reflete o quanto o cliente deseja a feature. A importância também é pontuada de 1 a 9, como antes.

• Funcional : -2 (não gosta), -1 (vive com), 0 (neutro), 2 (deve ser), 4 (gosta);
• Disfuncional : -2 (gosta), -1 (deve ser), 0 (neutro), 2 (viver com), 4 (não gosta);
• Importância : 1 (Nem um pouco importante), …, 9 (Extremamente importante.)

Pontuações mais altas (positivas) significam maior potencial de satisfação. No caso de respostas disfuncionais, “Não gostar” de algo significa que há uma forte discordância com a ausência da feature. Assim, haveria mais potencial de satisfação se fosse incluído e por isso tem uma pontuação maior.

A razão para esta escala assimétrica  (começando de -2 em vez de -4) é que as categorias que você obtém de  respostas na extremidade negativa (reversa e questionável) são mais fracas do que você obtém na extremidade positiva (deve ser e desempenho) . Assim, DuMouchel decidiu enfatizar esse lado da escala.

Essas pontuações levarão à categorização de nossas características dentro de um plano bidimensional. Com este método, não há mais necessidade da tabela de avaliação padrão .

Nosso  foco deve estar no quadrante positivo, que contém as respostas mais fortes. Fora dele, encontramos respostas mais fracas, bem como categorizações questionáveis ​​e reversas. Se uma feature terminar como “Reversa”, você sempre pode usar o truque de defini-lo como o oposto e alternar as pontuações “Funcional” e Disfuncional, para que seja classificado em outra categoria Kano; você também pode retirá-lo de seu estudo.

• Categorizando as features

Se tivermos números para cada resposta possível, isso significa que podemos trabalhar com médias. Aqui está o que precisamos calcular para cada feature:

1. Os valores médios funcionais, disfuncionais e de importância de todas as respostas;
2. O desvio padrão para as pontuações Funcionais, Disfuncionais e Importância.

Pegando as pontuações Funcionais e Disfuncionais de cada feature, podemos colocá-los no plano de categorização:

É claro que estamos falando sobre médias e o que elas escondem são as variações possivelmente grandes em nossos dados. É por isso que é útil adicionar o desvio padrão ao nosso gráfico na forma de barras de erro, para que tenhamos uma noção de como nossas categorizações estão dentro ou fora do alvo.

A camada final a ser adicionada é a pontuação de importância. Podemos visualizar essa dimensão adicional convertendo os pontos do gráfico de dispersão em bolhas, com tamanhos proporcionais à sua importância. Dessa forma, podemos comparar facilmente as features com posicionamento semelhante.

A regra geral de priorização apresentada na seção de análise discreta ainda é válida:

Esperadas (must-have) –> Perfomance –> Atrativas –> Indiferente

Para pequenos conjuntos de features, outra maneira de visualizar isso é por meio de uma lista de classificação de lista. Ele usa três colunas para classificar as features, nesta ordem (da pontuação mais alta para a mais baixa): potencial de insatisfação, potencial de satisfação e importância. 

Em nosso caso, as duas primeiras colunas são as pontuações disfuncional e funcional, respectivamente. 

O Modelo Kano pode ser um framework útil para equipes de produtos com tempo e recursos limitados, e que desejam garantir que priorizam o mix apropriado de features para trabalhar a seguir.

Essa abordagem é mais eficaz para as equipes que precisam de orientação para descobrir quais são os recursos mínimos que precisam criar, quais recursos de desempenho começarão a investir agora e quais recursos de satisfação do cliente oferecerão o maior cliente “Uau!”.

Como explica o consultor de gerenciamento de produtos Daniel Zacarias: “Existem muitas razões diferentes pelas quais você pode precisar incluir umm determinada feature, mas o que você faz para saber quais deles farão seus (futuros) clientes felizes e preferem isso a outros?”

O Modelo Kano pode ajudar as equipes de produtos a responder a essa pergunta muito importante.

Não há solução mágica quando se trata de priorizar os recursos de nosso produto. Embora tenhamos que considerar muitas dimensões diferentes, a satisfação do cliente é provavelmente a mais importante. Isso nos levou às perguntas das quais partimos:

• Como medimos a satisfação?
• Como escolhemos o que construir para fornecê-lo?
• Como vamos além da  satisfação  para o  deleite ?

Essas perguntas não têm respostas definitivas (se houver, todos nós precisamos procurar outro emprego)

O Modelo Kano é uma estrutura útil para equipes de produtos que procuram uma abordagem sistemática para priorizar features. Ajuda as equipes interessadas em priorizar as funcionalidades que eles acreditam que irão encantar os clientes.

Se tiver duvidas sobre como escolher o melhor framework de priorização para seu time, escrevi um artigo para ajuda-lo nessa tarefa, basta clicar no link a seguir.

Referências:

• Folding Burritos – Complete guide Kano Model (LINK);
• Wikipedia – Noriaki Kano (LINK);
• MindTools – Kano Model Analysis (LINK);
• Jan Moorman, “Measuring User Delight using the Kano Methodology”;
• Gary Burchill, “Observação do uso do método de Kano” em “Métodos de Kano para compreender a qualidade definida pelo cliente”, Center for Quality of Management Journal, outono de 1993;
• Robert Blauth, Reinhart Richter e Allan Rubinoff, “Experiência no uso dos métodos de Kano na especificação da BBN RS / 1 versão 5.0” em “Métodos de Kano para compreender a qualidade definida pelo cliente”, Center for Quality of Management Journal, outono de 1993;
• Mike Timko, “An Experiment in Continuous Analysis” on “Kano’s Methods for Understanding Customer-defined Quality”, Center for Quality of Management Journal, outono de 1993;
• UX Collective – Choosing the Right Features with Kano Model (LINK);
• Airfocus – Kano Model (LINK\);
• Pouliot, Fred, “Theoretical Issues of Kano’s Methods” on “Kano’s Methods for Understanding Customer-defined Quality”, Center for Quality of Management Journal, outono de 1993;