A maioria dos produtos SaaS tem um gap entre o signup e o momento em que o usuário realmente entende o produto. No WPFeatureLoop, esse gap era brutal.
Usuários criavam uma conta, olhavam o dashboard, e… nada. O próximo passo era instalar um SDK via Composer. Pra um dev WordPress que só queria ver se a ferramenta valia seu tempo, isso é pedir demais.
Tínhamos 72% de drop-off entre criação de conta e primeira instalação do SDK. A maioria desses usuários nunca voltou.
Então eu corrigi o onboarding. E a solução veio de um lugar inesperado: WordPress Playground.
O Problema do Onboarding “Instale Primeiro”
O WPFeatureLoop é um SaaS de votação de features pra donos de plugins WordPress. Você instala um SDK PHP no seu plugin, e seus usuários ganham um widget embutido onde podem sugerir features, votar e comentar. Você gerencia tudo por um dashboard Kanban.
A proposta de valor é clara quando você vê funcionando. O problema era que os usuários não conseguiam ver funcionando sem antes integrar o SDK — o que significa configurar Composer, adicionar uma dependência, configurar chaves e fazer deploy. São 20 a 40 minutos de trabalho antes de conseguir responder a pergunta “isso vale a pena?”
Esse é o problema clássico de ativação: você está pedindo pro usuário investir antes de ver o retorno.
O número que tornou isso concreto: nossa taxa de ativação — a porcentagem de signups que completavam a integração do SDK e submetiam pelo menos um feature request — estava em 28%. Tudo que vinha depois (retenção, upgrades) ficava prejudicado por esse número.
A Solução: Deixa Ele Experimentar Primeiro
O insight foi simples. Em vez de pedir pro usuário instalar o SDK pra ver o widget, e se eu pudesse mostrar o widget primeiro, com zero setup?
É aí que entra o WordPress Playground.
WordPress Playground é um ambiente WordPress completo que roda inteiramente no browser, via WebAssembly. Sem servidor. Sem instalação. Um site WordPress real rodando localmente numa aba.
E o mais importante: ele suporta Blueprints — um formato de configuração em JSON que permite definir exatamente o que acontece quando o Playground carrega: quais plugins instalar, quais settings configurar, qual página abrir, até com qual usuário logar.
Isso significava que eu podia construir um ambiente Playground que:
- Instala automaticamente um plugin demo com o SDK do WPFeatureLoop já embutido
- Pré-configura com as chaves de API reais do projeto do usuário
- Abre direto na página onde o widget está
- Faz login como admin automaticamente
O usuário clica em “Try it live”, uma nova aba abre, e em segundos ele está olhando pro widget real do WPFeatureLoop, conectado ao projeto real dele.
Como Funciona Tecnicamente
O Blueprint é gerado server-side no momento em que o usuário clica em “Try it live”, com as chaves do projeto injetadas dinamicamente. Aqui vai uma versão simplificada da estrutura:
{
"landingPage": "/sample-page/",
"login": true,
"plugins": ["wpfeatureloop-demo"],
"steps": [
{
"step": "defineWpConfigConsts",
"consts": {
"WPFL_PROJECT_KEY": "chave-real-do-usuario",
"WPFL_API_URL": "https://api.wpfeatureloop.com"
}
}
]
}
A URL do Playground fica:
https://playground.wordpress.net/?blueprint-url=https://app.wpfeatureloop.com/api/blueprint/{project_id}
É isso. O usuário cai num widget funcionando, conectado ao dashboard dele. Ele pode submeter um feature request, votar, e depois voltar pro dashboard do WPFeatureLoop e ver aparecer em tempo real.
Um detalhe importante: o sandbox do Playground é temporário e não persiste dados entre sessões. Mas pra onboarding isso não importa — o objetivo é demonstrar valor, não armazenar dados.
A Mudança na UI
No dashboard, quando o usuário cria um novo projeto, um modal “Get Started” abre com três abas:
- Try it live (padrão, destacada): o fluxo do Playground descrito acima
- Install SDK: as instruções tradicionais de setup via Composer
- See in action: um vídeo demo embutido
Fazer do “Try it live” a aba padrão foi uma escolha deliberada. A maioria dos usuários vai clicar no que já está selecionado. Ao tornar o caminho de zero fricção o padrão, você remove a decisão inteiramente pra maioria dos usuários.
Os Resultados
Depois de lançar isso, a taxa de ativação foi de 28% pra 51% — uma melhoria de 80%.
A métrica que mais me importa é a porcentagem de novos signups que completam uma ação significativa na primeira sessão. Esse número se moveu de forma relevante, e a mudança é quase inteiramente atribuível a usuários que antes teriam abandonado no passo “instale o SDK”.
Algumas coisas que notei:
- Usuários que passaram pelo fluxo do Playground primeiro tinham mais chance de completar a integração do SDK depois. Ver o resultado final primeiro dava uma razão pra fazer o trabalho.
- Chamados de suporte sobre setup do SDK caíram: usuários chegavam no passo de instalação com um modelo mental mais claro do que estavam construindo.
- A aba “Try it live” é clicada em 92% das criações de projeto.
Por Que Mais Produtos SaaS Deveriam Fazer Isso
O padrão aqui não é específico do WordPress. A ideia central é: não faça o usuário imaginar o valor — mostre o valor primeiro.
WordPress Playground tornou isso especialmente fácil pra um produto baseado em WordPress, mas o mesmo princípio se aplica em qualquer lugar onde você consiga criar um ambiente sandbox. A pergunta que vale fazer pra qualquer onboarding de SaaS é: qual é a experiência mínima viável que faz o usuário sentir o produto funcionando?
Pro WPFeatureLoop, a resposta era um widget funcionando numa aba do browser. Tudo antes disso — o signup, a criação do projeto, a configuração de chaves — é setup, não valor. WordPress Playground me permitiu comprimir todo esse setup pra zero na primeira experiência do usuário.
Se você está construindo um produto WordPress e ainda não olhou os Blueprints do Playground, vale uma tarde investida. A documentação é sólida e a API é direta.
WPFeatureLoop é uma plataforma de votação de features pra donos de plugins WordPress. Se você está construindo um plugin e quer saber o que seus usuários realmente querem, experimente.
Deixe um comentário