- Muitas empresas acabam lentas no desenvolvimento por estarem presas a processos complexos ou requisitos prolixos, mas o que realmente importa é criar rapidamente o ‘produto certo’
- Quando se removem elementos desnecessários do processo de desenvolvimento de produto, a velocidade de desenvolvimento aumenta muito. Criar o produto certo é, em essência, um processo rápido
- O que desacelera a velocidade da equipe de produto são elementos desnecessários como processos, a distância entre quem decide e quem executa, e especificações excessivas
[Princípios para Product Velocity]
1. É preciso ‘fazer menos’
- Em geral, existe um trade-off entre velocidade e qualidade
- A maioria das empresas define requisitos e prazos e trata a qualidade como resultado, mas nós fazemos o contrário: definimos um padrão de qualidade e pensamos no que pode ser lançado em 60 dias
- O importante não é tentar cumprir todos os requisitos, e sim concluir rapidamente apenas o que é importante
- Ao remover requisitos e fazer só o necessário, é possível aumentar tanto a velocidade quanto a qualidade
- Elon Musk também propõe uma abordagem parecida, dizendo: “primeiro, torne os requisitos menos idiotas”
2. O ‘modo idiota’ costuma ser eficaz
- Usando o ‘midwit meme’ como exemplo, pessoas muito inteligentes e pessoas idiotas concordam com soluções simples, enquanto a pessoa mediana cria problemas desnecessariamente complexos.
- Nós frequentemente abordamos problemas no ‘modo idiota’, tentando encontrar soluções simples em vez de pensar demais e complicar tudo.
- Quando erramos, em geral foi porque pensamos demais; métodos simples funcionam com mais frequência
- Perguntar a si mesmo “o que eu faria se fosse idiota?” muitas vezes leva a uma solução executável
3. Nem todo problema é importante
- Apenas alguns poucos problemas são realmente muito importantes. Questões críticas como segurança precisam ser resolvidas, mas não é necessário resolver todos os problemas.
- Por exemplo, a UI mobile não é boa, mas como os clientes quase não usam mobile, não estamos melhorando isso.
- Assim, problemas com os quais os clientes não se importam muito podem ser ignorados.
4. Simplesmente construa
- Não temos processo para desenvolvimento de produto. Não fazemos mockups no Figma, PRD, design system, Agile, OKR, roadmap de produto bem definido, testes A/B, growth hacking etc.
- Como nossos clientes são engenheiros, esperamos que nossos engenheiros consigam lidar com produto, design e tudo mais
- Preferimos criar o produto rapidamente e observar a reação dos clientes
5. Reescritas são feitas quando necessário
- As empresas muitas vezes pensam que conseguem se mover mais rápido adiando dívida técnica pelo maior tempo possível, mas nós não temos problema em fazer grandes reescritas quando necessário
- Às vezes, o caminho mais rápido para construir a coisa certa é construir a coisa errada, perceber que ela está errada e substituí-la pela coisa certa
- Se parecer útil eliminar dívida técnica, faremos isso
6. Terceirize quando possível
- Sempre que possível, compramos soluções de fornecedores externos em vez de construir internamente. Por exemplo, geramos SDKs por meio de uma empresa chamada Fern
- Claro, usar fornecedores envolve um custo inicial considerável e limita a liberdade, mas em geral é a escolha certa
- Nossos recursos de engenharia são muito limitados e caros; uma semana de tempo de um engenheiro custa cerca de 5 mil dólares. Considerando o custo de oportunidade, esse valor é muito maior
- Há relativamente poucas coisas que realmente valem a pena construir
7. Não contratar
- Não esperamos que aumentar o número de pessoas aumente a produção da equipe. Contratar é lento e difícil, e onboarding e gestão de pessoas consomem tempo
- Especialmente porque é difícil trazer pessoas capazes que consigam contribuir sem muita ajuda
- Por isso, mesmo tendo recursos para montar uma grande equipe de engenharia, fazemos o máximo para permanecer pequenos. Isso torna a vida muito mais fácil
Considerações finais
- Percebemos, em um grau que antes não entendíamos, que o desenvolvimento de produto não deveria levar tanto tempo assim
- Se você sabe o que os clientes precisam, tem uma equipe forte e elimina distrações e elementos desnecessários, é possível desenvolver produtos em alta velocidade
10 comentários
Eu também voltei para ver de novo. Até a próxima.
É bom mesmo vendo de novo e de novo.
?? É bem idealista, né
Os custos de gestão de terceirização e os recursos que precisam ser investidos nisso provavelmente não são nada triviais... Ainda assim, no geral, é um conselho excelente.
Sempre dizem para usar terceirização. Mas quase nunca vejo explicarem como fazer isso ao usar terceirização.
Quando você entrega apenas um esboço simples, sem uma visão clara do serviço, acaba não percebendo que pode receber algo pior do que imagina....
???: Por favor, façam rápido, mas sem ser ágil
Acho que isso é possível quando o produto está claro
Quando fica claro o que precisa ser feito, dá uma sensação de que qualquer design além disso é desnecessário
"Primeiro, torne os requisitos menos estúpidos"
Se a empresa terceirizada sumir um dia... e não atender o telefone ;_;
Mesmo sendo desenvolvimento interno, se um dia todo mundo pedir demissão de uma vez, a situação não fica parecida..?