Priorizar é preciso!
E Noriaki Kano nos ajuda.
Começo me arriscando a dizer: desde os produtos nos ciclos mais iniciais de vida até os mais maduros, uma verdade reina absoluta — sempre há muitas melhorias a serem feitas.
Escutar os usuários e clientes, na minha humilde opinião, é uma das tarefas mais divertidas e interessantes da vida do PM/PO, e são justamente essas conversas as maiores fontes de insights sobre o que pode mudar no produto para melhorá-lo.
No entanto, o que não é tão divertido assim é escutar tantas dores do dia a dia de diversas pessoas e saber que nem todas podem ser atacadas, muito menos ao mesmo tempo. Outra verdade que persegue a grande maioria das empresas (ou seriam todas, mesmo?) é que sempre tem mais coisa a melhorar do que time para desenvolver as melhorias.
Para lidar com essa equação, o caminho é priorizar. Ao mesmo tempo em que essa é uma tarefa instigante e interessantíssima, também pode causar bastante dúvida e tensão: queremos ter certeza de que estamos colocando em primeiro lugar na fila as melhorias que terão o maior impacto para os objetivos da empresa e dos usuários ao mesmo tempo, e que atingirão positivamente a maior quantidade de pessoas possível. Exato, é bastante responsabilidade.
Para não ficarem sozinhos nessa, PMs e POs felizmente contam com inúmeras metodologias para ajudar na priorização. Esse post famoso reúne boa parte delas. O problema desse post é que precisamos de uma metodologia de priorização só para priorizar as metodologias de priorização sugeridas (risos). Para conseguir, então, escolher uma delas com mais segurança, li mais alguns posts de PMs de startups brasileiras sobre o assunto e um método começou a aparecer de forma bem recorrente: o Kano Model. Partiu Kano (com a ajuda desse guia maravilhoso)!
Técnica Kano Model
A técnica, criada pelo japonês Noriaki Kano, é baseada na relação entre o nível de investimento que a empresa dá para uma feature e a satisfação dos clientes/usuários/stakeholders com as features propostas para o produto. Cruzando esses dois elementos, temos quatro categorias de features:
Abaixo, um resumão sobre cada uma delas.
Performance
São aquelas features que, quanto mais o usuário tem, mais ele fica satisfeito. Por exemplo, a bateria de um celular ou a velocidade da sua internet.
Must-be
São as features que os clientes simplesmente esperam que o produto tenha. Ou seja, ter elas não vai necessariamente deixar a pessoa feliz porque… bem, a pessoa espera que o produto tenha elas para sequer existir. Já o cenário de não ter elas vai irritar muito o usuário. Por exemplo, esperamos que nosso celular faça ligações.
Attractive
São aquelas coisas que o usuário não está esperando, e deixam ele impressionado positivamente.
Indifferent
São features que não fazem a menor diferença para o usuário. Não importa o empenho que coloquemos nelas, o usuário realmente não se importará. Ou seja, não valem o investimento de dinheiro da companhia e energia/tempo do time.
Ok, mas como saber em que categoria se enquadra cada umas das features que estou querendo implementar? Descrevo abaixo o passo a passo que segui.
Seleção das features e participantes
O primeiro passo é selecionar da lista de features no backlog, aquelas que já são as mais bem cotadas. Seja porque você as validou com um teste de hipótese, seja porque os dados te mostram que ela é importante, seja porque ela atinge uma quantidade enorme de usuários ou seja porque é um grande feeling seu.
Depois eu selecionei as pessoas que iriam participar do estudo, os usuários ou pessoas que têm seus trabalhos diretamente afetados pelo produto. Aqui eu optei por uma certa diversidade, para levar em conta as diferentes opiniões na empresa e conseguir atacar o que de fato representa o melhor para todas as áreas, mas é preciso ter cuidado: muita heterogeneidade aqui pode levar a uma análise pouco focada. Cada grupo de pessoas vai "puxar a brasa para a sua sardinha", e não teremos um resultado muito produtivo.
Questionário Kano
Feito isso, precisamos conversar com as pessoas escolhidas. Para saber como nosso usuário percebe cada feature que temos em mente para o produto, devemos entrevistá-lo através de duas perguntas básicas, uma positiva e outra negativa:
1- Como você se sentiria se tivesse essa feature?
2- Como você se sentiria se não tivesse essa feature?
O ideal é adaptar ambas as perguntas para cada feature que você selecionou para avaliar, colocando na pergunta o benefício (ou não) que ela traria. Segue um exemplo:
1- Como você se sentiria de pudesse buscar por produtos em nosso aplicativo através de um campo de busca?
2- Como você se sentiria se tivesse que buscar manualmente por um produto na lista total de produtos?
Para cada pergunta, devemos dar 5 opções de resposta (você pode adaptar levemente o texto, mantendo a ideia). Coloco abaixo como eu utilizei:
1- Eu gostaria
2- Eu acho isso básico/isso é esperado por mim
3- Sou neutro
4- Seria um incômodo leve
5- Seria um grande problema
Isso, até onde eu lembro, não está no post do método, mas foram orientações que eu dei para pessoal entrevistado:
1- Ser criterioso: todas as features apresentadas foram pré-selecionadas, ou seja, tudo da lista tendia a ser muito legal! Orientei as pessoas a serem críticas, já que eu, sinceramente, "gostaria" de tudo que estava lá, e elas provavelmente também.
2- As perguntas são opostas, mas as respostas não precisam ser: orientei as pessoas a encararem cada uma das perguntas como única, sem fazer correlação ou "manter coerência" com a resposta da outra. Ou seja, não é porque eu marquei que gostaria de algo, que preciso dizer que não ter esse algo é um grande problema. Posso gostar muito de ter algo, mas ser indiferente de não ter, por exemplo.
Análise das respostas
Com todas as respostas em mãos, basta usar o quadro abaixo para categorizar como cada pessoa entrevistada vê cada feature proposta. As letras no quadro são as iniciais das categorias citadas no início desse texto. Você deve "cruzar" a resposta das duas perguntas e achar onde a feature se enquadra. No meu caso, se a pessoa falou "eu gostaria" na pergunta positiva, e "sou neutro" na negativa, essa é uma feature "A (attractive)" para essa pessoa.
Relembrando as categorias:
P- Performance
M- Must-be
A- Attractive
I- Indifferent
Vocês vão notar que temos, no quadro, mais duas categorias além das quatro do início do texto. As "Q (questionable)" e as "R (reverse)".
Questionable
Uma vez que as perguntas positivas e negativas são opostas, é bastante estranho que alguém diga que quer muito algo e, depois, que quer muito não ter esse algo. No meu exemplo, seria o caso da pessoa marcar "eu gostaria de ter um filtro de busca" e, ao mesmo tempo, "eu gostaria de procurar os produtos na mão". Nesses casos, provavelmente a pessoa não entendeu muito bem a pergunta ou a feature proposta. Felizmente no meu caso, não obtive nenhum "Q", ou seja, todos aparentemente entenderam o que eu quis dizer.
Reverse
São os casos em que a pessoa quer exatamente o oposto do que estamos propondo. Seguindo o exemplo, se a pessoa marcar "seria um grande problema ter um campo de busca", e "eu gostaria de procurar os produtos na mão", desenvolver um campo de busca não deixaria essa pessoa muito contente. Ela quer o contrário da feature proposta.
No fim da minha análise, a tabela que eu terminei foi essa:
Agora, precisamos contar e juntar o que foi respondido (categorias) mais frequentemente para cada feature. Meu resultado:
Em caso de empate, use a regra M>P>A>I. Observem a minha feature 4: o P, A e I empataram para ela. Logo, ela é uma P.
Finalmente… priorizando!
Agora que temos o resultado, a ideia para priorizar é simples: colocarmos em nosso produto todas as features "Must-be", o máximo de "Performance" que pudermos, e algumas "Attractive".
No meu caso, o melhor para o produto na opinião dos entrevistados é focar nas features 4 e 7 primeiro, e depois nas features 3, 5 e 6.
É importante lembrar que essa análise não dura para sempre. As percepções e necessidades dos usuários mudam muito rapidamente, assim como rapidamente surgem novas melhorias para entrar na briga. Ou seja, a priorização (seja com o método Kano ou outro) é um exercício constante.
