O tamanho do backlog é inversamente proporcional à frequência das conversas com os clientes

• Quanto mais frequentemente você conversa com os clientes, menor fica o backlog
• É importante substituir o tempo de planejamento por conversas com os clientes
• Quanto mais intermediários houver entre desenvolvedores e clientes, maior a chance de o produto não atender às necessidades do cliente
• Um backlog grande significa muitas suposições não validadas e baixa probabilidade de gerar valor para o cliente

Foque no design dos componentes técnicos mais do que no design da UI

• Não gaste tempo demais com o design da UI; é mais importante lançar rapidamente uma interface básica e melhorá-la com base no feedback dos clientes
• É preciso manter a dívida técnica baixa para conseguir realizar rapidamente as mudanças de que os clientes precisam

A forma como as pessoas acham que usam um app é diferente da forma como realmente o usam

• É importante observar os clientes usando o app
• Ao observar diretamente o comportamento dos usuários, é possível obter insights que métricas quantitativas sozinhas não conseguem revelar

Implementação de spoofing de conta

• É importante investir em um recurso de spoofing de conta para entender quais telas um cliente específico está realmente vendo
  • Spoofing de conta (Account Spoofing): recurso que permite ao administrador usar o app como se fosse um determinado usuário de produção
• Isso ajuda a diagnosticar problemas com eficácia e reduz a dependência de dados de teste

A importância da primeira página

• Para clientes que acessam o app pela primeira vez, é preciso apresentar de forma concisa as informações mais relevantes
• Tentar colocar informação demais na primeira página aumenta a carga cognitiva do usuário

O cliente é o marketing mais importante

• O NPS (Net Promoter Score) é um bom indicador de quanto os clientes gostam do produto a ponto de recomendá-lo
• É possível gastar com publicidade, mas começar por clientes satisfeitos é uma estratégia de marketing mais eficaz

Um MVP não tem sentido sem iteração contínua

• O MVP não deve servir apenas como desculpa para oferecer uma experiência de baixa qualidade ao cliente por causa da pressão de prazos
• O MVP ajuda a decidir se são necessárias novas iterações e, se forem, o que precisa ser melhorado

Opinião do GN⁺

• O ponto mais importante deste texto é a importância de desenvolver produtos que reflitam as necessidades reais dos usuários por meio de conversas contínuas com os clientes
• O texto enfatiza a importância de uma UI flexível e de componentes técnicos que permitam incorporar rapidamente o feedback dos clientes
• Mostra que ir além do MVP, melhorando continuamente o produto e aumentando a satisfação dos clientes, pode levar ao sucesso de longo prazo
• O texto compartilha lições aprendidas na vida de startup e oferece insights práticos para fundadores e desenvolvedores

[GN⁺]

Comentários do Hacker News

• Opiniões sobre como organizar funcionalidades/melhorias

  • Pela experiência, a estratégia de transformar toda ideia em ticket é ineficiente. Isso cria uma “geladeira” cheia de ideias que nunca serão usadas.
  • Mesmo quando uma ideia da geladeira é necessária para um negócio importante, muitas vezes ninguém se lembra de que ela existe e acaba criando um novo ticket.
  • Há preferência por tickets com viabilidade de curto ou médio prazo, enquanto as outras ideias são armazenadas separadamente.
  • A equipe de engenharia mantém uma lista de dívidas técnicas que quer resolver, e os PMs mantêm uma lista de possíveis melhorias por projeto.
  • Para novas funcionalidades/produtos, escreve-se um PRD, mas ele não é convertido imediatamente em ticket.
  • Um backlog enorme que provavelmente nunca será tratado é sinal de um PM fraco, com medo de dizer “não”.

• Relação entre o tamanho do backlog e a rotatividade de PMs

  • O tamanho do backlog é inversamente proporcional à rotatividade de PMs.
  • Para PMs antigos, o backlog funciona como um apoio de memória para conversas passadas sobre o produto.
  • PMs novos olham para o backlog, ficam confusos e tentam limpar aquilo que não conseguem entender.

• Opinião contrária à manutenção de backlog orientado por clientes

  • As equipes que mantêm backlog, em sua maioria, o alimentam a partir dos clientes.
  • “Encontre algo que melhore a vida do cliente e transforme isso na próxima funcionalidade” não é algo simples.
  • O que fazer quando há vários clientes, e as funcionalidades que melhorariam a vida de cada um não têm relação entre si e ainda são complexas?
  • É preciso sempre ouvir os pedidos dos clientes, mas quase nunca se deve construir exatamente o que eles pedem.
  • Os clientes pedem funcionalidades que embutem não só uma implementação de UX, mas também o problema e o processo de trabalho atual que estão usando.
  • É preciso identificar o problema de negócio e descartar a ideia de implementação de UX e os detalhes específicos do processo.
  • Deve-se construir, de forma econômica, a funcionalidade mínima que resolva o problema de negócio, com bom design de UX e consistência.

• Necessidade de um lugar para PMs registrarem requisitos de clientes

  • PMs precisam de um lugar para registrar os requisitos dos clientes.
  • Sem uma ferramenta dedicada, esses requisitos acabam, na maioria das vezes, virando tickets no Jira.
  • Existem duas abordagens: ProductBoard e Jira Product Discovery.
  • O ProductBoard segue uma abordagem de CRM, registrando toda interação com clientes e depois decompondo isso em requisitos e desejos.
  • O Jira Product Discovery começa com ideias e exige decompor imediatamente tudo o que se ouviu dos clientes em uma longa lista de requisitos e desejos.
  • A vantagem do Jira Product Discovery é separar a lista de ideias do backlog de desenvolvimento, mas isso cria outra lista longa.
  • Para analisar prioridades de produto com base em conversas com clientes, o ProductBoard é uma ferramenta de descoberta de produto melhor.

• Importância de um backlog refinado por feedback de clientes

  • Como há conversas com clientes quase todos os dias, o backlog contém funcionalidades e melhorias diretamente informadas e refinadas pelo feedback deles.
  • Sempre haverá muita coisa para fazer, mas a diferença está em o backlog ter sido ou não informado e refinado pelo feedback dos clientes.

• Gestão do backlog por meio de conversas diárias com clientes

  • Como alguém de perfil técnico que conversa com clientes todos os dias, a teoria é atraente, mas há alguns problemas.
  • Viés de recência e custo de oportunidade: é preciso continuar coletando feedback sobre espaços de problema nos quais deliberadamente não se está trabalhando por causa de prioridades mais altas.
  • Desenvolvimento reativo: se você pula o registro do feedback, acaba se concentrando no trabalho mais recente e mais acessível, deixando problemas antigos passarem despercebidos.
  • Base de conhecimento da equipe: se houver uma única pessoa responsável por coletar feedback e propor soluções, a argumentação do autor original pode fazer sentido.
  • Se a equipe estiver envolvida, é necessário um banco de dados compartilhado no qual seja possível registrar e buscar pontos de dados de forma assíncrona.
  • O backlog pode crescer rapidamente, mas lidar com sistemas e pessoas complexos traz dificuldades.
  • Para uma equipe bem organizada, uma boa gestão do backlog é necessária, incluindo arquivar trabalhos não relacionados, eliminar duplicações, repriorizar regularmente e tirar o máximo proveito das ferramentas.
  • Gerenciar o backlog é mais importante do que a ferramenta em si, e pode ser necessária uma “fachada” sobre o backlog para expor as informações certas e permitir aprofundamento quando necessário.

• Importância de observar usuários do app

  • É importante observar clientes usando o app.
  • Você pode rastrear todas as métricas, mas ver o usuário rolando a tela para procurar algo, apertando o botão de voltar ou tentando clicar em algo que não é clicável é uma experiência muito concreta.
  • Seria desejável que Apple, Google e todas as outras empresas observassem usuários várias vezes por dia.

• Inutilidade de um backlog grande

  • Um backlog grande contém muitas suposições incertas e tem baixa probabilidade de gerar valor para o cliente.
  • Já se cometeu muitas vezes o erro de presumir que algo teria valor, quando na verdade ninguém se importava.
  • Um backlog grande reflete baixa frequência de conversas com clientes, por isso deve ser visto com muito ceticismo.

• Alerta sobre a implementação de spoofing de conta

  • O spoofing de conta é uma forma fácil de testar problemas em produção, mas as equipes de suporte e desenvolvimento precisam preservar a confiança nos dados de produção.
  • Em alguns setores, isso pode se tornar um grande problema para os clientes.
  • A última startup em que a pessoa trabalhou não permitia que desenvolvedores acessassem dados de produção de forma alguma.
  • Em termos de segurança, isso deve ser considerado um último recurso, e é melhor trabalhar partindo do pressuposto de que não se pode acessar dados de clientes.

• Estrutura em árvore do planejamento de produto

  • O planejamento de produto deve sempre ter uma estrutura em árvore.
  • O nó de nível mais alto são os objetivos de negócio; abaixo deles vem o produto; abaixo disso, os problemas dos clientes; e abaixo disso, os itens do backlog.
  • Ter itens demais no backlog pode significar que uma estrutura adequada não foi definida e que não existe uma lista priorizada de objetivos de negócio.
  • “Conversar com clientes” é útil para entender os problemas deles, mas primeiro é preciso conhecer os objetivos de negócio. Caso contrário, perde-se tempo coletando feedback em áreas nas quais não se vai trabalhar de qualquer forma.