Dev Mind - Kano Model

  • Rafael Miceli
  • 21 Fev 2017

Este post é uma continuação do Post anterior a respeito de como desenvolvedores geralmente decidem jogar um produto no mercado e como podemos fazer para antes validarmos nossa ideia e polir ela para atender ao mercado.

Dando continuidade a nossa etapa de Identificar necessidades não servidas podemos usar uma técnica para termos uma melhor visão do que priorizar para entrar em nosso MVP prototype.

Modelo Kano

Analisando as soluções coletadas das informações de problemas que seu potencial cliente passa separe elas usando o Modelo Kano. Neste modelo você divide as funcionalidade como Must Have, Performance Benefit e Delighter.

kano model

Must Have são funcionalidades que são de alta importância, mas que elas por si só não vão melhorar a satisfação do potencial cliente.

No caso da sua tia conseguir encontrar o remédio que ela busca é imprescindível, pois hoje ela já faz isso. Uma hipótese do que poderia ser um Performance Benefit seria você exibir o preço do remédio pesquisado em cada uma das farmácias próximas a ela. Uma hipótese de Delighter pode ser demonstrar o quanto você ecnomizaria com o remédio mais barato vs o mais caro em um período de tempo. Para que sua tia pereba o quanto ela vai economizar nesse período de tempo usando o App.

De acordo com o modelo Kano com a medida que o mercado que voxê está apontando amadurece o que era Performance Benefit se torna Must Have e o que era Delighter se torna Performance Benefit e novos Delighters são descobertos.

Um exemplo ilustrado disso podemos ver em softwares de ponto de venda para empresas de médio porte. Quando sincronizar suas vendas em um servidor central era um Performance Benefit hoje em dia é um Must Have da mesma forma que possuir um PDV que fosse Fault Tolerant ja foi um Delighter, hoje é um Performance Benefit.

comentarios com Disqus Disqus