Já vi três pessoas diferentes lidarem mal com o mesmo ecrã de trinta segundos — o cartão do plano que aparece entre o seu pedido e a construção — e cada uma pagou por isso numa moeda diferente. Uma pagou com uma reconstrução. Outra pagou com tempo perdido a escrever. Outra pagou com um produto que não conseguia fazer aquilo de que realmente precisava. O cartão do plano é o momento mais barato de todo o processo para mudar de ideias, e é precisamente isso que faz com que seja fácil de ignorar.
Erro um: aprovar sem pensar
Este é o mais comum. O esboço parece correto, carregar em aprovar, seguir em frente — fiz isto durante semanas antes de me morder. A construção que finalmente pôs fim a este hábito voltou com um checkout Stripe ligado a um site estático que não tinha onde guardar o estado de conta de que o Stripe precisava. O plano dizia tipo de produto: site estático em texto simples, ali mesmo no cartão, e eu passei-lhe os olhos por cima porque a lista de páginas parecia bem e estava com pressa.
O resultado deste erro tem sempre a mesma forma: tudo o que vem depois do plano está correto dado o plano, portanto a falha não surge como um erro, surge como uma construção funcional mas estruturalmente errada. Ninguém a assinala porque nada está avariado — um site estático com um botão de checkout simplesmente faz a coisa errada em silêncio, ou falha exatamente no momento em que um utilizador real carrega em "pagar". Descobre-se isso na revisão, que é o sítio mais caro para descobrir.
Erro dois: sobre-especificar para evitar uma segunda ronda
O erro oposto parece mais responsável e não é. Algumas pessoas, depois de se queimarem com o erro um, sobrecorrigem escrevendo um parágrafo de requisitos precisos na fase do plano — texto exato, preferências de espaçamento, quais funcionalidades devem e não devem existir, formulado como um documento de especificações. Também já fiz isto, por uma ansiedade vaga de que saltar detalhes agora significa "desperdiçar" uma ronda de construção mais tarde.
É ao contrário, e a razão é esta: o plano vai voltar a ser revisto assim que vir as páginas reais, independentemente de quão cuidadoso tenha sido da primeira vez. E quando for revisto, não recebe um diff do que mudou — recebe um cartão novo que já incorpora a sua edição, ponto final, sem notas de alteração. Portanto a precisão que escreveu na primeira ronda não sobrevive intacta até à segunda de qualquer forma; vai ter de reler tudo outra vez de qualquer maneira. Duas ou três rondas de "não, assim" chegam a um resultado melhor, mais depressa em tempo real, do que um briefing exaustivo — mesmo que escrever o briefing pareça mais eficiente enquanto o está a fazer.
As edições em linguagem simples que realmente funcionam são curtas:
- "Retira o blogue, adiciona uma página de preços" — troca a lista de páginas de forma limpa.
- "Torna-o a dois jogadores em vez de um só" — maior do que parece. Pode afetar o modelo de dados, passando agora a acompanhar dois participantes em vez de um, e o plano revisto vai mostrar esse impacto em vez de o esconder.
- "Isto precisa de contas de utilizador" — se o plano atual é um site estático, esta é a frase que força de imediato a questão do tipo de produto.
Erro três: tratar o tipo de produto como um campo secundário
Este é o erro caro, e é caro porque tudo o resto no cartão é genuinamente recuperável. Páginas, funcionalidades inferidas, a maioria das bifurcações de perguntas — tudo corrigível com uma iteração de versão depois de a construção chegar. O tipo de produto não é. Há quatro categorias:
| Tipo de produto | O que significa |
|---|---|
| Site estático | Simples, sem lógica de servidor. |
| Aplicação instalável | Estilo PWA — funciona offline, pode ser adicionada ao ecrã principal, continua sem lógica de servidor. |
| Compilação de framework | Estilo React/Next, interatividade do lado do cliente mais pesada, ainda sem backend persistente. |
| App com backend em servidor | A única das quatro com uma base de dados e sistema de contas reais por trás. |
Aprovar um plano de site estático, decidir três versões depois que quer login, e isso não é uma atualização de versão — é uma reconstrução a partir de um tipo de produto diferente, e perde a continuidade que o histórico de versões lhe dava para tudo o resto.
As pessoas erram isto de duas formas. Primeiro, não confrontam o seu próprio pedido com o campo — se o seu pedido tem "contas", "login", "guardar", "painel que se atualiza", "pagamentos", ou "vários utilizadores a editar a mesma coisa", e o cartão não diz com suporte de servidor, essa é a edição que vale a pena fazer antes de aprovar, sem exceções. Segundo, confundem aplicação instalável com construção em framework, porque ambas parecem "uma aplicação" em conversa casual. Não são intermutáveis: aplicação instalável adequa-se a uma ferramenta em que todo o estado vive no dispositivo do utilizador — uma calculadora de gorjetas, um cronómetro de treino. Construção em framework significa mais interatividade e estrutura de componentes, mas continua sem nada a persistir do lado do servidor entre sessões ou dispositivos. Nenhuma das duas é "uma aplicação" no sentido de ter contas e dados que o acompanham entre dispositivos — só o suporte de servidor é isso. E sobredimensionar para suporte de servidor "por precaução" num site de portefólio ou numa página de documentação também não é a escolha segura; retroceder mais tarde é tanto uma reconstrução quanto teria sido avançar.
O que resta depois de deixar de fazer estas três coisas
Depois de deixar de passar os olhos pela linha do tipo de produto, de deixar de escrever uma especificação na fase do plano, e de deixar de tratar linguagem sobre contas/dados/pagamentos no seu próprio pedido como negociável, o que resta é uma verificação rápida e específica:
- Ler o tipo de produto.
- Cruzá-lo com o seu pedido.
- Percorrer a lista de funcionalidades inferidas em busca de algo que rejeitaria à primeira vista.
A lista existe precisamente porque um pedido como "ferramenta de agendamento para salões de cabeleireiro" traz consigo coisas que não escreveu — vista de calendário, lembretes por SMS e uma lista de clientes, algumas das quais eram intencionais e outras são expansão de âmbito que o modelo acrescentou porque essas funcionalidades andam estatisticamente juntas. Corte o que não pertence numa frase, aqui, em vez de depois de construído.
Tudo o resto — texto, espaçamento, que tom de cor de destaque, se o botão diz "Começar" ou "Experimentar Grátis" — nem sequer está no cartão, de propósito. São coisas baratas de ver e corrigir numa construção funcional, por isso o cartão não desperdiça a sua atenção nelas, e você também não deveria. Isso são talvez quinze segundos de critério real dentro dos trinta segundos que demora a ler o cartão.
