Não é sobre entrega, é sobre resultado

9 min readApr 2, 2021

Notas sobre o livro Inspired, How to Create Tech Products Customers Love

Resolvi fazer esse post para compartilhar algumas notas e pensamentos sobre esse livro que li recentemente.

Antes de falar sobre o assunto principal, preciso fazer algumas introduções. Considero que o contexto em que estamos inseridos e o nosso momento de vida impacta a forma que recebemos e absorvemos diferentes conteúdos. Um filme, série, viagem e nesse caso, um livro, podem trazer diferentes percepções dependendo do tipo de empresa que trabalha, desafios que precisa resolver, o que você estudou, interesses e quais oportunidades teve.

Sendo assim, para que minhas colocações aqui façam mais sentido, vou falar um pouco sobre o meu contexto atual: sou técnico em informática, formado em ciência da computação e tenho MBA em gestão de tecnologia. Iniciei minha carreira em 2004, com 15 anos de idade, passei por áreas administrativas até chegar na área de tecnologia que sempre foi o meu interesse. Em tecnologia, como desenvolvedor back-end, líder técnico e posteriormente gestor de equipes multidisciplinares, tive oportunidade de desenvolver e entregar projetos para grandes marcas como Unilever, Heineken, Bradesco, Itaú, Absolut etc.

Trabalhei um pouco mais de 10 anos no mercado de comunicação digital que tem a característica de prestação de serviços, consultoria e entrega de projetos. Resolvi recentemente trocar o tipo de desafio e, em dezembro de 2020, comecei a liderar equipes dentro de um grande banco que está se transformando para acompanhar o momento em que vivemos.

O banco, assim como eu, está em uma jornada de transformação, seja em relação à cultura, liderança, diversidade, modernização tecnológica e pensamento de produto, ao invés de projetos (vamos falar bastante sobre essa diferença logo mais).

Se você já trabalha em alguma startup ou em uma empresa com forte cultura de produto, talvez os assuntos tratados aqui podem parecer básicos.

Nesse post não farei uma resenha ou detalharei as técnicas que o autor apresenta, já vi alguns posts nesse caminho, focarei em trazer algumas notas que me fizeram refletir bastante.

O livro

Inspired foi lançado em 2008 e teve, em 2018, sua segunda edição com algumas atualizações do autor.

O livro está dividido em 5 partes:
Parte 1 — As lições das maiores empresas de tecnologia
Parte 2 — As pessoas certas
Parte 3 — O produto certo
Parte 4 — O processo certo
Parte 5 — A cultura certa

O livro é fácil de ser encontrado e está disponível também em português e na versão digital para o Kindle.

O autor: Marty Cagan

Passou por empresas como HP, eBay, AOL, Netscape e Fortune 500.
Fundador do Silicon Valley Product Group, atualmente é considerado um guru da gestão de produtos digitais.

Onde acompanhar:
Blog
Linkedin
Livros
Twitter

Ecossistema

Quando falamos sobre produtos digitais normalmente associamos apenas aos aplicativos como Uber, Netflix e Instagram, a realidade é mais ampla que isso com sites, sistemas corporativos, e-commerces, etc.

Recentemente vi uma notícia que 57% dos apps são desinstalados em 30 dias no Brasil, o número é bem alarmante considerando o grande esforço ($) que as marcas aplicam para desenvolver e tentar convencer as pessoas a baixarem e instalarem seus aplicativos.

Quais são as causas que fazem tantas inciativas de produto fracassarem? O livro explica os 10 principais motivos, citarei alguns no post, mas quase todos remetem à cultura de desenvolvimento de produtos em cascata ou o modelo tradicional de lidar com projetos, onde as equipes se tornam apenas tiradores de pedidos.

Netflix, Amazon e Google são exemplos de empresas que aplicam as técnicas e são cases citados no livro Inspired.

Case HP

“não importa o quão boa é a sua equipe de engenharia se não for dado a eles algo que valha a pena desenvolver.”

Marty começa com uma história pessoal, na década de 80 o autor era engenheiro de software na HP, ele e a equipe tinham o grande desafio de disponibilizar inteligência artificial com baixo custo (desafio interessante e, ainda, complexo atualmente, imagina para época). Eles trabalharam muito e pesado por mais de um ano, atenderam aos rígidos padrões de qualidade da empresa, o produto foi internacionalizado e localizado para vários idiomas, a equipe de vendas foi treinada, conseguiram até criar patentes e a imprensa fez ótimas críticas sobre o lançamento. Apenas “um” problema: ninguém comprou o produto.

O produto foi um fracasso, mesmo sendo tecnicamente impressionante, aquilo não era o que as pessoas queriam ou precisavam.

“prometi a mim mesmo que nunca mais trabalharia tão pesado em um produto a não ser que eu soubesse que ele seria algo que os usuários e clientes queriam.”

Agile para entrega

Em empresas onde a fonte de ideias são guiadas por stakeholders, marketing e vendas, as equipes de tecnologia são envolvidas para implementar coletando requisitos, documentando e executando. Em geral, as ideias vêm de cima para baixo.

Não só a engenharia e design, como os principais benefícios do agile também entram em cena muito tarde. Equipes que trabalham deste modo recebem, talvez, somente 20% do potencial e valor dos métodos agile. O que se vê na verdade é agile para entrega, mas o resto da organização e contexto é bastante tradicional.

Me identifiquei bastante com esse cenário, pois sempre tentei aplicar o máximo possível de boas práticas do lean e agile em minhas equipes, isso melhora bastante a parte da entrega com foco em eficiência, prazo e qualidade técnica, mas percebo o quanto isso limita a autonomia do time e desperdiça potencial, tempo e dinheiro.

“Este processo inteiro é muito centrado em projetos. A empresa geralmente financia projetos, seleciona projetos, faz com que projetos sejam aceitos pela organização e finalmente lança projetos. Infelizmente, projetos focam entrega, e produtos têm tudo a ver com resultados.”
“Todo o risco está no fim, o que significa que a validação do cliente acontece muito tarde.”

Riscos

Riscos são abordados com antecedência, em equipes modernas, nós abordamos estes riscos antes de decidir desenvolver qualquer coisa.

O livro cita 4 tipos de riscos que devem ser considerados:

Risco de valor — se os clientes comprarão o produto
Risco de usabilidade — se os usuários conseguem compreender como usá-lo
Risco de viabilidade — se os engenheiros conseguem desenvolver o que precisamos com o tempo, habilidades e tecnologia que temos
Risco de viabilidade do negócio — se esta solução também funciona para os vários aspectos do nosso negócio: vendas, marketing, finanças, jurídico, etc.

Colaboração e resolução de problemas

“Produtos são definidos e projetados colaborativamente, em vez de sequencialmente. Em fortes equipes, produtos, design e engenharia trabalham lado a lado, em um modo recíproco, para encontrar soluções movidas à tecnologia que nossos clientes adoram e que funcionam para o nosso negócio.”

Considerando que já não temos dúvidas sobre as vantagens de trabalhar em equipes multidisciplinares, destaquei as palavras “definidos” e “projetados”, pois entendo ser o maior desafio e necessidade de mudança: que as equipes participem ativamente da definição, prototipação/validação e não apenas da implementação.

“Finalmente, a questão tem a ver com resolução de problemas, não implementação de funcionalidades. Roadmaps de produtos convencionais tratam apenas a entrega de soluções. Fortes equipes sabem que não é só implementar uma solução. Eles devem garantir que a solução resolva o problema subjacente. É tudo uma questão de resultados de negócio.”
“Sempre que você coloca uma lista de ideias em um documento intitulado de roadmap, não importa quantas ressalvas você coloca nele, as pessoas na empresa interpretarão os itens como um compromisso.”

Como o que se espera é garantir resultado e não entrega de features, o que deve ser feito é:

Encorajar o time
Dar contexto do negócio
Alinhar sobre a visão que a empresa deseja alcançar
Priorizar os objetivos de negócios
Definir como o resultado vai ser medido.

Todos precisam saber no que estamos focados agora e o que está planejado para depois. Exemplos:

Melhorar o NPS de X para Y
Aumentar a taxa de retenção de X para Y.

Discovery

“Se a primeira vez que seus desenvolvedores virem uma ideia for no planejamento da sprint, você fracassou.”

Discovery ou descoberta é a etapa onde precisamos descobrir o produto a ser desenvolvido. O propósito é separar rapidamente as boas ideias das ruins e o resultado da descoberta é um backlog do produto validado.

Devemos validar nossas ideias com clientes e usuários reais. Precisamos fazer isso antes de gastarmos tempo e dinheiro para criar um produto. Para rodar um discovery você precisa de experimentos rápidos e, para isso, podemos contar com o apoio de protótipos. A ideia é aprender rápido e de forma barata.

Descobertas e entregas constantes com base em dados e protótipos validados exigem participação ativa dos engenheiros e designers nessas etapas. Isso significa que você tem a engenharia atuando em atividades de discovery, assim como tem gerentes de produtos e designers ajudando no delivery.

“Precisamos garantir a viabilidade antes de decidirmos desenvolver, não depois. Isso não só acaba economizando muito tempo perdido, mas ter a perspectiva do engenheiro com antecedência também tende a melhorar a solução em si, e isso é crítico para o aprendizado compartilhado.”

Pessoas certas

“O trabalho principal da liderança em qualquer organização de tecnologia é recrutar, desenvolver e reter grandes talentos.”

Como você define as funções e seleciona as pessoas para o time é um fator determinante para o sucesso ou falha do produto. O livro foca muito no papel de gerente de produtos, mas considero essencial, para todos os membros da equipe, os conhecimentos necessários que ele estabelece que um gerente de produtos domine:

Clientes, quais são suas questões, dores, desejos, como pensam, como decidem comprar
Dados de vendas e testes, como o cliente usa o produto
Negócio, stakeholders, restrições, como o negócio funciona, qual o papel do produto no negócio
Mercado, setor, concorrentes, tecnologias emergentes, especialistas do setor.

Em um modelo tradicional, o papel de um gerente de produto é de compilar requisitos e documentações para o time, isso é o oposto do que deveria ser a função do gerente de produto.

“A verdade é que o gerente de produto precisa estar entre os maiores talentos na empresa. Se o gerente de produto não tiver o conhecimento de tecnologia, habilidade com negócios, credibilidade com os executivos-chave, profundo conhecimento dos clientes, paixão pelo produto e nem o respeito da sua equipe de produtos, então é uma receita infalível para o fracasso.”

Tanto designers quanto engenheiros costumam entrar no processo muito tarde, essas pessoas são ótimas fontes de inovação e deveriam fazer parte do processo desde o início. Em equipes modernas, em vez de ser avaliado no resultado do seu trabalho, o designer de produto é avaliado no sucesso do produto.

Mercenários X Missionários

“Mercenários constroem tudo o que lhes pedem. Missionários acreditam verdadeiramente na visão e são comprometidos em resolver problemas de seus clientes.” John Doerr (famoso investidor do Vale do Silício e autor do livro Métricas que importam).

Considerando que trabalhamos com profissionais capacitados, ao invés de definir exatamente o que cada um faz, deveríamos contar ao time o que precisamos que realizem e como os resultados serão medidos, dando autonomia ao time para descobrir a melhor forma de resolver os problemas.

“A pergunta não é: Você consegue fazer isso? Em vez disso, peça a eles para analisar e responder a pergunta: Qual é a melhor forma de fazer isso e quanto tempo levaria?”

Ao invés de apenas construir o que outros pedem, o time precisa entender dos objetivos de negócio e ter responsabilidade pelos resultados.

Perguntas importantes:

Estamos endereçando qual objetivo de negócio?
Como saberei que tive sucesso?
Qual problema estamos resolvendo para os nossos usuários?
Que tipo de clientes estamos focando?

Estudo muito sobre agilidade, lean, design thinking e formatos de trabalho como o do Spotify (que nem eles usam). Não acredito em fórmulas mágicas ou receitas prontas para todas as situações, como dizem por aí: não existe bala de prata. Sou a favor de conhecer tudo isso, porém adequar e adaptar cada conhecimento ao seu contexto (de novo essa palavra). Isso também se aplica para esse livro com suas técnicas e exemplos.

Leia o livro

Inspirado, faço como Tim Maia e sugiro que leia o livro, faça suas reflexões e tente aplicar, com coerência, a sua realidade para criar produtos que as pessoas amem.