A caixa de feedback são três trabalhos comprimidos numa cabeça cansada

Existe uma hora que todo product manager que conhecemos teme e nunca admite em voz alta. Ela chega na sexta à tarde, antes da reunião de roadmap, e funciona assim. Você abre a pasta. Dentro há algumas centenas de pedaços de feedback, tickets de suporte, um canal de Slack que ninguém cura, um par de transcrições de calls de vendas, um export de pesquisa, dois emails longos do mesmo cliente furioso. Você tem talvez sessenta minutos. Você lê os barulhentos, os que gritam, e entra na sala com uma sensação visceral que você chama de prioridade porque todo mundo concordou em chamar assim.

Os pedaços que você não leu não são ruído. Em algum lugar daquela pilha não lida está o terceiro cliente deste mês pedindo o mesmo formato de export, e você não vai encontrá-los, porque encontrá-los nunca foi um trabalho de leitura. É um trabalho de contagem, e a sua sexta-feira acabou.

Nós vimos gente inteligente perder essa hora por anos, e o que finalmente entendemos é que ela não é uma hora que você ganha lendo com mais afinco. A caixa de feedback não é um problema de leitura. São três trabalhos comprimidos numa cabeça cansada, e ninguém é dono dos dois que decidem o roadmap. Essa frase é o post inteiro, e vamos voltar a ela sem parar, porque toda ferramenta já construída para essa hora errou da mesma forma, atacando o único trabalho que nunca foi o gargalo.

O que os três trabalhos de fato são

Sente-se com o trabalho por um segundo, porque o esgotamento mora no formato dele, não no volume. A hora são três tipos diferentes de labor usando uma única fantasia.

O primeiro é ler, pegar cada item e entender o que ele diz. O segundo é agrupar, reconhecer que onze itens espalhados por seis semanas são secretamente um único pedido, e manter uma contagem corrente de todos eles ao mesmo tempo. O terceiro é casar, conectar cada um desses clusters ao roadmap que você já tem, para saber quais pedidos já estão planejados, quais são gaps sem nenhum plano por trás, e qual trabalho planejado ninguém de fato está pedindo.

Esses não são três passos de um trabalho. São três habilidades cognitivas diferentes, e um humano sob prazo consegue segurar mais ou menos uma delas por vez. A caixa de feedback não é um problema de leitura; são três trabalhos comprimidos numa cabeça cansada, e a crueldade é que os dois trabalhos em que o humano é pior são os dois que decidem o que você constrói. Vamos mostrar onde cada um quebra, voltando àquela PM e àquela pasta.

O trabalho que todo mundo otimiza é o que nunca foi o problema

Aqui está o que toda ferramenta vendida para aquela hora tem em comum: ela torna a leitura mais rápida. Resume cada ticket. Marca com sentimento. Joga num dashboard com uma boa barra de busca. Agora ela passa por sessenta itens na hora em vez de quarenta.

Parece progresso e não muda nada, e o sinal é brutalmente simples: ela ainda sai com os itens mais barulhentos, só que mais deles. Um ticket mais curto ainda é um ticket. O sumarizador comprimiu cada item e não fez nada sobre a relação entre os itens, e a relação entre os itens é onde todo o sinal mora. O terceiro cliente pedindo o mesmo export não é barulhento em nenhum ticket isolado. São três tickets quietos que só significam algo quando você os coloca lado a lado, e um leitor mais rápido lendo um item por vez não consegue ver isso mais do que um leitor mais lento.

Resumir a caixa de feedback torna cada pedido mais curto. Não faz nada quanto ao fato de que os pedidos são secretamente o mesmo pedido.

Essa é a armadilha, e vale nomeá-la com clareza porque é a razão de não termos construído um dashboard melhor. O mercado otimizou a leitura porque a leitura é a parte visível da dor, é a parte que parece o trabalho. Mas a leitura sempre foi o trabalho barato. Os trabalhos caros são invisíveis: você não consegue ver o cluster que não foi feito, e não existe mensagem de erro para “você lançou a coisa errada porque nunca contou a coisa certa”. A caixa de feedback não é um problema de leitura. Um leitor mais rápido ainda entrega os quarenta mais barulhentos.

Ambas as pistas partem da pilha idêntica. Uma termina com uma lista mais curta e o mesmo ponto cego. A outra termina com uma contagem, e uma contagem é algo com que você pode decidir.

Agrupar é o trabalho que um humano cansado é feito para falhar

Esse é o segundo formato, e é o que quietamente nunca chega a ser feito.

Para saber que onze tickets são um único pedido, alguém tem que ler todos os onze, reconhecer que “deixa eu escolher as colunas no CSV”, “o export está faltando campos que eu preciso” e “consigo customizar o download do relatório” são um único pedido em três fantasias, e segurar uma contagem corrente sobre a pilha inteira sem perder o fio. Isso não é uma habilidade de leitura. É uma habilidade de working memory, e um humano esgotado no fim de uma semana consegue segurar mais ou menos sete coisas na cabeça, não trezentas. Então o agrupamento não acontece. O que acontece em vez disso é que recência e volume vencem: o ticket desta manhã parece urgente, o cliente que mandou email duas vezes parece dois clientes, e os onze tickets quietos espalhados por seis semanas parecem onze coisinhas pequenas e não relacionadas, nenhuma merecendo um slot no roadmap, quando juntas são a única feature mais pedida que você tem.

Repare que isso não é uma falha de disciplina. É o tipo de trabalho para o qual humanos são fisicamente inadequados. E é exatamente o tipo de trabalho para o qual um sistema é feito, não porque é esperto, mas porque não fica entediado no item duzentos, não favorece o ticket desta manhã sobre o de cinco semanas atrás, e consegue segurar a pilha inteira à vista de uma vez e perguntar, de cada par, esses dois são secretamente um só. O que volta não é um resumo. É uma estrutura: não trezentos itens, quarenta pedidos, cada um carregando o número real de clientes por trás dele.

E aqui está a parte que importa para que tipo de coisa estamos construindo. Esse agrupamento não é uma feature que escrevemos para product managers. É o que um sistema é quando lembra de tudo que já leu e nunca se cansa de segurar tudo de uma vez. A caixa de feedback do PM é agrupada pela mesma razão que toda outra pilha na empresa é agrupada, temas de suporte duplicados, bloqueadores de deal recorrentes, a mesma objeção surgindo em cinco calls de vendas. Não adicionamos uma feature de agrupamento. Construímos um substrato que não esquece, e o agrupamento cai dele. A caixa de feedback não é um problema de leitura; são três trabalhos comprimidos numa cabeça cansada, e este é o segundo ponto cego da cabeça, o que nenhuma quantidade de esforço conserta, só um tipo diferente de memória conserta.

Casar é onde a contagem finalmente vira uma decisão

Um cluster perfeito ainda morre se terminar numa planilha. O terceiro trabalho, o que transforma contar em decidir, é conectar cada cluster ao roadmap que você já tem.

A forma como isso acontece hoje é uma reunião. Os clusters, se é que existem, são lidos em voz alta, e alguém diz “isso é meio parecido com o épico de relatórios que escopamos no Q2”, e outra pessoa diz “não, isso está mais perto do trabalho de integrações”, e a sala litiga ao vivo, de memória, conduzida por quem por acaso lembra melhor do roadmap. Metade das vezes um cluster que mapeia limpamente sobre um épico em andamento é tratado como trabalho novo, e o time escopa uma segunda coisa para fazer um trabalho que uma coisa planejada já faz. Na outra metade, o output mais valioso da hora inteira nunca aparece: um cluster com onze clientes por trás que mapeia sobre nada no roadmap, um pedido real e popular que simplesmente não está planejado. Trazer isso à tona exige segurar o feedback agrupado e o roadmap inteiro numa cabeça só no mesmo momento, e ninguém consegue.

Casar é um trabalho de traçar-a-linha-entre-duas-listas. De um lado, os pedidos agrupados com suas contagens. Do outro, os épicos e specs já em andamento. Três linhas precisam ser traçadas: este cluster é aquele épico, suba a prioridade dele; este cluster mapeia para nada, sinalize o gap; este épico mapeia para nenhum cluster, pergunte por que você está construindo. Nenhuma dessas três linhas é traçada de forma confiável por uma pessoa cansada sob uma hora de pressão. Todas as três são traçadas da mesma forma por algo que consegue ler as duas listas de uma vez e nunca precisa lembrar de nenhuma delas, porque já mora onde o roadmap mora. Essa última cláusula é a quieta que sustenta tudo: o casamento funciona apenas porque o mesmo sistema que leu o feedback também segura o roadmap, os specs, as coisas em andamento. Ele não está alcançando uma ferramenta estrangeira. O roadmap é só mais uma coisa que ele já conhece.

Os três resultados à direita daquele funil são o ponto da hora. Nenhum é alcançável lendo mais rápido. Todos são alcançáveis por uma coisa que lê tudo, lembra de tudo, e mora onde o trabalho já está.

Por que isto nunca ia ser uma ferramenta que você comprava

Você poderia comprar três produtos para isso. Um sumarizador para a leitura, um sistema de tags para o agrupamento, um board de roadmap para o casamento. Empresas fazem exatamente isso, e a pilha ainda vence, e a razão é estrutural, não uma falha de qualquer produto isolado.

O output de cada trabalho é o input do próximo trabalho. O cluster não vale nada sem uma leitura honesta de cada item. O casamento não vale nada sem o cluster. A mudança de prioridade, a decisão de fato, não vale nada a menos que flua direto de volta para o roadmap a partir do qual o time trabalha. Três ferramentas significam três handoffs, e todo handoff é um lugar onde um humano cansado carrega o output de um trabalho para o input do próximo na mão, numa sexta, com vinte minutos sobrando. Os handoffs são onde o trabalho morre. Você não conserta um problema de um-único-dono comprando três donos que não se falam.

Então a coisa que dissolve essa hora não é uma quarta ferramenta melhor no stack. É algo que já leu o feedback porque está ligado, já o agrupou porque não esquece, e já segura o roadmap porque é onde ele mora, então os três trabalhos não são três handoffs, são um único movimento contínuo que ninguém precisa babá. Isso não é uma feature que apontamos para product managers. É o que um sistema operacional para uma empresa é, virado para uma das muitas horas que ele quietamente absorve. A caixa de feedback faz sua própria triagem da mesma forma que a renovação prestes a escapar aparece sozinha e o follow-up esquecido se cobra sozinho, não porque lançamos um produto de triagem, um produto de renovações e um produto de follow-up, mas porque um único substrato que observa, lembra e tem permissão de agir faz tudo isso cair de uma vez. A amplitude não é vaidade. É a evidência de que o substrato é o certo.

O que sobra quando a hora já está feita

Imagine a PM mais uma vez. A pasta está aberta, mas a leitura, o agrupamento e o casamento já estão terminados quando ela se senta. O que ela de fato faz agora?

Ela decide. Esse sempre foi o trabalho inteiro, ele só estava enterrado sob algumas centenas de coisas que ela nunca alcançaria. Agora ela está olhando para quarenta pedidos reais em vez de trezentos brutos, cada um com uma contagem verdadeira, cada um já alinhado contra o roadmap, o cluster de onze clientes sem nenhum plano por trás sentado bem no topo, impossível de não ver. E ela faz a única coisa que nenhum sistema pode fazer por ela: ela escolhe.

Porque contar não é decidir, e somos cuidadosos para nunca confundir os dois. Um sistema pode dizer a ela que onze clientes querem o export. Não pode dizer se eles importam mais do que três contas enterprise pedindo quietamente por SSO, ou se o cluster barulhento é barulhento porque é importante ou só porque é fácil de colocar em palavras. Esse julgamento, o que esta empresa deveria perseguir, de quem a dor vale um trimestre de engenharia, é dela, e sempre será. A pilha nunca foi o trabalho. A pilha era a coisa entre ela e o trabalho.

Este é o mundo para o qual estamos construindo, e ele ainda não está no mercado, porque o mercado ainda está vendendo formas mais rápidas de ler a pilha. Nós achamos que a pilha não deveria nem chegar a um humano. A caixa de feedback não é um problema de leitura, são três trabalhos comprimidos numa cabeça cansada, e a resposta nunca foi um leitor mais esperto. É uma empresa que roda sobre um sistema que já leu tudo, já lembra de tudo, e já mora onde as decisões são tomadas, para que o único julgamento que sempre foi seu pare de se afogar nos dois que nunca deveriam estar ali.

---

É isso que estamos construindo na Apollo Space: não um dashboard que você rola numa sexta, mas uma empresa onde a pior hora da semana já está terminada quando você entra, para que a decisão mais importante da sala receba sua atenção inteira em vez dos seus últimos vinte minutos. A intuição da PM nunca foi o problema. Ela só nunca teve a contagem para sustentá-la.