A confiança perdida (Lost confidence)

• Frameworks de priorização baseados em confiança, como RICE, são em grande parte ruído, e é preciso uma forma de tomar decisões sem fingir que sabemos um futuro incerto
• Pontuações de confiança tendem a ser altas para projetos pequenos e baixas para projetos grandes, o que sistematicamente empurra projetos de alto valor para baixo e distorce a priorização
• Pontuações de confiança têm definição ambígua, faltam dados de validação, e como projetos quase sempre atrasam e geram menos impacto que o esperado, elas não são confiáveis
• A solução é perguntar, no campo da incerteza e não da probabilidade, "qual ação é sensata sob qualquer distribuição de probabilidade?"
• Em vez de confiança, é importante priorizar com técnicas como o que é sempre verdadeiro, impacto no cliente, preservação de opções e apostas assimétricas

---

Jogos de confiança (Confidence games)

• Muitos frameworks de priorização incluem na pontuação a confiança de que será possível entregar o impacto previsto com o esforço estimado
  • Entre dois projetos de mesmo valor e mesmo esforço, escolher o que tem maior confiança de execução é, por si só, razoável
  • Mas o uso real não é: "1) pontuar → 2) executar o vencedor claro → 3) em caso de empate, escolher o de maior confiança"
• O RICE coloca a confiança diretamente na fórmula de pontuação da etapa 1
  • Fórmula do RICE: Score = (Reach × Impact × Confidence) / Effort
  • Fórmula do RPS: Score = Reach × Potential × Solution Confidence
• Esse método trata dois cenários diferentes como equivalentes e cria uma falsa equivalência
  • uma funcionalidade incremental, pequena, mas seguramente executável
  • uma funcionalidade grande, com muito impacto, mas também com risco
• Em geral, projetos pequenos recebem alta confiança e projetos grandes recebem baixa; ao multiplicar isso na conta, você se afasta sistematicamente do caminho de maximizar o valor entregue
  • A própria motivação central do movimento Agile era o insight de que projetos grandes sempre deveriam ter baixa confiança de sucesso
• Motivos para não confiar em pontuações de confiança
  • A definição é ambígua: não está claro o que significa "30%". Em tese, seria preciso registrar a pontuação de confiança de todos os projetos e comparar depois com os resultados reais para calcular a precisão numericamente, mas na prática isso não é feito
  • Quando se lança só um pequeno número de funcionalidades importantes por ano, faltam dados suficientes até mesmo para validar isso retrospectivamente
  • Projetos quase sempre atrasam, e seu impacto é menor e mais lento que o esperado. Um projeto de 9 meses com 6 equipes também começou porque havia "algum grau de confiança"
• Citação da Lei de Hofstadter: "Sempre leva mais tempo do que você espera, mesmo quando se leva em conta a Lei de Hofstadter"
• Se você perguntar a PMs experientes por funcionalidades de que tinham certeza de que seriam bem recebidas, mas não foram, todos terão vários exemplos
  • Mesmo com conversas com clientes, pedidos explícitos e promessas de compra como base, quando a coisa é construída, muitas vezes nem quem prometeu usa de fato
  • Uma técnica para melhorar previsões: fazer o cliente explicar passo a passo como usaria aquilo no fluxo real de trabalho. Ao percorrer as etapas, a própria pessoa percebe coisas como: "isso exigiria reescrever meu código, então não vou fazer"
• O mesmo vale para criadores de conteúdo: textos publicados às pressas e sem expectativa acabam tendo o maior número de visualizações e reações do ano, enquanto obras em que se investiram dezenas de horas podem ser ignoradas
  • Os quatro quadrantes da matriz 2×2 de "havia confiança ou não × o resultado foi amado ou ignorado" estão cheios de exemplos

O que usar no lugar de confiança e risco (What to use in place of confidence and risk)

• A resposta está no campo da incerteza, não da probabilidade
  • Probabilidade pressupõe que você conhece a distribuição. Ao jogar uma moeda justa 100 vezes, é possível prever com alta confiança que o número de caras ficará entre 40 e 60
  • Quase tudo em uma startup é diferente disso. Sucesso, estratégia e funcionalidades são inéditos demais, complexos demais, ou têm variáveis de entrada imprecisas demais para que se possa atribuir probabilidades significativas
  • É o conceito de "Knightian Uncertainty" derivado da obra de 1921 do economista Frank Knight
  • Mesmo métodos bayesianos exigem probabilidades prévias numéricas e probabilidades condicionais, e ambas são desconhecidas ou impossíveis de definir
• A pergunta própria do domínio da incerteza é: "que ação é sensata independentemente da distribuição de probabilidade?"

• O que é sempre verdadeiro (True always)

  • Foque no que é sempre verdadeiro em qualquer cenário — o princípio dos long-term constants de Bezos
    • Usuários universalmente preferem software rápido e responsivo. Valorizam sincronização em segundo plano, interação imediata e funcionamento em qualquer dispositivo
    • Mesmo no pior caso, em que alguém não liga para velocidade, isso não é visto negativamente. No melhor caso, o desempenho se torna um diferencial central, como em Notion, Figma, Miro, Gmail e Google Docs
  • Nem toda funcionalidade tem apelo universal. Em vez de decompor tudo em números precisos, identifique funcionalidades que praticamente todos os clientes consideram valiosas ou pelo menos positivas
    • Às vezes isso é certo por obrigação. Requisitos corporativos como conformidade com SOC 2 podem não ser empolgantes, mas têm valor claro ao vender para empresas
    • Essa certeza compensa a falta de diferenciação
  • Ainda assim, as ideias mais inovadoras e diferenciadoras quase nunca entram na categoria de "absolutamente certas"
    • O que é certo tem valor, mas raramente vira um diferencial estratégico
    • Um grande produto precisa de melhorias confiáveis e também de saltos inovadores

• Descobrir rápido, recuperar rápido (Quick discovery, quick recovery)

  • Há muito tempo se defende validar ideias entrevistando sistematicamente potenciais clientes antes de construir, mas isso também cai na armadilha da confiança
    • Antes de construir, nunca dá para saber com certeza
    • Ainda assim, antes de construir é possível invalidar ideias e evitar desperdícios de meses ou anos, então continua sendo um bom ponto de partida
  • A solução típica é criar um SLC (uma evolução do conceito de MVP): um produto simples, mas completo, para obter feedback real — experiência em vez de previsão
    • O produto existente deve manter um portfólio equilibrado entre vitórias certas e apostas inovadoras, aplicando um método de validação diferente para cada uma
  • Exemplo de "funcionalidades dummy": um botão que, ao ser clicado, mostra "essa funcionalidade ainda não existe. Conte como você a usaria"
    • Isso gera um sinal real, por meio de comportamento, sobre quantas pessoas estão interessadas e quem pode virar entrevistado em potencial
    • É um sinal 100 vezes melhor do que pesquisa. Em pesquisa, é fácil dizer "sim"; clicar num botão exige interesse real. Comportamento observado vence intenção declarada

• Em vez de confiança, foque no impacto no cliente (Focus instead on customer impact)

  • Substitua confiança por impacto. O impacto é definido de duas maneiras
    • Regra da maioria (Majority rule): se a maioria dos usuários usa uma funcionalidade regularmente, ela é claramente importante e provavelmente é uma razão central de adoção e retenção
    • Defensores apaixonados (Passionate advocates): funcionalidades que criam fãs fervorosos em uma minoria. Pessoas que dizem "comprei só por causa disso". Não são universais, mas geram lealdade profunda em segmentos específicos (magnificent delighters)
  • Quando o usuário realmente ama uma parte específica do produto, ele tolera outras falhas
    • O apelo do iPod fez bilhões de pessoas tolerarem o iTunes, o pior software do mundo
    • Softwares lindamente projetados são aceitos apenas pela experiência de design, mesmo com ausência de funcionalidades ou limitações de plataforma
  • Definição quantitativa de funcionalidade de alto impacto
    • (1) pelo menos 51% dos clientes a usam regularmente, ou
    • (2) pelo menos 15% dos clientes a citam entre os 3 principais motivos para escolher ou continuar com o produto
    • É um critério elevado, mas funcionalidades inovadoras e arriscadas devem mesmo ter uma barra alta; a magnitude da recompensa precisa justificar o risco

• Invista em alavancagem (Invest in leverage)

  • Existem áreas em que pequenas mudanças incrementais geram grandes resultados
  • Há áreas de alavancagem que quase sempre valem por razões matemáticas e estruturais
    • (a parte relacionada à divulgação de livro foi excluída por ser publicidade)

• Maximize a opcionalidade (Maximize optionality)

  • Se não dá para conhecer o futuro, escolha o que maximiza o número de opções disponíveis quando você chegar lá
    • Isso vai além de simples flexibilidade ou evitar lock-in; trata-se de projetar para conseguir lidar com o que quer que aconteça
  • Exemplos
    • Manter custos baixos → preserva rentabilidade e permite experimentar vários preços e modelos de empacotamento, além de aumentar a resiliência futura
    • Escolher bibliotecas e frameworks de UI multiplataforma bem validados e ativamente desenvolvidos → ajuda a acompanhar a evolução de plataformas e dispositivos
    • Arquitetura de plugins → permite que você e a comunidade construam coisas hoje inimagináveis
    • Arquitetura API-first → conecta isolamento entre equipes, frontend, backend e integrações de clientes
    • Wrappers para serviços de vendors → permitem substituir fornecedores instáveis, caros ou atrasados
  • Preservar opções futuras exige trabalho extra hoje
    • Envolver a API de um vendor com um wrapper não agrega valor imediato
    • Isso é sensato em empresas maduras, em que estabilidade e previsibilidade são importantes, mas pode ser a escolha errada em estágios iniciais, quando é preciso vencer incumbentes pela velocidade
  • A melhor forma de maximizar as opções da empresa como um todo é construir uma grande empresa
    • Crescimento saudável e sustentável, margem bruta alta e em expansão, amor dos clientes provado por retenção, upgrades e boca a boca, e amor dos funcionários provado por permanência longa e crescimento de carreira
    • Uma grande empresa tem muitas opções: aquisição, continuidade independente, captação, IPO, sucessão e outras

• Portfólio de apostas (Portfolio of bets)

  • Um portfólio reduz a volatilidade, mas também reduz o upside máximo
    • A chance de não haver vitória nenhuma é baixa, então o downside não costuma ser terrível; mas como as vitórias precisam compensar as perdas, mesmo um grande acerto ocasional não será tão grande quanto numa aposta isolada
    • Analogia: comprar Amazon no IPO e manter para sempre teria sido excelente; mas aplicar isso a outros IPOs do mesmo ano poderia ter virado $0. Um portfólio não vai a zero, mas seu crescimento máximo fica muito abaixo do melhor ativo
  • Nota matemática: o motivo de um portfólio funcionar independentemente da distribuição é o Teorema Central do Limite (Central Limit Theorem)
    • Se você extrair repetidamente N amostras de uma população com distribuição estável, porém desconhecida, e fizer um histograma das médias amostrais, essa distribuição converge para uma gaussiana (normal), com média igual à média populacional e variância igual à variância populacional dividida por 1/n
    • O CLT de Lindeberg–Lévy mostra que isso também vale quando cada amostra vem de distribuições diferentes, desde que haja independência, variância finita e nenhuma variável individual domine o conjunto
    • Mas em ambientes de startup essas condições podem falhar, já que algumas distribuições do tipo Power Law têm variância infinita
  • Portfólios funcionam quando você quer resultados previsíveis, porém medianos, e não funcionam quando quer outliers
    • Exemplo de portfólios de venture capital e angel: 65% dão prejuízo, e apenas cerca de 10% geram retorno suficiente para justificar o risco e a falta de liquidez
    • Se o objetivo é buscar outliers, em vez de portfólio é preciso apostar tudo em uma tese, porque a distribuição de retornos de startups segue Power Law e viola os critérios de Lindeberg
  • Conclusão: se a priorização busca diferenciação de mercado e motores de crescimento, portfólio é a ferramenta errada. Ele serve para resultados incrementais pequenos e confiáveis, caso em que não faz sentido discutir confiança

• Apostas assimétricas (Asymmetric bets)

  • O oposto natural do portfólio. Se portfólio serve para confiabilidade, apostas assimétricas servem para outliers
    • Em vez de prever se a aposta vai dar certo, você escolhe apostas cujo downside é limitado e quantificável, enquanto o upside é grande
  • Se o pior cenário é "perder 2 meses" e o melhor é "diferenciação total", a probabilidade quase não importa
    • Basta que o downside seja sobrevivível e que o upside seja grande o bastante para que uma vitória compense dez perdas
    • Talvez não se conheça a probabilidade exata, mas é possível conhecer o formato (shape) de cada aposta
  • Em nível estratégico, apostas assimétricas geralmente já vêm com esse formato mais definido (como novos mercados em que recomendações compostas se acumulam, ou fossos competitivos que se aprofundam a cada venda)
    • No nível de funcionalidade, é preciso construir a assimetria deliberadamente. A forma padrão de um projeto de software é derivar de "2 semanas → 2 meses → já gastamos tanto tempo que agora temos de terminar"
    • O mecanismo é um orçamento definido antes de começar: "2 engenheiros, 3 semanas, depois parar e revisar". Timebox é downside limitado
  • Outra opção é substituir confiança por "quão assimétrica é esta aposta"
    • O RICE pede que você estime probabilidades que já admitiu não conhecer
    • A assimetria pergunta por duas coisas que de fato podem ser estimadas: o pior cenário em tempo e custo e o melhor cenário em valor para o cliente. Ambos são concretos e, se todos os números forem restringidos a potências de 10, é possível convergir para valores sobre os quais a equipe consegue chegar a acordo nas reuniões

Conclusão

• Pare de fingir que dá para quantificar ou definir confiança
• Em vez disso, use técnicas que funcionam sempre que o futuro é imprevisível — porque ele é imprevisível o tempo todo

[hmmhmmhm]

"Em vez disso, use técnicas que funcionem sempre que o futuro for imprevisível, porque o futuro é sempre imprevisível". Excelente.

[spilist2]

É um texto excelente.