Quando você começa a centralizar feedback de clientes em uma ferramenta como Productboard, Harvestr, Dovetail ou um sistema próprio, uma pergunta aparece logo: como classificar direito feedbacks que não falam todos da mesma coisa?

Alguns comentários são bem concretos:

• um incômodo em uma tela;
• um pedido de feature;
• um comportamento do produto considerado ruim.

Outros são muito mais amplos:

• uma necessidade transversal;
• um job to be done;
• uma restrição de negócio;
• um objetivo de negócio.

É aí que as dificuldades costumam começar. O problema não é só "organizar melhor" o feedback. O problema é que um único modelo de classificação não basta.

A armadilha de classificar em um só eixo

Muitas equipes classificam o feedback segundo uma única lógica:

• por feature;
• por problema;
• por tema;
• por objetivo;
• por tipo de cliente.

O problema é que essa lógica funciona bem para uma parte do feedback, e depois fica capenga para todo o resto.

Uma abordagem focada só nas features é prática para os incômodos locais, mas reduz rápido demais o feedback a pedaços do produto. Aí você perde a lógica de negócio, a necessidade transversal ou a meta de negócio por trás.

Ao contrário, uma abordagem focada só nos objetivos mantém a visão de cima, mas fica vaga na hora de tratar um problema específico em um fluxo, uma tela ou uma interação.

Em outras palavras:

• um modelo local demais não tem recuo;
• um modelo global demais não tem precisão.

A necessidade real: cobrir todo o escopo sem virar um monstro

O desafio, então, não é adicionar cada vez mais categorias.

É preciso encontrar um modelo que seja:

• simples de entender;
• rápido de usar;
• robusto o suficiente;
• capaz de cobrir feedbacks que vão do muito estratégico ao muito tático.

É aí que mora toda a dificuldade.

Com poucas classificações, você mistura coisas que não estão no mesmo nível. Com classificações demais, você deixa o sistema chato de usar, e por isso mal adotado.

O bom modelo não é o mais "elegante" na teoria. É aquele que uma equipe consegue usar de verdade ao longo do tempo.

O modelo que eu escolho: 4 classificações

O modelo que eu escolho se apoia em 4 classificações:

1. Objetivo de negócio
2. Caso de uso / JTBD
3. Capacidade do produto
4. Ponto de atrito local

A ideia é simples: classificar um feedback pelo nível em que ele se expressa.

1. Objetivo de negócio

Falamos de objetivo de negócio quando o cliente expressa:

• uma meta de negócio;
• uma restrição de organização;
• uma prioridade operacional;
• um risco;
• uma ambição de transformação.

Exemplos:

• harmonizar as práticas entre várias equipes;
• reduzir um risco de conformidade;
• melhorar a gestão;
• absorver o crescimento sem contratar mais gente.

Nesse nível, o cliente ainda não fala de uma feature ou de um uso específico. Ele fala do que importa para a atividade dele.

2. Caso de uso / JTBD

Falamos de caso de uso / JTBD quando o cliente descreve o que ele busca realizar no trabalho dele.

Aqui estamos no nível da ação de negócio:

• qualificar um incidente;
• acompanhar um tratamento;
• comparar várias entidades;
• recuperar contexto antes de agir;
• coordenar várias pessoas.

Esse nível é particularmente útil, porque ajuda a entender o trabalho real sem prender a análise cedo demais em uma solução.

3. Capacidade do produto

Falamos de capacidade do produto quando o cliente expressa o que o produto deveria permitir fazer.

Por exemplo:

• configurar alertas;
• gerenciar permissões de acesso;
• consolidar um histórico;
• automatizar uma atribuição;
• ligar vários objetos ou eventos entre si.

Aqui não estamos mais no nível da meta de negócio, mas ainda não no nível de um incômodo local. Estamos no nível da capacidade esperada do produto.

4. Ponto de atrito local

Falamos de ponto de atrito local quando o feedback trata de algo específico no produto:

• uma tela;
• uma feature;
• um filtro;
• um botão;
• um formulário;
• um comportamento inesperado.

Exemplos:

• o filtro reseta;
• o botão de exportação é difícil de achar;
• um campo precisa ser preenchido de novo;
• um formulário é longo demais.

É o nível mais tático, mas continua indispensável. Um bom sistema de insights não pode perder essa granularidade.

A regra simples para classificar bem um feedback

Para evitar hesitações, eu adoto uma regra de triagem bem simples.

O cliente fala de uma meta de negócio ou de uma restrição de organização? → Objetivo de negócio

Ele fala do que busca realizar no trabalho dele? → Caso de uso / JTBD

Ele fala do que o produto deveria permitir fazer? → Capacidade do produto

Ele fala de uma tela, de uma feature, de um comportamento ou de um incômodo específico? → Ponto de atrito local

Essa regra tem um mérito essencial: ela evita classificar pelo assunto aparente, e leva a classificar pelo nível real do sinal.

Por que esse modelo me parece o melhor equilíbrio

Esse modelo de 4 classificações me parece mais sólido do que uma abordagem focada só nas features.

Por quê? Porque um feedback de cliente nem sempre fala de uma feature. Ele também pode falar:

• de uma necessidade transversal;
• de um problema de workflow;
• de uma restrição de organização;
• de um desafio de gestão;
• de uma expectativa mais estratégica.

Ao contrário, esse modelo também me parece mais útil do que uma abordagem focada só nos objetivos.

Por quê? Porque um bom sistema de gestão dos insights também precisa permitir recuperar o concreto:

• o que trava no produto;
• o que falta;
• o que merece uma melhoria local;
• o que pode alimentar diretamente discovery, design ou backlog.

Esse modelo, então, segura melhor o equilíbrio entre visão de cima e utilidade operacional.

Conclusão

Classificar todo o feedback dos clientes em um único eixo não basta. Funciona enquanto o feedback é homogêneo. Mas assim que você quer cobrir ao mesmo tempo objetivos de negócio, usos, capacidades esperadas e atritos bem locais, o modelo fica pobre demais.

O modelo em 4 classificações que eu escolho traz um equilíbrio melhor:

• Objetivo de negócio
• Caso de uso / JTBD
• Capacidade do produto
• Ponto de atrito local

Ele continua simples, cobre todo o escopo útil e pode ser usado em uma ferramenta de verdade sem virar um monstro.

É esse modelo que eu vou implementar no meu próprio projeto de Insight Manager. O objetivo não é só organizar melhor os comentários. O objetivo é ligar melhor a voz do cliente às decisões de produto, com um sistema leve o bastante para ser usado, e estruturado o bastante para continuar útil ao longo do tempo.

Para saber mais

O PM como arquiteto do Contexto O segundo cérebro é um beco sem saída para o product management