Podemos construir cada vez melhor e mais rápido — e ainda assim construir a coisa errada.
Há alguns anos escrevi que criar um produto era como montar um quebra-cabeça.
Cada peça representaria uma parte importante: clientes, mercado, tecnologia, stakeholders, recursos disponíveis, modelo de negócio.
Individualmente, cada uma dizia pouco. O valor apareceria quando conseguíssemos encaixá-las de forma coerente e formar uma imagem que fizesse sentido.
Continuo gostando da metáfora. Mas hoje vejo um problema nela. Quando compramos um quebra-cabeça, recebemos uma caixa com a imagem final impressa. Sabemos exatamente o que estamos tentando construir.
Também sabemos que todas aquelas peças pertencem ao mesmo jogo e que, com tempo e alguma persistência, existe uma solução esperando para ser encontrada.
Em produto, quase nunca temos esse privilégio. Não conhecemos inteiramente a imagem final.
Algumas peças que parecem essenciais no início deixam de fazer sentido quando entendemos melhor o problema. Outras ainda não existem. Algumas pertencem a outro puzzle.
E, de tempos em tempos, descobrimos que estávamos tentando montar a imagem errada.
Esse é, para mim, um dos aspectos mais difíceis de construir produtos: o trabalho não é apenas descobrir como encaixar as peças. É decidir quais peças importam, quais hipóteses estamos fazendo sobre elas e, principalmente, qual puzzle merece ser montado.
Construir mais rápido não significa saber melhor o que construir.
Essa discussão ganhou outra dimensão.
Nossa capacidade de construir aumentou exponencialmente. IA potencializou isso de maneira impressionante.
Hoje conseguimos transformar uma ideia em interface, protótipo, código, conteúdo, análise ou até mesmo em um produto funcional em uma fração do tempo que precisaríamos há alguns anos.
Uma hipótese discutida pela manhã pode ganhar uma representação bastante convincente no mesmo dia.
Isso é uma enorme oportunidade.
Mas existe um efeito colateral que prende minha atenção cada vez mais.
Quando construir se torna mais fácil, também se torna mais fácil confundir capacidade de executar bem com capacidade de decidir bem.
Uma solução funcionando rapidamente produz sensação de progresso.
Mas velocidade de construção não reduz, por si só, a incerteza sobre o produto.
Podemos simplesmente chegar mais rápido ao lugar errado.
Quanto maior nossa capacidade de construir, maior deveria ser nossa disciplina para decidir o que merece ser construído.
E essa decisão continua exigindo algo que a tecnologia, sozinha, não resolve: julgamento.
Antes do produto, existem hipóteses
Ideias de produto costumam chegar acompanhadas de frases que soam como fatos.
- “O cliente precisa disso.”
- “O concorrente já oferece.”
- “Essa funcionalidade vai aumentar conversão.”
- “O mercado está indo nessa direção. É uma tendência.”
- “Agora conseguimos fazer isso com IA.”
Qualquer uma dessas afirmações pode estar correta.
Mas também pode ser apenas uma hipótese apresentada com muita convicção.
Para mim, uma parte fundamental do trabalho de produto está justamente em fazer essa separação:
o que sabemos, o que inferimos e o que ainda precisamos aprender antes de aumentar o investimento.
Por isso, discovery nunca me pareceu apenas uma etapa anterior ao desenvolvimento.
Discovery é uma forma de administrar incerteza.
E continua existindo mesmo depois que começamos a construir. Talvez até mais.
Porque cada nova evidência pode mudar nossa compreensão do problema, do cliente, da solução ou da própria oportunidade.
Estratégia não diz onde cada peça entra.
No meu post original, eu dizia que uma boa estratégia deveria orientar desde a seleção das primeiras peças até sua priorização e entrega.
Hoje escreveria de outra forma.
Estratégia, nesse contexto, não serve para dizer onde cada peça entra. Serve para decidir qual imagem não vamos montar.
Essa distinção importa porque estratégia não é apenas organizar prioridades. É fazer escolhas.
- Escolher quais problemas merecem atenção.
- Quais clientes queremos atender.
- Quais capacidades queremos desenvolver.
- Que oportunidades parecem atraentes, mas deliberadamente não perseguiremos.
- Que resultados fariam uma iniciativa continuar recebendo investimento.
- E que evidências deveriam nos fazer mudar de direção.
E todos os porquês que essas escolhas trazem e que precisam ser respondidos. Sem isso, podemos ter um roadmap muito organizado, um backlog priorizado e uma operação extremamente eficiente — e ainda assim estar executando algo que não deveria existir.
Também mudei minha maneira de pensar sobre MVP
No texto original escrevi:
“Uma boa definição de MVP seria montar as bordas.”
Eu gostava dessa imagem.
Montar as bordas ajuda a enxergar os limites do quebra-cabeça, dá uma percepção inicial da imagem e oferece ao time alguma noção de complexidade.
Hoje eu não usaria mais essa definição.
Porque ela ainda pressupõe que conhecemos suficientemente bem a imagem que estamos tentando completar.
Prefiro pensar de outra maneira: eu não defino MVP pelo tamanho da solução. Defino pela incerteza que preciso reduzir.
O mínimo não está necessariamente no produto.
Está no aprendizado necessário para tomar a próxima decisão.
Se a principal dúvida é saber se um problema realmente existe, talvez não precisemos construir nada. Uma pesquisa pode bastar.
Se queremos saber se uma solução é compreensível, um protótipo pode ser suficiente.
Se queremos testar comportamento real, talvez seja necessário colocar algo funcional nas mãos do usuário.
Se o maior risco é tecnológico, o experimento talvez sequer envolva clientes.
O MVP, portanto, não deveria ser simplesmente a menor versão de algo que conseguimos lançar.
Deveria ser o menor investimento capaz de produzir evidência suficiente para melhorar uma decisão relevante.
Às vezes isso será uma borda.
Às vezes serão algumas peças do centro.
E às vezes descobriremos que o melhor próximo passo é parar de montar aquele puzzle.
Talvez seja isso que tenha mudado na minha metáfora
Há alguns anos, eu pensava em construção de produtos principalmente como a capacidade de montar bem o quebra-cabeça.
Hoje acho que o trabalho começa antes.
- É perceber que não recebemos a imagem da caixa.
- É distinguir evidência de convicção.
- É identificar as peças que realmente importam.
- É reconhecer quando uma peça, aparentemente perfeita, pertence a outro jogo. E mudar o jogo se necessário.
- É criar formas menos custosas de testar os encaixes antes de investir (de)mais neles.
E é ter disposição para abandonar uma imagem que deixou de fazer sentido.
E muitas vezes isso exigirá mais disciplina, clareza e coragem do que gostaríamos de admitir.
A tecnologia está tornando cada vez mais barato produzir peças.
IA acelerou esse movimento de forma extraordinária.
Isso não tornou a decisão mais fácil.
Tornou a qualidade da decisão mais importante.