Seguindo com a série de posts da SLLConf, além do excelente case da Aardvark e da entrevista com o Randy Komisar (farei o review do seu livro aqui no blog), o bloco Measure da conferência também contou com a apresentação dos cases da Flowtown e KISSMetrics (esse último virá no próximo post).

Ambos foram ótimos exemplos da utilização de Pivôs – mudanças significativas no modelo de negócio – a partir de aprendizados validados com os clientes. Especialmente no caso da Flowtown, também foi possível perceber o quanto é poderoso o conceito do Minimum Viable Product (MVP). Seguem abaixo os videos, os slides e algumas observações sobre o case deles.

Flowtown

A Flowtown é uma Startup que nasceu com o objetivo maior de ajudar as PMEs a fazer Marketing na Internet. O primeiro produto escolhido para isso foi um Criador de Landing Pages, o qual eles passaram três meses construindo. Algumas semanas após o “lançamento”, tudo que eles conseguiram foi apenas um usuário pago e mais alguns na versão free, e claramente o produto não estava pegando tração. Depois de várias conversas e investigações com os usuários, eles decidiram descontinuar o produto e fazer o Pivô.

A segunda ideia era um produto que o cliente poderia inserir o email de alguém e coletar uma série de informações demográficas sobre aquela pessoa provenientes das redes sociais. Só que desta vez, ao invés de simplesmente construir o produto, eles passaram algumas semanas apenas fazendo testes de demanda com usuários, lançando mão de iterações com Smoke Tests e protótipos (mock-ups) de alta fidelidade. Somente quando eles já tinham 20 clientes que efetivamente quiseram pagar pelo produto que eles começaram a codificá-lo.

A figura abaixo mostra a evolução da receita da empresa a partir desse pivô.

Receita da Flowtown antes e depois do pivô

Eles finalizaram a apresentação com algumas dicas gerais aprendidas com o processo:

- Tenha uma “Bullshit Bar” para cada iteração maior: um objetivo (métrica) claro definido para cada hipótese que está sob prova. Não continue avançando na mesma direção se esse objetivo não for atingido;
- Use e abuse dos protótipos. Coloque-os na mão dos usuário rapida e frequentemente;
- Faça quantos pivôs precisar, mas valide alguma coisa antes de mudar de direção. Não adianta ficar pulando de um lado para o outro sem evidências e aprendizado;
- Desde o dia zero, seu mindset deve ser: “fracassos vão acontecer”. Não se preocupe muito com os usuários atuais se tiver que fazer o pivô, a não ser que tenha efetivamente cobrado algo deles.
(obs. Essa é mais uma evidência de que não se deve antecipar a hora de cobrar pelo uso do produto. Comentei sobre esse timing no segundo post da série Freemium).

Por fim, eles deixaram um comentário sobre o quão brilhante foi o processo “Mágico de Oz” usado pela Aardvark para buscar validar o problema antes de implementar a solução.

Uma das palestras mais interessantes da SLLConf foi o estudo de caso da Aardvark, empresa de “Busca Social” que foi comprada pelo Google no início do ano. A Aardvark é um dos exemplos recentes de Startups bem sucedidas que aplicaram conscientemente os conceitos de Customer Development e Lean Startup.

A apresentação foi dividida em quatro partes: uma explicação conceitual do produto, os princípios adotados pela empresa desde o início, a história do produto e por fim o processo de desenvolvimento.

O Slide abaixo resume o conceito por trás do produto, que foi explicada em bem mais detalhes pelos fundadores.

Desde o início, os fundadores sabiam do Espaço em que queriam atuar (Social Search), mas não tinham uma ideia exata de qual seria a forma que o produto assumiria. Além disso, eles sabiam que as Startups não são “sucessos do dia para a noite”, e que a probabilidade de fracasso é muito grande. Parafraseando Mike Cassidy, “em uma Startup, a chance de qualquer coisa boa acontecer é sempre menor que 50%”.

Eles então definiram uma série de hipóteses e iniciaram a experimentação seguindo os princípios abaixo.

Princípios

- Minimizar risco (da catástrofe final: acabar o dinheiro)

- Maximizar os testes

- Ser paciente

A ideia central é mover através de blocos muitos pequenos, já que é impossível pular do zero para a perfeição. Sabendo que a maioria das experiências não vão dar certo mesmo, é importante olhar a “falha” como algo central para o aprendizado, tornando-a menos dolorosa para todos.

Histórico e lições aprendidas em cada etapa

Concepção

Duração: Meio ano
Feitos: Escolheram um problema, fizeram protótipos em série, abandonaram cinco ideias.
Aprendizados e dicas:
- Concentre seus esforços em um campo de atuação específico. Os pivôs devem ser extensões do aprendizado com a ideia anterior.
- Fique longe de ideias de produtos que tenham um componente visual muito forte e/ou baixa “latência” (demora muito para aprender algo). Escolha coisas em que se pode fazer protótipos e iterar com usuários de maneira muito rápida.

Implementação

Duração: Um ano
Feitos: Levantaram capital semente, implementaram o teste “Mágico de Oz”, recrutaram pessoas-chave (sobre esse teste, vale a pena ler este artigo)
Insight: “As pessoas estão usando e gostando dessa ideia do Aardvark (a sexta ideia implementada), mesmo nesse formato super rústico. Agora vale a pena continuar investindo no desenvolvimento, já que provavelmente eles gostarão ainda mais. Apesar da coisa toda ainda ser uma ilusão, pelo menos parece promissor agora”.
Aprendizados e dicas:
- Bons investidores estão muito mais interessados em apostar em algo que já mostrou que tem demanda mas que precisa ser melhor desenvolvido, do que investir em um produto “pronto” (tecnologicamente) mas que ainda precisa ser submetido ao teste do mercado.

Refinamento

Duração: Um ano
Feitos: Levantaram investimento Series A, estenderam o refinamento do produto, triplicaram o tamanho da equipe
Aprendizados e dicas:
- Testes qualitativos são essenciais para o refinamento do produto. (eles traziam semanalmente cerca de 20 pessoas para acompanhar os testes com protótipos de novas features)
- O objetivo é chegar ao Product/Market Fit ao longo do tempo. A preocupação maior não é “criar o produto certo desde o começo”, mas sim ficar melhor e melhor no processo de aprendizado com os usuários.
- Se você não tem um grande obstáculo interno (como um conflito com outro sócio, por exemplo), enquanto não acabar o dinheiro e você continuar melhorando a sua taxa de aprendizado, a tendência ao longo do tempo é você deixar os concorrentes para trás.
- Pense no desenvolvimento técnico do produto (engenharia) como um Hockey Stick. A evolução do produto (código) pode ser lenta por um bom tempo, e depois acelerada quando se conhece de fato o problema que se quer resolver.

Processo

Na Aardvark, o processo de design e desenvolvimento é a coisa mais importante para a empresa. Todos têm a responsabilidade de parar regularmente e discutir o resultado dos experimentos e aprender coletivamente. Para cada iteração, eles procuram identificar quais são as hipóteses-chave ou os problemas que estão incomodando mais e projetam uma solução para testar aquilo, buscando validar o design com usuários antes de investir recursos de engenharia na funcionalidade. O gráfico abaixo ilustra o ciclo de desenvolvimento de cada lote.

Outras dicas gerais sobre o Processo da Aardvark:

- Faça a melhoria contínua do processo um dos objetivos da empresa;
- Faça experimentos no processo tanto quanto no produto;
- Contrate e doutrine as pessoas para apoiar o processo de desenvolvimento;
- Para cada novo problema, antes de tentar resolvê-lo defina a métrica para qual o sucesso será mensurado;
- Explore o aprendizado coletivo, tanto por parte dos funcionários quanto dos usuários do produto;
- Defina períodos de tempo regulares nos quais todos vão sentar e discutir sobre os aprendizados. Estimule o “confronto” sob pontos de vista diferentes;
- Seja transparente com todos stakeholders (investidores, funcionários, usuários, etc.).

Por fim, segue abaixo o video e os slides da palestra:

Na parte I desta série, argumentei que o núcleo de um modelo Freemium de sucesso é a parte Premium, enquanto a parte Free é essencialmente estratégia de marketing. Como o processo de Customer Development se propõe a validar se o produto envisionado pelo empreendedor tem de fato demanda no mercado, essa validação – e consequentemente, a construção do Minimum Viable Product (MVP) – deve começar necessariamente pela parte Premium do produto.

Há exceções para esta regra (como debati com o Millor do Empreendemia nos comentários do post anterior), que em geral são aplicadas ao caso de Startups com produtos baseados em network-effect, onde o valor para cada usuário cresce na medida que mais usuários usam o sistema (ex. Twitter, eBay, Facebook, etc.). Ou então para os casos de monetização indireta, onde os usuários não pagam para usar o produto (ex. receitas baseadas em publicidade, programa de afiliados, etc.). Nesse caso, o maior desafio inicialmente é “ganhar tração” e conseguir um grande número de usuários o quanto antes. Para estes tipos de produtos, o MVP deve caminhar mais na direção de um Minimum Desirable Product.

(Obs. Ainda assim, mesmos nestes casos já é possível testar e monitorar algumas métricas de monetização, tais como receitas/usuário.)

Se a parte Premium deve ser validada em primeiro lugar, e cobrar ($$) pelo produto faz parte dessa validação, quando é a hora certa para colocar um preço no produto?

Quando a Startup deve começar a cobrar pelo produto?

Essa é uma discussão polêmica e sem um claro consenso. Depende bastante do contexto onde a Startup está inserida, qual é o tipo de produto, e ultimamente, qual é o principal componente de risco das premissas do negócio (o que Brant Cooper chamou de Business Driving Force).

Em uma discussão recente no Lean Startup Circle sobre esse tema, o debate gravitou para as vantagens de se cobrar pelo produto desde o início. As passagens abaixo ilustram alguns dos bons argumentos para tal:

“Even if I was trying to build a freemium service, I would try to get early customers to pay. What I noticed was that insisting to myself that my MVP was good enough to sell focused my mind enormously. I can think of thousands of programs I’d like to write. I can think of tens of ideas I’d like to make into businesses. Trying to make this one right here that I’m working on right now good enough to buy helps me quiet the clutter, if that makes sense. I think that overall a paid MVP will result in less waste, better feedback, and long-term better results.” Kent Back

“I feel starting with free and figuring out premium later (all too common) is backwards. Focussing on the premium part of freemium first (yes, it’s harder) lets you learn about your unique value proposition – the stuff people will pay for. You can then more intelligently offer a free plan without giving the farm away.“  Ash Maurya

Certamente a maior validação do negócio que se pode ter é conseguir clientes que de fato paguem pelo produto. Desta forma, faria sentido cobrar do cliente desde o início e ir iterando até chegar a um conjunto (features, preço, canais de aquisição de clientes, etc.) que gere um modelo de vendas replicável e escalável.

No entanto, a grande maioria das Startups morre antes de achar o Product/Market Fit, e cobrar pelo produto antes desse “sinal” dificulta a descoberta do que o cliente vê valor e de como entregar esse valor para ele.

Algumas razões para não cobrar pelo produto desde o início:

- É mais difícil atrair massa crítica para experimentação e aprendizado: Um produto pago tende a assustar muitos potenciais clientes/usuários na sua primeira exposição. Não só eles têm que decidir se aquele problema é relevante para se investir tempo e atenção, como também têm que avaliar e tomar uma decisão econômica imediata se aquele produto vale o investimento financeiro;

- O MVP tende a não ficar tão Minimum assim: Psicologicamente, é difícil para o empreendedor lançar um produto “mínimo” e ainda cobrar por ele.  Especialmente aqui no Brasil, a quantidade de “críticos de plantão” é muito grande e é natural que haja medo do feedback negativo. Adiar a cobrança pelo produto é uma forma de aliviar essa pressão sobre o MVP, e consequentemente, antecipar o aprendizado;

- É mais difícil fazer o pivô: Como resultado do aprendizado adquirido com o mercado, faz parte da história da maioria das Startups de sucesso a mudança de estratégia de negócio, processo batizado como pivô.  Ao cobrar dos usuários desde o início, o grau de amarração que a Startup tem com o produto inicial é muito maior (pela necessidade de manutenção, suporte, etc.), diminuindo a flexibilidade para se fazer eventuais mudanças mais bruscas no produto;

- Fica mais fácil implementar os pacotes de planos e preços adequados: Para que se tenha um modelo Freemium equilibrado, é importante colocar na parte Premium (paga) componentes que os clientes de fato valorizem. Essa descoberta do valor percebido pelos usuários só é validada após muitas iterações e aprendizado. (exemplo de como encontrar o valor do produto aqui)

- Implementar o billing pode ser uma grande distração: No estágio inicial, idealmente o foco deve estar no aprendizado. Claro que ter vendas é um ótimo problema para se resolver, mas lidar com as questões relacionadas – sistema de pagamentos, contratos/termos de uso, cobrança, notas fiscais, impostos, etc. – tende a desviar esse foco e diminuir a velocidade de experimentação.

Pela sua larga experiência em uma série de Startups, Sean Ellis também defende que não se deva cobrar pelo produto até que seja atingido o Product/Market Fit. O trecho abaixo extraído de uma das discussões recentes sobre o assunto resume a sua opinião:

“The safest assumption for all startups is that you won’t have product/market fit when you first introduce the product. I think that it is easier to evolve toward product/market fit without a business model in place (users are free to try everything without worrying about price). As soon as you have enough users saying they would be very disappointed without your product, then it is critical to quickly implement a business model. And it will be much easier to map the business model to user perceived value.”

A pirâmide da Startup do Sean Ellis - implementar o modelo de negócio e colocar preço no produto é parte da fase "Transition to Growth"

Apesar dessa recomendação geral de não se cobrar pelo produto desde o início, duas observações importantes devem ser consideradas:

- Isso não significa que uma ideia de preço não possa ser validada na fase inicial. Para isso, vale tentar extrair essas percepções de custo/benefício através de entrevistas qualitativas com os clientes e através de experimentos quantitativos (ex. testes com Landing Pages).

- É importante comunicar para os usuários que o produto está gratuito, mas que será pago futuramente (veja o exemplo do CoTweet abaixo). Uma boa dica para minimizar o impacto disso é prometer um desconto futuro para atrair beta testers e estimulá-los a dar feedback sobre o produto.

No próximo post da série, passarei algumas dicas compartilhadas por várias pessoas que já acertaram e erraram bastante em implementar e calibrar o modelo Freemium de seus produtos.

Como já discutido em posts anteriores, o processo de Customer Development serve para guiar a Startup na tarefa de “encontrar o seu negócio”, através de iterações ágeis e uma estrutura de custos enxuta. Até encontrar o Product/Market Fit, a Startup opera no modo “Aprendizado” ao invés de focar na execução e crescimento.

Esse aprendizado provém das experimentações dos clientes com o MVP e das diversas formas de feedback que podem ser coletadas (entrevistas, testes de usabilidade, métricas diversas, etc.). Para facilitar e “padronizar” parte desse processo, Sean Ellis e o pessoal do KISSmetrics desenvolveram uma ferramenta que permite mensurar o Product/Market Fit e extrair informações importantes sobre a percepção dos usuários com relação ao produto.

Em síntese, essa ferramenta – batizada de Survey.io – é uma rápida pesquisa para ser aplicada a diferentes grupos de usuários de tempos em tempos. Mais importante do que a ferramenta em si, as perguntas da pesquisa foram elaboradas de forma a extrair pontos fundamentais para análise de engajamento do usuário, benefício percebido e posicionamento do produto.

Para exemplificar sua aplicação, montei uma pesquisa de avaliação do “produto” blog Manual da Startup. Peço que façam a avaliação não só para me fornecer feedback, mas principalmente para experimentar o questionário, já que a sua adaptação para qualquer outro produto é muito simples.
Obs1: leva apenas 3 minutos! ;)
Obs2: é importante responder a pesquisa antes de ler o resto do post.

Clique aqui para responder a pesquisa

Utilizei o SurveyMonkey para montar a pesquisa, já que o Survey.io ainda não permite a customização de perguntas (nesse caso, precisei apenas traduzi-las). Para adaptá-la, basta “copiar” a pesquisa e trocar o nome do produto nas perguntas.

Como aplicar a pesquisa

Sugere-se que a pesquisa seja aplicada apenas com usuários recorrentes do produto (utilizaram mais de uma vez dentro de um mês, por exemplo), e que seja aplicada em lotes superiores a 50 pessoas para começar a ter uma relevância estatística (veja aqui dicas de como trazer usuários para o produto). Caso não seja possível ter esse leque em mãos, um grupo menor poderá ainda assim oferecer informações qualitativas relevantes.

Apesar de ser fácil “espalhar” de uma só vez o convite aos usuários para responder a pesquisa, elaborar os convites individualmente traz um índice de respostas muito maior do que um email genérico para todo mundo. Em troca de uma maior participação, vale oferecer aos usuários um incentivo, tais como um trial gratuito, descontos mais longos no preço do produto e até brindes diversos. Lembrando que antes do Product/Market Fit, o ROI de qualquer ação que envolva tempo ou dinheiro deve ser mensurado por Aprendizado Validado sobre os Clientes.

O blog Venture Hacks fez uma entrevista com o Hiten Shah do KISSmetrics para esclarecer melhor os porquês de cada pergunta da pesquisa e como elas ajudam a extrair as informações relevantes para análise. Separei os principais trechos abaixo junto com algumas observações pessoais:

- Pergunta 1: Como você descobriu o produto?
Serve para descobrir qual foi a origem daquele usuário. Pode complementar as ferramentas de analytics se combinado com filtros de grupos de usuários de acordo com os resultados da pesquisa. (ex. fulanos que estão vindo da fonte X tendem a perceber o produto como Y)

- Pergunta 2: Como você se sentiria se o produto não existisse mais?
Essa é a pergunta-chave de toda a pesquisa. Serve para medir quantitativamente o percentual de usuários que ficaria muito desapontado se o seu produto não existisse. Como já escrevi anteriomente, Sean Ellis acredita que o produto encontrou Product/Market Fit quando esse índice é maior do que 40% (para produtos B2B, geralmente é melhor exigir um nível mais alto neste percentual). Essa resposta também é um dos elementos que melhor auxilia na aplicação de filtros sobre os resultados da pesquisa, já que é possível separar por grupos de usuários que acreditam que o produto é um “must-have”, “nice-to-have” ou “not important”. Algumas implicações disso serão vistas a seguir.

- Pergunta 3: O que você usaria como alternativa se o produto não existisse mais?
Permite avaliar em qual “ambiente” os usuários acreditam que o produto se encaixa, e quais outros produtos (ou outras formas de resolver o mesmo problema) são percebidos como concorrentes. Essa resposta é uma das mais importantes para ajudar a estabelecer o preço do produto, já que mesmo que não haja concorrente direto, pode-se levantar o custo da “forma atual” de se resolver o problema.

- Pergunta 4: Qual é o principal benefício que você tem recebido do produto?
Outra questão fundamental, pois auxilia a entender qual é de fato o problema do cliente que está sendo resolvido. Essa resposta é ainda mais útil se acompanhada do filtro dos usuários que consideram o produto um “must-have”, o que possibilita descobrir qual é a principal percepção de valor dos usuários “apaixonados”. Quando for identificado um padrão, essa resposta vai auxiliar imensamente na otimização da mensagem do produto.
Além disso, essa percepção de valor também é importante na hora de implementar o modelo de negócios do produto, especialmente para o caso do produtos Freemium, já que um dos erros mais comuns de estratégia de monetização é colocar no componente Free features que são essenciais para o usuários, e cobrar na parte Premium coisas que são dispensáveis, resultando em uma baixa conversão e retenção.

- Pergunta 5: Você já recomendou o produto para alguém?
Além de identificar se o produto vale uma recomendação (em alguns modelos de negócio, isso é essencial), caso afirmativa essa resposta auxilia a entender como os usuários descrevem o produto. É uma outra forma de ajudar a entender e otimizar a mensagem que o produto deve passar.

- Pergunta 6: Que tipo de pessoa você acredita que mais pode aproveitar o produto?
As respostas aqui ajudam a refinar melhor qual deve ser o público-alvo do produto, especialmente se a apresentação do produto ainda está muito baseada em features horizontais, sendo então possível identificar nichos verticais onde o produto se aplica melhor. Essa análise fica mais completa se combinada com o filtro de origem do usuário.

- Pergunta 7:  Como posso melhorar o produto para atender melhor suas necessidades?
Essa pergunta ajuda a identificar qual deve ser o roadmap de desenvolvimento do produto (melhorias no MVP). Porém, antes de sair acatando qualquer feedback dos usuários, é muito importante identificar um caso de uso comum para os usuários “apaixonados”, e então orientar o desenvolvimento para melhorar esse benefício principal percebido por eles. Essa pergunta também é uma das principais fonte de sugestões para melhorar o índice de usuários que consideram o produto um “must-have”. Para isso, basta filtrar as respostas pelos usuários “nice-to-have” e identificar as melhorias pedidas por eles, desde que o caso de uso seja similar ao dos usuários “must-have”.

- Pergunta 8: Você se importaria se eventualmente nós entrássemos em contato contigo por email para tentar entender melhor algumas de suas respostas?
Essa pergunta é bastante auto-explicativa, e em geral as pessoas dos grupos “nice-to-have” e “must-have” tendem a deixar o email à disposição. Esse contato é importante não só para esclarecimentos e interações futuras mais profundas, mas também para iniciar um trabalho de CRM com os early adopters com coisas simples (ex. avisando o usuário de que determinada melhoria que ele pediu foi implementada).

Como observação final, vale reforçar que essa pesquisa não substitui as outras formas de feedback, mas condensa uma boa combinação de dados qualitativos com uma métrica fundamental: a quantidade de usuários que acreditam que o seu produto é um “must-have”. Mantendo isso em mente, é possível fazer adaptações ao modelo para identificar e auxiliar na tomada de decisão sobre questões específicas de cada negócio, caso necessário.

Para descobrir a combinação Problema/Solução para o seu produto, a Startup deve estabelecer um processo iterativo que permita um aprendizado constante sobre os clientes e outras premissas do negócio. Esse processo é uma combinação de experimentações práticas com investigações qualitativas que buscam extrair dados para comprovar as hipóteses dos empreendedores, bem como as nuances e “porquês” que estão por trás do comportamento dos clientes. No centro dessa experimentação está o conceito do Minimum Viable Product (MVP).

O MVP tem como definição “o mínimo conjunto de funcionalidades que permite uma ação e aprendizado sobre os clientes ou usuários”. Sua origem remete ao mantra release early, release often das metodologias ágeis de desenvolvimento, prática que coloca o feedback real dos usuários como norte da evolução do software. Em termos de estratégia geral para o lançamento de produtos, também são vários os defensores desta abordagem. (alguns exemplos aqui, aqui e aqui)

No entanto, o MVP vai além da prática agile comum em dois pontos principais. Primeiro, a preocupação principal do MVP não é colher sugestões gerais para o produto, mas sim provar a visão inicial do empreendedor. Parafraseando Steve Blank, Customer Development não é um Focus Group. Segundo, além de testar a utilização do produto e suas features, o MVP também serve – e deve ser usado – para testar as demandas do mercado com relação ao produto. Ou seja, para determinadas iterações, o objeto do experimento não será o software em si, mas outros componentes que permitem validar outras hipóteses do negócio.

Por exemplo, o MVP pode tomar forma de uma campanha de anúncios no Google Adwords combinada com a criação de diferentes landing pages para testar a reação dos consumidores sobre diferentes tipos de chamadas para o benefício principal do produto. Ou então, split tests para estudar qual a melhor opção de pacotes de preços/funcionalidades do produto.  Ou então, uma apresentação em ppt para guiar uma série de entrevistas com potenciais clientes. Ou então, uma chamada fake para uma nova funcionalidade  no software só para testar a receptividade dos usuários atuais. E por aí vai… Resumindo, o MVP toma qualquer forma que seja necessária para garantir um aprendizado relevante que ajude a Startup a caminhar em direção ao Product/Market Fit.

Portanto, mais do que a forma específica que o MVP toma para um determinado experimento, o mais importante é a criação da cultura de experimentação que permite o aprendizado de uma forma lean, gastando a menor quantidade de recursos e tempo possível. Deixo duas frases abaixo que reafirmam essa questão do processo:

“Entrepreneurship in a lean startup is really a series of MVP’s.” – Eric Ries

“You can’t identify one thing and then stop talking to your customers and go build.  Because you’re not really building a product – you’re building an environment that supports increasingly educated guesses.” – Cindy Alvarez

Interiorizada a necessidade do processo, resta responder a questão: o que construir e testar primeiro? Essa resposta não é simples, e está muito relacionada ao tipo de negócio da Startup e quais são suas hipóteses mais importantes e questionáveis. Em linhas gerais, para produtos corporativos de alto valor agregado, a recomendação inicialmente é testar a demanda principalmente através de apresentações e entrevistas com potenciais clientes. Para produtos voltados para pequenas/médias empresas ou para o consumidor final, testar a demanda via Web também é essencial (por landing pages, formulários de conversão, etc.), mas dependendo do caso os testes da experiência com o produto também passam a ser importantes. Já para produtos B2C onde o modelo de negócio é venda de publicidade, ou seja, exigem a adoção de larga escala de usuários, os MVPs devem caminhar mais fortemente em direção à construção do próprio produto, algo que Andrew Chen cunhou como Minimum Desirable Product.

Definir o que deve ser o próximo MVP a cada iteração é uma arte, não uma ciência.

Para ilustrar melhor, esse post do Venture Hacks traz alguns exemplos de MVPs bastante interessantes. Deixo abaixo também um vídeo e os slides de uma apresentação do Eric Ries sobre o tema.

Até a Startup estar pronta para passar para a fase de crescimento, o processo de Customer Development pode ser dividido em duas etapas, com preocupações principais distintas. A primeira etapa, a qual Steve Blank denominou Customer Discovery, tem como objetivo transformar as principais hipóteses do negócio em fatos, ou seja, essencialmente provar que um determinado mercado possui um Problema, e que a sua Solução (Produto) atende a essa necessidade dos clientes ao custo proposto. Na segunda etapa, chamada Customer Validation, o objetivo é encontrar um modelo de negócios escalável para o produto.

Dependendo do tipo de negócio, essa comprovação necessária para passar o Customer Discovery pode tomar várias formas. Por exemplo, para o caso das Startups visando o mercado corporativo (produtos de alto valor agregado), a afirmação que Steve Blank faz em seu livro é que tendo cerca de 3 a 5 empresas assinando uma Carta de Intenções de Compra do seu produto seria evidência suficiente para se passar para a próxima etapa. Já para Startups Web (B2C ou B2SB), Sean Ellis usa como indicador o percentual de usuários que ficariam muito desapontados se o seu produto não existisse. Segundo ele, se esse número for maior que 40%, a Startup já encontrou a combinação Problema/Solução (Problem/Solution Fit). A figura abaixo ilustra o modelo resumido da Startup Pyramid do Sean Ellis, onde a fatia de baixo representa o Customer Discovery para Startups Web.

Startup Pyramid do Sean Ellis (versão resumida)

(Obs. Na verdade, como mostra a figura, Sean Ellis utiliza o termo Product/Market Fit para definir esse estado onde o indicador de “usuários que ficariam muito desapontados sem o produto” é maior que 40%. Aqui no blog manterei a definição de Product/Market Fit usada pelo Steve Blank, que é encontrar um Modelo de Vendas Repetível e Escalável. Determinadas Startups chegam ao ponto de encontrar o Problem/Solution Fit para seu produto, porém ainda não possuem um modelo escalável de aquisição de clientes, que é exatamente o aspecto que Sean Ellis trabalha na parte Transition to Growth da sua pirâmide acima.)

Resumindo, encontrar essa combinação de Problema/Solução (Problem/Solution Fit) deve ser a preocupação principal do empreendedor nos momentos iniciais da Startup.

O primeiro passo do processo de Customer Discovery é externalizar as Hipóteses, ou seja, as premissas pelas quais o negócio será tocado. É importante gastar um tempo refletindo especialmente sobre o público-alvo, sua necessidade, como o produto vai atendê-la e qual o modelo de negócio previsto (preço do produto, custo de aquisição de clientes e seu lifetime value), nem que seja ao estilo “conta de guardanapo de boteco”. (Disclaimer: proponho uma reflexão, não escrever um Plano de Negócios)

Os itens abaixo sugerem algumas ideias de perguntas a serem respondidas nesta fase:

- Produto: Quais são as features imaginadas? Quais é o benefício principal entregue pelo produto? Qual é o roadmap de desenvolvimento esperado? Há custos indiretos da adoção do produto (ex. treinamentos, infra-estrutura, etc.)? O produto é auto-suficiente ou precisa da adoção de outros complementares? Propriedade Intelectual é algo relevante neste caso? 
- Cliente e Problema: Qual é o perfil do público-alvo? Quais são as características principais desse(s) segmento(s)? Qual recorte desse segmento representaria os early-adopters? Quem toma decisão, quem compra, quem influencia e quem usa o seu produto dentro da empresa (importante especialmente para produtos corporativos)? Qual é o problema que esse público tem que o produto pretende solucionar? Para esse público, o produto é uma aspirina ou uma vitamina? Qual é o Retorno sobre Investimento (ROI) que os clientes podem esperar para o produto? Qual é o menor conjunto de features que atenderia o problema principal desse público? Quão grande é esse nicho de mercado que pretende ser explorado (projeção preferencialmente bottom-up)?
- Preço e Distribuição: Como é o processo de compra do seu produto? De forma direta ou por intermediários? Caso haja formas indiretas de vendas, quais são os diferentes canais imaginados? Quais são os custos diretos e indiretos esperados para cada canal? Quais são os benefícios esperados para os intermediários? Se há algum produto semelhante ao seu no mercado, quanto custa? Se não, como os potenciais clientes estão resolvendo o problema hoje e quanto eles estão pagando por isso? Quais são os planos e pacotes imaginados? Qual é a divisão de receita dentro de cada elemento dos diferentes canais de distribuição?
- Criação de Demanda: Como os usuários vão saber do produto? Propaganda? Boca-a-boca? Através de parceiros? Outros? Destes anteriores, qual deve ser o principal canal de geração de demanda? Quem são as pessoas ou empresas mais influentes para o seu público-alvo? Qual a mensagem “ao redor do produto” que pode ressoar com eles? Que tipo de conteúdo pode ser produzido para alavancar demanda via Inbound Marketing? Como é o processo de geração de oportunidades de negócio (leads) do seu produto?
- Tipo de Mercado (Market Type): O produto se encaixa em um novo mercado (não há nada parecido hoje), em um ambiente competitivo de um mercado existente (vários players), ou é uma nova segmentação por preço ou nicho de um mercado existente?  Para mercados existentes, qual é o posicionamento único que o seu produto propõe? Para mercados resegmentados, qual é o público que ainda não consome o produto devido a questões de custo ou falta de features específicas? Para novos mercados, o que fará os clientes perceberem o problema e começar a comprar/usar o produto? Qual é a curva de adoção esperada? Há reservas suficientes na Startup para aguardar essa adoção se concretizar?
- Competição: Quem são os concorrentes diretos do produto (mesma proposição de valor)? Caso não haja produtos similares, quem são os concorrentes indiretos (maneira atual de se resolver o problema)? Em que o seu produto é diferente: preço, features, simplicidade, canal de distribuição, etc.? Quão grande é a barreira de entrada no mercado atualmente? O que pode ser feito para evitar ou minimizar o impacto de novos entrantes?

O próximo passo é testar essas hipóteses e buscar transformá-las em fatos, neste momento focando prioritariamente nas três primeiras categorias (Produto, Cliente e Problema). Para produtos corporativos, o Four Steps to the Epiphany traz o passo-a-passo detalhado para ser percorrido pelas Startups, como mostra a figura abaixo:

Para Startups de Web, o processo é muito mais iterativo e apresenta uma gama maior de possibilidades. No entanto, como não há caixas bem definidas (como as do modelo acima), o avanço não fica tão claro na cabeça do empreendedor. Por isso é importante definir métricas e fazer experimentações diversas para analisar o impacto. Além das métricas, é essencial um contato constante e individual com os potenciais clientes, principalmente nesta fase onde o objetivo é encontrar o Problem/Solution Fit. Entrevistas presenciais (ou por telefone) podem trazer insights que nenhuma pesquisa online ou análise de planilha traria. Métricas são importantes, mas não o suficiente.

No centro dessa experimentação está o conceito de Minimum Viable Product (MVP), que é a versão do produto que permite à equipe coletar a máxima quantidade de aprendizado validado (fatos) com o menor esforço possível – e mais importante, da forma mais rápida possível.  O próximo post aqui no blog será dedicado a explorar com detalhes o que é o MVP.

Em suma, a experimentação pode ser definida por esse ciclo iterativo:

1) Identificar hipótese principal a ser testada;

2) Definir e construir o próximo MVP;

3) Rodar testes qualitativos e quantitativos (surveys, entrevistas, A/B testing, campanhas Adwords, testes de usabilidade, etc.);

4) Conclusões e revisões das hipóteses.

Essa iteração em torno dos MVPs se encaixa ao conceito do Loop Fundamental da Startup apresentado no post anterior sobre o que é a Lean Startup (imagem abaixo). Apesar do critério de saída dessa fase de Customer Discovery ser definido por encontrar a combinação Problema/Solução, esse Loop iterativo continuará sendo útil mesmo na fase de Execução (crescimento) da Startup, ajudando a criar e manter a cultura de uma empresa baseada em fatos e não em opiniões.

Ps. Tenho publicado aqui posts mais densos e longos do que é a “recomendação geral” para um blog. O que vocês acham? O tamanho está razoável ou devo tentar quebrar ou resumir melhor os posts? Comentários e sugestões sobre o formato e conteúdo são muito bem-vindos!