Criámos uma regra na WEMASY: nada sai sem sobreviver primeiro a nós
Muito cedo no nosso percurso, criámos uma regra que guia a forma como cada produto WEMASY é construído. Chamamos-lhe a regra "Primeiro sobrevive a nós". É simples. Se uma funcionalidade não apoia sem esforço o nosso próprio trabalho diário, não está pronta para mais ninguém.
Esta regra mantém-nos práticos. Impede-nos de construir para apresentações e obriga-nos a construir para o uso real. Lembra-nos de que um produto não tem sucesso quando é lançado. Tem sucesso quando as pessoas o conseguem usar à vontade todos os dias, sem se sentirem perdidas, confusas ou cansadas.
Porque é que a maioria das estratégias de lançamento falha
Olhámos para lançamentos que correram bem e para lançamentos que se apagaram em silêncio, incluindo algumas versões iniciais do nosso próprio trabalho. A diferença raramente estava na ideia. Estava na forma como o produto aguentava o uso real, confuso e diário. Funcionalidades que pareciam ótimas numa demonstração falhavam em dias cheios. As pequenas fricções somavam-se e as pessoas voltavam aos velhos hábitos.
Eis algumas coisas que observámos:
As equipas preparam os produtos para o dia do lançamento e não para o dia de trabalho. A funcionalidade brilha numa apresentação, mas não indica o passo seguinte quando alguém está com pressa.
As pequenas fricções acumulam-se até o utilizador desistir. Um clique a mais aqui e uma opção escondida ali tornam a ferramenta cansativa aos poucos.
O produto espera que os utilizadores se adaptem a ele. Em vez de se encaixar na forma como as pessoas já trabalham, impõe um caminho novo, com mais passos e mais esforço mental.
O contexto real vive fora da ferramenta. Ficheiros, feedback e decisões ficam em chats e emails, e o produto nunca se torna a única fonte de verdade.
Não fica claro quem é responsável nem qual é o resultado. As pessoas não sabem quem avança a seguir nem o que significa "concluído", por isso as tarefas andam de mão em mão e os prazos derrapam.
Não há uso interno diário antes do lançamento. Sem viver com o produto, as equipas não sentem as dores do dia a dia que só aparecem depois de vários dias de trabalho real.
Também aprendemos com os nossos erros
As melhores lições vêm dos erros. Percebemos que não estávamos imunes a estes erros. Nos primeiros tempos da WEMASY, também criámos funcionalidades que faziam todo o sentido nas reuniões de planeamento. Todos concordavam que a ideia era boa. Mas, quando tentámos usar essas funcionalidades no nosso trabalho diário, sentimos a mesma fricção que víamos noutros produtos.
O que parecia simples no ecrã tornava-se lento quando estávamos mesmo a tentar terminar uma tarefa.
Um fluxo que parecia claro na discussão tornava-se confuso quando o experimentávamos sem contexto.
Passos que achávamos "nada de especial" tornavam-se cansativos quando repetidos várias vezes por dia.
Demos por nós a usar soluções alternativas fora da ferramenta, um sinal claro de que a funcionalidade não apoiava o trabalho real.
Este foi o nosso ponto de viragem. Percebemos que, se nós não conseguíamos usar uma funcionalidade sem esforço, sabendo como tinha sido construída, os utilizadores comuns teriam ainda mais dificuldade. Nenhum plano de marketing para o lançamento de um produto resolve um produto que não funciona no dia a dia. Foi aí que decidimos mudar a forma como construímos e lançamos os nossos produtos e criar uma regra interna para isso.
Os nossos passos para lançar um produto na WEMASY
Com o que aprendemos, o nosso processo de lançamento ficou simples. Se queremos que os utilizadores sintam que os produtos WEMASY trabalham para eles, então a WEMASY tem primeiro de trabalhar para nós sem esforço. Isso levou-nos de uma construção baseada em suposições para uma construção baseada na experiência. Hoje, cada produto passa por três fases antes de chegar até ti.
Os três passos importantes:
Passo 1. Construímos uma versão funcional e somos os primeiros a usá-la
Assim que uma funcionalidade funciona, passamos o nosso trabalho diário para ela. É aqui que a verdade aparece. Vemos logo o que interrompe o fluxo, o que pesa e o que tem de ser mais natural. Se algo nos atrasa, corrigimos. Se temos de pensar demasiado ou achamos difícil de usar, simplificamos. Afinamos até deixarmos de reparar na ferramenta e só repararmos no trabalho a ser feito.
Passo 2. Partilhamos com um pequeno grupo de utilizadores atuais da WEMASY
Quando já a usamos à vontade, abrimos a funcionalidade a um pequeno grupo de utilizadores atuais que gostam de dar feedback honesto. Eles mostram-nos como a funcionalidade se comporta com outras formas de trabalhar, outros setores e equipas de outros tamanhos. O feedback deles ajuda-nos a limar arestas que nos tenham escapado, porque a nossa forma de usar um produto não é a única.
Passo 3. Só lançamos para todos quando os dois lados a usam sem problemas
Só quando a funcionalidade funciona bem para nós e para este primeiro grupo é que a disponibilizamos a todos. Quando chega a todos os utilizadores, já está estável, clara e pronta a usar, sem chamadas de formação nem onboarding complicado.
Construímos a WEMASY assim porque sentimos na pele as ferramentas que parecem boas mas não ajudam num dia cheio. Usar primeiro os nossos próprios produtos mantém-nos credíveis, fiáveis e honestos. Se achas que a nossa estratégia de lançamento te pode ajudar, experimenta e conta-nos como correu com a tua marca. Para saberes mais sobre como estar online, lê o nosso artigo sobre como começar o teu website. Também podes ver a nossa checklist de lançamento de um website. Para teres a visão completa, lê o nosso guia principal sobre o que é um website e porque precisas de um.
Perguntas frequentes
O que torna boa uma estratégia de lançamento de produto?
Na WEMASY, aprendemos que a melhor estratégia de lançamento é aquela em que a equipa usa o produto todos os dias antes de mais alguém o ver. Quando sentes a fricção na pele, resolves os problemas reais e não os que imaginaste no planeamento. O feedback inicial de 10 a 30 utilizadores reais traz a perspetiva de fora que a tua equipa não consegue ter. Quando lanças para o público, o produto já funciona em condições reais e imperfeitas.
Quanto tempo devem durar os testes internos antes de um lançamento?
Pelo menos duas a quatro semanas de uso diário a sério. Um teste rápido num fim de semana não apanha a fricção que só aparece com o uso repetido. O objetivo é encontrar os pequenos problemas que se acumulam ao longo dos dias, como cliques a mais, fluxos confusos ou falta de contexto. São coisas que os utilizadores sentem logo, mas que as equipas muitas vezes não veem.
Devo fazer um plano de marketing para o lançamento antes de o produto estar pronto?
Começa a planear cedo, mas não fecha a mensagem até o produto estar testado. O teu plano de marketing para o lançamento deve basear-se em feedback real dos utilizadores, não em suposições. Se os testes mostrarem que os utilizadores valorizam outro benefício que não esperavas, o teu ângulo de marketing tem de mudar. Prepara o plano em paralelo, mas mantém-te flexível.
Qual é o maior erro que as equipas cometem num lançamento?
Preparar o produto para o dia do lançamento em vez de o preparar para o dia de trabalho. Muitas equipas correm para cumprir um prazo e saltam os testes reais. O produto fica ótimo numa apresentação, mas frustra os utilizadores ao terceiro dia. Gastar mais uma semana a testar bem poupa meses de correções e críticas depois do lançamento.
Com quantos utilizadores devo testar antes de lançar para o público?
Começa com 10 a 30 utilizadores que representem o teu público real. Devem ser pessoas que vão usar o produto com regularidade, não apenas amigos que clicam uma vez por curiosidade. O feedback deles vale mais do que centenas de respostas a inquéritos, porque sentem a fricção real que um teste casual não apanha.
Como é que a WEMASY testa os seus próprios produtos antes do lançamento?
Cada funcionalidade da WEMASY passa por três fases: uso diário interno pela equipa, testes com um pequeno grupo de utilizadores atuais e só depois o lançamento público. Se uma funcionalidade não funciona sem problemas para a equipa e para os primeiros utilizadores, não é lançada. Este processo garante que cada ferramenta está estável, clara e pronta para trabalho real desde o primeiro dia.
