Como pôr as coisas a ser construídas a sério
Fiz algumas edições a 8 de maio de 2025 para clarificar alguns pontos. Fiquei preocupado por ter desvalorizado o trabalho árduo que dá construir produtos e quis garantir que isso ficava claro. Deixei aqui a minha formulação original, para referência. Não tenho intenção de ofender, mas quero ser honesto sobre os desafios que enfrentamos. Posso tê-lo feito sem querer. Peço desculpa e alterei a formulação para dar mais clareza.
As equipas de produto complicam muitas vezes as coisas.
Escrevem PRDs extensos, fazem pesquisa de utilizadores exaustiva e seguem as metodologias Agile à risca. Mas algures pelo caminho perdem de vista o objetivo real: entregar valor aos utilizadores.
Este excesso de complicação é um sintoma de cuidado. As pessoas querem fazer bom trabalho, por isso empilham processo e documentação. Mas mais camadas não significam mais clareza. Muitas vezes, só deixam tudo mais lento.
As equipas de produto tratam muitas vezes os PRDs como o mapa definitivo da entrega: detalhados, ponderados e assentes em pesquisa com clientes. E com razão.
Mas, do ponto de vista da engenharia, estes documentos podem por vezes parecer otimizados para rastreabilidade e contexto, não para clareza de execução.
Isto não é uma crítica ao rigor ou à abordagem. Se alguma coisa, reflete a complexidade que o desenvolvimento de produto moderno ganhou. Mas quando estou a construir, preciso de uma planta. Uma visão clara e simplificada do que se espera, de como funciona e de como é o sucesso em código.
A isto somam-se as falhas de comunicação. As equipas têm maneiras de trabalhar diferentes. Sem linguagem comum nem alinhamento, essas diferenças criam lacunas. E as lacunas criam atrasos.
Depois há o MVP, mal compreendido e mal usado. Não é lançar uma versão meio cozinhada do produto. É uma aposta de entrega mínima, uma hipótese testável com o suficiente construído para provar ou refutar alguma coisa. Se não colar? Mata-se e segue-se em frente.
“Keep It Simple, Stupid”, o velho princípio KISS, continua a aplicar-se. A simplicidade é subestimada. Sobretudo quando tentas construir algo depressa com uma equipa de gente inteligente que pensa toda de maneira diferente.
Dave Thomas, um dos autores do Manifesto Agile, disse-o bem:
“Agile has become a noun, and that’s the problem. We need to focus on agility.”
O objetivo é a agilidade. Não regras, não rituais, só capacidade de resposta. Queres poder mudar de direção sem atrito.
O caminho é simplicíssimo: menos inchaço, mais clareza.
Começa com plantas de uma página. Só o essencial:
- Percursos do utilizador: quem está a tentar fazer o quê?
- Prioridades MoSCoW: o que tem de ser feito e o que fica de fora?
Trata isto como documentos vivos. Guarda-os no Notion ou onde colaborarem. Quando algo muda, atualiza a planta. Avisa a equipa. Se a mudança for grande, marca tempo para reagrupar.
Essa é a tua fonte de verdade, não uma ferramenta de gestão de projetos, não um quadro do Jira.
Usa o Linear (ou o Jira, se te odeias) para acompanhar o que há para fazer. Não para registar casos-limite nem o histórico de decisões. Se um caso-limite importa, junta-o aos critérios de aceitação ou regista-o na planta. Caso contrário, não encham o quadro.
Na implementação técnica, os engenheiros podem apoiar-se em UML, ERD, diagramas de sequência, tudo o do costume. Esse é o mundo deles. Mas o resto do documento? É uma carta do Produto para a Engenharia. E deve ler-se como uma.
Clara. Focada. Sem enchimento.
E depois de algo estar construído, testar não é só território dos devs. O Produto é dono da hipótese. Falaste com utilizadores. Delimitaste o âmbito. Agora volta atrás e valida. Funcionou? Resolveu mesmo o problema?
Todo este processo, quando está a funcionar, é uma máquina linda. Quando não está, é uma confusão. Mas a solução não é mais processo. É menos. Só a quantidade certa. O suficiente para alinhar as pessoas, não para as paralisar.
Se quiseres aprofundar: