Checklist de Desenvolvimento de Clientes para Minha Startup Digital — Parte 1
Este texto foi originalmente publicado em inglês por Ash Maurya, autor de Runnig Lean, aqui.
No ano passado, Steve Blank lançou um desafio aos membros do Lean Startup Circle para atualizarem seus checklists de desenvolvimento de clientes (customer development) para seus negócios específicos. O checklist dele tem foco em software corporativo, o que não é facilmente adaptado a outros tipos de startups (mesmo startups na web) — especialmente quando se faz Validação de Clientes (Customer Validation).
Após a palestra de Blank, David Binetti, criador do Innovation Options Framework, reuniu um grande grupo de pessoas do Lean Startup Circle para criar um Checklist de Desenvolvimento do Cliente para startups da web. Fiquei honrado em ser convidado. No entanto, depois de algumas trocas tentando definir primeiro o tipo de web startup que atacaríamos primeiro, descobrimos várias diferenças táticas que me levaram à conclusão de que definir esse modelo em grupo é muito difícil de fazer. O resultado seria um modelo altamente generalizado ou nenhum modelo.
Eu, pessoalmente, não me sinto confortável extrapolando um modelo de contas de terceiros do que poderia ter funcionado para outras empresas, especialmente sem experiência em primeira mão na construção de um tipo semelhante de startup.
Então, decidi tentar definir um checkilist de desenvolvimento do cliente para minha startup na web.
Primeiro, um pouco de contexto
Este modelo é baseado em minhas experiências na criação e execução de dois produtos: BoxCloud e CloudFire. Ambos usam um modelo de assinatura. O BoxCloud foi construído usando um modelo de lançamentos antecipados e frequentes e foi lançado inicialmente com um modelo de pagamento Freemium — depois mudamos para o modelo de free-trial. O CloudFire foi criado usando um modelo de startup enxuta / desenvolvimento de clientes e foi lançado apenas com a opção de free-trial.
Para um produto SaaS como o meu, acredito firmemente que você precisa:
a) cobrar pelo seu serviço e
b) validar o preço cobrado mais cedo ou mais tarde
Testes gratuitos, freemium, períodos de adaptação gratuitos etc. são táticas para reduzir o atrito no processo inscrição de pessoas no seu produto e devem ser aplicados (testados em separado) criteriosamente, caso a caso. No entanto, meu principal argumento é que, mesmo se você estiver considerando o Freemium, valide a parte premium do produto antes de dar qualquer experiência grátis.
Abrangerei a descoberta de clientes na parte 1 e a validação de clientes na parte 2 desse artigo. Espero que eu possa escrever as partes 3 e 4 um dia.
Descoberta de clientes: o que devo construir e para quem?
Visão de 3.000 pés
Para uma startup na Web, o objetivo do Customer Discovery (descoberta de clientes) é identificar um problema que vale a pena resolver, definindo o produto mínimo viável “certo” a ser construído e testar o modelo de negócios usando três os loops Build / Measure / Learn (construir / medir / aprender). A maioria das startups da Web conta com um site de produtos para distribuição e blogs, SEO, SEM como canais iniciais de aquisição de clientes — deixando o preço como a maior incógnita do modelo de negócio.
Sidebar: existe pouca ou nenhuma definição de como o termo MVP deve ser usado. Muitos o usam (inclusive eu) para se referir a qualquer coisa (uma landing page, uma apresentação de problemas para clientes, capturas de tela etc.) que permita que você aprenda sobre as pessoas usuárias do seu produto com um mínimo de esforço. Aqui, estou usando a definição mais rigorosa do MVP para significar o conjunto mínimo de recursos necessários para aprender com as earlyvangelists (termo que remete às pessoas usuárias que se comprometem a comprar um produto antes mesmo que haja uma versão completa finalizada e que o divulgam para pessoas próximas). Em outras palavras, a primeira versão do seu produto.
Tudo começa com a declaração de suas suposições
Antes de testar o que se acha que sabe, é preciso passar as ideias para o papel. É normal tentar encurtar esta etapa, mas acho que é um exercício muito interessante.
Teste o problema
No que se refere ao processo de Customer Discovery, não encontrei outra maneira de maximizar o aprendizado validado mais eficaz do que o exercício de “sair do prédio”. Isso vindo de alguém que costumava preferir ficar na própria sala, conversando com clientes por e-mail. Hoje eu tenho o contato de mais de 800 pessoas e horários reservados para fazer entrevistas presenciais com clientes.
No meu último produto, usei uma página inicial / promocional com ações para gerar um buzz pré-lançamento, coletar endereços de e-mail e medir o interesse das pessoas. Embora fosse encorajador ter pessoas usuárias interessadas, elas não me disseram nada sobre o problema que tinham, quem eram, o que eu deveria enviar primeiro ou o que eu deveria cobrar. O que coletar 10 endereços de e-mail por dia me diz? O que significa coletar 20, 40, 100? Por que os 70% dos visitantes abandonaram minha landing page? Foi o produto que causou isso, os textos, os gráficos, outra coisa? O que?
Construir uma boa landing page é difícil. A menos que você tenha um insight excepcional de quem é sua/seu cliente (ou seja seu próprio cliente), iterar o produto sem falar com essas pessoas é um processo lento e doloroso, à medida que se faz testes de uma página contra outra com pouco tráfego inicial. Sim, parece trabalho braçal encontrar pessoas que terão uma conversa com você, mas um papo descontraído de 15 minutos tem mais peso de aprendizado validado do que todos os dados que você pode extrair da análise da web.
Nunca tentei usar pesquisas nas seções de cadastro das minhas landing pages porque eu mesmo odeio preenche-las. Ainda, para construí-las de maneira simples de preencher, é necessário ser muito específico, o que pressupõe que você sabe sabe exatamente o que quer saber — o que raramente é caso.
A beleza do processo de Steve é que ele testa o problema separadamente da solução. Parafraseando Dave McClure:
Os clientes se preocupam com seus problemas, NÃO com a sua solução.
Durante a “Apresentação do problema” para clientes,o ideal é apresentar os três principais problemas, depois calar a boca e ouvir — o que é fundamental para fazer as coisas funcionarem. Dá certo porque você não está solicitando aos clientes que validem ou projetem uma solução que atenda ao argumento “Os(as) clientes não sabem o que querem”. Funciona porque não é um pitch. Na verdade, eu retiro essa constatação. É um pitch. Mas é o cliente que está apresentando os problemas para você. Eu sei que atingi o “nervo problemático” certo com base na paixão do cliente durante essa entrevista.
Eu gosto de estruturar minha “Apresentação de problemas” assim:
1. Enuncie os 3 principais problemas
2. Peça à cliente para priorizar os problemas e colocá-los em ordem, de acordo com a prioridade (da mais alta para a mais baixa)
3. Peça à cliente que descreva como o problema é resolvido hoje
4. Descreva brevemente como você pode resolver o problema
5. Pergunte à cliente se sua abordagem resolveria o problema deles
6. Pergunte se a empresa usaria a sua solução se fosse gratuita
7. Pergunte se eles pagariam $ X / ano?
8. Peça que indiquem sua solução a outros clientes
Crie seu MVP
Diferentemente do software corporativo, que pode ter muitas features, as startups da Web precisam se concentrar no menor número de recursos necessários para aprender com os earlyvangelists ou com o MVP. Após o primeiro check de realidade, você deve terminar com uma lista dos três principais problemas priorizados, o que orienta os recursos necessários para a construção do MVP. Enfatizo a importância de criar o MVP somente até o ponto em que possa ser demonstrado para as pessoas. Será difícil para os clientes visualizarem sua solução sem uma visão assim. Capturas de tela e mockups podem ser usados como substitutos apenas se um demo estiver absolutamente fora de questão.
Teste seu MVP
Com o MVP desenvolvido, teste-o com as primeiras entrevistadas e com mais algumas pessoas.
Eu gosto de estruturar minha “Apresentação do produto” assim:
1. Indique o problema
2. Use a demonstração para contar uma história de como sua solução resolve o problema
3. Teste os preços novamente
4. Peça indicação para outros clientes
5. Termine com uma chamada a ação: inscrição na sua plataforma ou compromisso com a inscrição no futuro.
Dica: eu realizo a apresentação de demos usando um software de captura de tela, o que não apenas me permite fazer edições até que um possível vídeo esteja curto e assertivo, mas também me dá algo que eu posso usar depois no próprio website do produto.
Iterar ou desistir
A última etapa do Customer Discovery é resumir o que foi aprendido e tomar uma decisão para iterar ou desistir.
Qual é o próximo passo?
Na continuação desse artigo, explicarei o fluxo de validação de clientes para uma web startup. Veja aqui.
