05 - Working Backwards - PR&FAQ
01 - Aprendizados do capítulo
Aqui estão as ideias reorganizadas, expandidas e unificadas em tópicos coesos:
1. A inversão fundamental: começar pelo fim
O Working Backwards é uma inversão da lógica tradicional de negócios. Em vez de criar um produto e depois tentar encaixá-lo no mercado, você imagina o produto já lançado em sua forma ideal — perfeito, do jeito que o cliente sonharia — e só então trabalha de trás para frente para construí-lo. O ponto de partida não é o que você consegue produzir, mas sim o que o cliente merece receber.
2. A experiência desejada como bússola
Toda decisão começa com uma única pergunta: qual é o grau máximo de experiência que o cliente pode ter? Não o mínimo aceitável, não o suficiente para cumprir o SLA — o máximo possível. Essa experiência ideal se torna a bússola que orienta cada escolha de processo, produto e entrega.
3. Entregar além do resultado esperado
Na Amazon, a entrega padrão é, na verdade, a entrega prioritária — não um piso mínimo, mas um compromisso inabalável. E o objetivo vai além: superar o esperado é o que transforma um cliente satisfeito em um cliente fiel. Entregar o combinado é obrigação; entregar além é diferencial.
4. Uma experiência ruim apaga várias experiências perfeitas
Tudo tem que estar perfeito porque o cliente não faz média. Uma experiência ruim tem peso desproporcional: ela é capaz de anular cinco experiências anteriores excelentes. Por isso a Amazon trata cada interação como se fosse a única que o cliente vai lembrar — porque muitas vezes é exatamente essa que ele vai lembrar.
5. Cultura: servir o cliente e melhorar a sociedade
Por trás de toda essa metodologia há uma crença mais profunda: o trabalho de uma empresa não é apenas gerar lucro, mas genuinamente servir as pessoas e, em escala, melhorar a sociedade. O Working Backwards não é só uma técnica de produto — é a expressão prática de uma cultura que coloca o ser humano no centro de cada decisão.
02 - O que é e como aplicar a tickets de TI
O que é o Working Backwards?
O Working Backwards é uma forma sistemática de validar ideias e criar novos produtos. Seu princípio central é começar definindo a experiência do cliente e trabalhar de trás para frente a partir desse ponto, até que o time alcance clareza total sobre o que construir.
Em vez da lógica tradicional — criar um produto e depois procurar clientes — a Amazon inverte completamente: começa pelo problema do cliente e deixa esse problema ditar a solução.
A ferramenta principal: o PR/FAQ
O PR/FAQ é um documento narrativo curto, tipicamente com cerca de seis páginas, com duas partes: um mock press release (comunicado de imprensa fictício) de uma página escrito a partir de uma data futura, anunciando o produto lançado como se ele já existisse — em linguagem simples, sem jargão — respondendo: Quem é o cliente? Qual problema isso resolve? Por que a solução é notável?
A lógica é simples: iterar num comunicado de imprensa é muito mais barato do que iterar no produto em si.
Ou seja: antes de escrever uma linha de código, contratar alguém ou gastar um real, você escreve como seria o dia do lançamento — e se esse comunicado não fizer o cliente querer o produto, a ideia precisa ser repensada antes de qualquer coisa.
Por que isso funciona?
A estrutura narrativa de um bom memo força um pensamento melhor e um melhor entendimento do que é mais importante — isso é o que diferencia o Working Backwards de simplesmente ter boas ideias.
O Working Backwards força os times a definir os benefícios para o cliente, as métricas de sucesso e os desafios potenciais logo no início, garantindo inovação centrada no cliente e visão mais clara do projeto antes de investir recursos.
Como aplicar isso no atendimento de tickets de TI?
Aqui está onde fica interessante. O Working Backwards não é só para criar produtos — é uma mentalidade que pode transformar completamente como um time de TI enxerga o seu trabalho.
A maioria dos times de TI pensa de dentro para fora: “Temos um sistema de tickets, temos SLA, o ticket foi fechado, missão cumprida.” O Working Backwards inverte isso: “Como seria a experiência perfeita para o usuário que abriu esse ticket?” — e aí você trabalha de trás para frente para construir o processo que entrega isso.
Na prática:
1. Comece pela experiência ideal do usuário final, não pelo processo interno
Antes de definir categorias de ticket, SLA ou fluxo de escalonamento, escreva como seria o relato do usuário após uma experiência perfeita de atendimento: “Abri o chamado às 9h, às 9h15 recebi uma resposta com a solução explicada de forma clara, sem precisar repetir o problema. O ticket foi resolvido remotamente sem que eu precisasse parar o que estava fazendo.” Esse é o seu ponto de chegada — agora trabalhe de trás para frente.
2. Use o FAQ para antecipar problemas recorrentes
Cada ticket repetido é uma pergunta que o usuário não deveria precisar fazer. Mapeie os 10 tickets mais frequentes do mês e crie um FAQ interno claro e acessível. Se o usuário consegue se ajudar antes de abrir o chamado, o time de TI ganha tempo para resolver o que realmente é complexo.
3. Escreva o “press release” do seu processo ideal
Imagine que daqui a 6 meses o atendimento de TI da sua empresa está excelente. Como seria o comunicado interno descrevendo isso? “O time de TI passou a resolver 80% dos chamados em menos de 2 horas, com satisfação de 95% dos usuários e zero tickets reabertos.” Agora pergunte: o que precisaria ser verdade para que esse comunicado existisse? Esse exercício revela os gaps reais do processo atual.
4. Classifique tickets pela causa raiz, não pelo sintoma
O Working Backwards aplicado ao suporte significa não se contentar em fechar o ticket — significa perguntar por que aquele ticket existiu. Um ticket de “não consigo acessar o sistema” pode ter como causa raiz uma política de senha mal comunicada. Resolver a causa raiz elimina uma família inteira de tickets futuros.
5. Meça o que o usuário sente, não só o que o time faz
SLA cumprido não significa usuário satisfeito. Implemente uma pergunta simples ao fechar cada ticket: “Sua problema foi resolvido de verdade?” Esse dado é o equivalente ao press release da Amazon — se a resposta for não, o processo precisa ser reescrito.
A síntese: o Working Backwards aplicado a TI transforma o suporte de um processo reativo (“fechar tickets”) em um processo proativo (“eliminar a necessidade de tickets”). O objetivo final não é atender bem os chamados — é que os usuários precisem abrir cada vez menos deles.