Recusar um pedido de funcionalidade sem perder a cliente

Fechar o ciclo geralmente significa dizer a alguém que o pedido dela foi lançado. A metade difícil, para a qual a maioria dos sistemas de rastreamento não tem processo nenhum, é dizer não. A maioria dos pedidos de funcionalidades nunca é lançada, o que significa que a maior parte do fechamento de ciclo que um produto realmente deve às suas usuárias é uma recusa, não um anúncio, e uma recusa mal conduzida custa mais boa vontade do que o silêncio teria custado. Bem conduzida, pode custar quase nada, porque o que quem pediu mais quer, na maioria das vezes, é saber que foi ouvida, não a funcionalidade em si.

Por que recusar bem importa tanto quanto lançar bem?

Porque o silêncio se lê como uma recusa sem explicação, e um não explicado se lê como atenção. Quem não ouve nada presume que o pedido foi ignorado ou perdido, e as duas conclusões ensinam a ela a parar de se dar ao trabalho de perguntar, o que é o mesmo resultado que um produto tem com uma recusa de verdade, só que alcançado mais devagar e com mais ressentimento pelo caminho. Uma resposta que diz não, claramente e com um motivo, fecha o ciclo tão completamente quanto uma funcionalidade lançada, e faz isso mais rápido.

O que faz uma recusa cair mal?

Quase sempre três coisas, combinadas. Genericidade: um “obrigada pelo feedback” pronto que não menciona o que realmente foi pedido se lê como se nem tivesse sido lido, mesmo que tenha sido. Atraso: uma recusa que chega seis meses depois do pedido, quando quem pediu já esqueceu que perguntou, parece pior que um não rápido, porque sugere que o pedido ficou parado em vez de considerado e recusado. E um motivo que não se sustenta: “não está no nosso roadmap” não responde nada, enquanto “isso exigiria redesenhar como as permissões funcionam, o que não planejamos mexer esse ano” dá a quem pediu algo que ela realmente pode avaliar e, se importar o suficiente, escalar ou contornar.

O que uma boa recusa deveria realmente dizer?

Quatro coisas, nesta ordem: um reconhecimento que nomeia o pedido específico, não uma paráfrase genérica; o motivo real, declarado honestamente mesmo quando o motivo honesto é “isso não se encaixa para onde o produto está indo” em vez de uma desculpa mais suave; se a porta está fechada ou só não está aberta agora, porque isso exige tons bem diferentes; e, quando existe, uma alternativa que atende à necessidade subjacente mesmo que não seja a funcionalidade pedida ao pé da letra.

Oi Jamie,

Obrigada pelo pedido de adicionar importação em massa de CSV para
convites de time. Avaliamos, e não vamos construir isso: nosso fluxo
de convite é construído em torno da revisão individual de cada novo
membro por motivos de segurança, e importação em massa iria contra
isso por design, não por descuido.

Se o problema real é convidar um time grande rapidamente, a API
suporta convites individuais via script, o que dá quase toda a
velocidade sem pular a revisão: [link]. Me avise se quiser ajuda para
configurar isso.

Repare o que isso faz que um template não consegue: nomeia a funcionalidade real, dá um motivo ligado a uma decisão de design de verdade em vez de uma política vaga, e oferece um caminho que resolve o problema subjacente em vez de só fechar o ticket.

Como isso difere de fechar o ciclo em uma funcionalidade lançada?

A mecânica é parecida, o tom não. Fechando o ciclo de feedback com o cliente cobre o caso lançado, onde a mensagem é boa notícia e o risco principal é esquecer de enviá-la. Uma recusa é má notícia, ou pelo menos notícia indesejada, e precisa de mais cuidado no motivo dado e menos automação na entrega: uma notificação de funcionalidade lançada pode ser um comentário de template disparado por uma mudança de status, mas uma recusa que se lê como template é exatamente a falha que essa abordagem inteira tenta evitar. Os dois compartilham uma exigência, porém: o pedido original tem que continuar ligado a quem o fez, a mesma disciplina de rastreamento que rastreamento de pedidos de funcionalidades cobre, senão não há como enviar nenhuma das duas mensagens individualmente.

Uma recusa deveria ser pública, como um status em um roadmap público?

Geralmente não o motivo específico, embora o status possa ser. Roadmap público cobre etiquetas de status que quem pediu pode conferir sem perguntar de novo, e um status “recusado” ou “não planejado” pode fazer parte desse sistema. Mas o motivo detalhado, especialmente quando toca prioridades internas ou contexto pouco lisonjeiro, geralmente vale mais na resposta individual do que em uma página de status pública, onde a mesma redação precisa funcionar para cada leitora em vez da única pessoa que realmente perguntou.

Todo pedido recusado merece uma resposta individual?

Todo pedido de uma pessoa nomeada e alcançável sim, pelo menos uma curta. Pedidos de alto volume, duplicados ou anônimos são a exceção: agrupar pedidos semelhantes e responder uma vez por grupo, ou atualizar uma etiqueta de status compartilhada, é razoável quando respostas individuais realmente não escalam. A linha a manter é que “não podemos responder a todo mundo individualmente” deveria ser uma restrição operacional real, verificada contra o volume real, não uma desculpa padrão para pular uma resposta que teria levado dois minutos.

FAQ

É melhor recusar rápido com um motivo fraco, ou tirar um tempo para um bom? Rápido, com um motivo honesto, vence os dois separados. Uma resposta rápida com um motivo real, mesmo curto, supera uma resposta lenta com uma polida; o próprio atraso é parte do que danifica a confiança.

Uma recusa deveria algum dia prometer reconsiderar o pedido depois? Só se isso for realmente provável e existir um mecanismo para realmente reconsiderá-lo, como uma etiqueta que o traz de volta em um ciclo de planejamento. Um vago “vamos manter em mente” sem tal mecanismo é funcionalmente o mesmo que silêncio, só formulado com mais gentileza.

E se o motivo honesto for algo que a empresa não pode compartilhar, como uma preocupação competitiva? Diga isso diretamente em vez de inventar um motivo mais suave. “Não podemos compartilhar o raciocínio específico aqui, mas isso não é algo que planejamos construir” é mais honesto, e mais respeitado, do que uma explicação inventada que desmorona diante de uma pergunta de acompanhamento.

Recusar um pedido significa que ele deveria ser apagado do rastreamento? Não. Mantenha-o, etiquetado como recusado com o motivo, para que faça parte do padrão contra o qual o próximo pedido semelhante é agrupado, e para que um contexto mudado depois (uma nova integração, uma nova prioridade de time) possa trazê-lo de volta em vez de começar a avaliação do zero.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Comparativo de ferramentas de changelog