Quem já leu o livro Founders at Work (ou Startup, aqui no Brasil) pode perceber que a grande maioria das empresas de sucesso presentes tiveram que fazer mudanças bruscas na ideia inicial, seja em termos de produto, tipo de cliente, canal de distribuição, preço, posicionamento, etc. Eric Ries batizou de Pivô essa correção de rota, e desde então o termo tem sido muito usado e discutido por diversos empreendedores e investidores.

Mike Maples, fundador da Floodgate , um dos VCs mais procurados nos EUA ultimamente, falou recentemente sobre a importância do Pivô para a criação de negócios de sucesso. Mike definiu o que ele considera um Pivô e mostrou os cases de três empresas investidas por ele – ngmoco, Chegg e Twitter – que tiveram que fazer alterações significativas nos seus planos iniciais.

Segundo ele, o Pivô não é apenas uma iteração. É uma mudança radical no Modelo de Negócio.

Nos casos em que a Startup está estagnada a necessidade dessa mudança é relativamente fácil de ser identificada, mas ainda assim difícil de ser executada. No entanto, os melhores empreendedores também são capazes de identificar oportunidades de pivôs mesmo quando já há algum legado na Startup (produto, clientes, marca, etc.), em nome de um Modelo de Negócio melhor e mais escalável. Em todos casos, o Pivô exige coragem para “jogar muita coisa fora”.

Mike comentou que o Pivô pode tomar formatos diferentes. Nos exemplos ilustrados, a ngmoco promoveu um pivô de modelo de receita, o Chegg fez um pivô de produto, enquanto o Twitter (Odeo) fez um pivô completo da empresa.

Fechando a apresentação, Mike deu algumas dicas práticas sobre como conduzir esse processo:

- Penser em termos de Modelo de Negócio, não Plano de Negócio. (“Universidades deveriam abolir as competições de plano de negócios”);

- Tenha sempre declarada suas hipóteses de Modelo de Negócio. Prove-as o quanto antes;

- Não fique vivendo em modo “Zumbi”. Não tenha medo de jogar fora o que construiu em busca de algo melhor;

- No entanto, não fique pulando de galho em galho de forma compulsiva. Os pivôs devem ser feitos com cuidado e muita reflexão;

- Não entre em pânico dentro do furacão. Os pivôs são difíceis e sempre haverá resistência, inclusive da sua própria equipe. Faça isso com consenso e ajuda do Board.

Vale a pena conferir o vídeo na íntegra:

No penúltimo post da série da Startup Lessons Learned Conference (eu sei… isso se arrastou por tempo demais…), vou resumir os melhores momentos do painel “But who should actually get out of the building”, que na prática foi uma sessão de Perguntas e Respostas sobre Customer Development.

O painel foi moderado pelo Sean Ellis e participaram da mesa outras pessoas com muita experiência prática no tema: Cindy Alvarez, David Binetti, Brant Cooper e  Matt Johnson.

Sean começou a sessão ressaltando que, de toda a sua experiência em uma série de Startups, qualquer Startup bem-sucedida precisa ter um produto que seja “must-have” por um mercado suficientemente grande. Apesar dele mesmo trabalhar com Marketing, a provocação é que um ótimo marketeiro não pode salvar um produto que não seja “must-have”, mas um marketeiro médio ainda pode fazer crescer bem um produto “must-have”.  Customer Development então serve para auxiliar neste processo de descoberta do que os clientes/usuários querem, e ultimamente levar à criação de um produto “must-have” para um mercado definido.  (mais no seu clássico post da pirâmide)

A partir desse ponto, repasso as questões perguntadas pela plateia e os principais trechos das respostas dos painelistas.

Pergunta: Quais são as diferentes técnicas para se colher feedback do usuário?

Brant Cooper: Depende do estágio que você está, mas no início é essencial ficar cara-a-cara com o cliente. Descubra se suas hipóteses sobre o problema e sobre os clientes estão corretas.

David Binetti: Lance o quanto antes o que quer que você tenha em mãos. Citando Kent Beck, “nós mesmos temos a tendência de nos atrapalhar”.

Cindy Alvarez: Você não precisa ter nem um mockup ainda. Basta conversar com os seus potenciais clientes e perguntá-los como eles estão lidando com o problema/tarefa hoje. Descubra o processo atual e onde ele “dói”. Isso vai te dar um feedback mais cru, completamente dissociado da solução que você tem em mente.

Pergunta: Informações sobre concorrentes são úteis para validar o mercado? Se sim, como pegá-las?

Sean Ellis: No início, ignore os concorrentes. Geralmente as pessoas não conhecem (ou não há) concorrentes para satisfazer o mesmo problema e caso de uso que elas têm. Chegar ao Product/Market Fit é algo entre você e o seu cliente.

Matt Johnson: Se os seus concorrentes já “quebraram”, facilmente eles falarão contigo sobre qualquer ponto do negócio. Se eles ainda estão no mercado, finja ser um estudante/blogueiro/jornalista para tentar tirar alguma informação importante.

David: Faça Landing Pages e compre Adwords com anúncios do tipo: “Odeio o Concorrente X”. Descubra quais necessidades não estão sendo atendidas pelos clientes.

Pergunta: Como lidar com Customer Development no caso dos clientes serem grandes empresas, que estão acostumadas a lidar com produtos bem acabados?

Cindy: Faça um demo com um protótipo/mock-up e apresente o roadmap de desenvolvimento. Se eles perguntarem quando o produto vai estar pronto, é um ótimo sinal.

Brant: Se não for isso, qual a alternativa? Arriscar construir todo o produto sem ter feedback do mercado?

Pergunta: Como encontrar um mercado/problema se eu ainda não tenho uma ideia?

Brant: Três formas: escolha um segmento e tente achar um problema, escolha algo para um segmento em que você tenha expertise, resolva um problema que você tenha.

Pergunta: Devo investir em assessoria de imprensa? Se sim, quão cedo?

Sean: Apostar na tática “lançar e fazer a maior fumaça possível, ganhar primeiros usuários e depois crescer de forma viral” é uma loteria. Às vezes dá certo, mas as chances são baixíssimas.
A alternativa: Coloque o produto no ar e atraia os primeiros usuários, colha feedback, descubra a proposição de valor que está funcionando e coloque suas fichas nisso (tire todo o resto que não tem a ver com essa proposição de valor). Depois traga eficiência na conversão e no modelo de negócio, e depois tente crescer.

David: Não gaste um centavo. Se você ainda não sabe o que está vendendo, qualquer exposição é inútil. Você acaba se distraindo com “métricas vaidosas” e exposição pela própria exposição. Startups de network-effect são um pouco diferentes, mas isso já é uma loteria por si só e não é para a maioria das pessoas.

Brant: Depende do seu objetivo no momento. Um pouco de RP pode ser útil para ajudar a captar investimento, por exemplo, mas saiba porque está fazendo isso.

Pergunta: E como é Customer Development para negócios baseados em publicidade?

Sean: Esse tipo de negócio tende a ser muito ruim, pois precisa de uma enorme escala para se tornar viável, e a geração de valor para o cliente (anunciante) em geral está na contramão da experiência do usuário. A chave é achar uma forma de alinhar essas duas gerações de valor, como o Google faz por exemplo.

Pergunta: Se eu encontro Product/Market Fit para um segmento e depois descubro que esse nicho é muito pequeno, devo fazer o pivô para um segmento maior?

Brant: Geralmente você consegue fazer um cálculo bottom-up para descobrir o potencial de um segmento antes de entrar nele, mas ainda assim é possível “cair” na situação perguntada. Seria loucura simplesmente jogar fora Product/Market Fit fazendo o pivô para sair de um segmento, mas você pode começar a procurar nichos adjacentes que também podem ser atendidos com o mesmo produto.

Sean: Uma das partes mais difíceis de ser um empreendedor é ter que sacrificar oportunidades para tentar maximizar a chance de sucesso em uma coisa exclusiva. Isso vale também para a segmentação de mercado. Em geral é difícil prever com exatidão qual é o tamanho da oportunidade que está à frente (ex. disso: Apple ignorando o mercado corporativo).
Provavelmente você tem uma chance melhor de criar um grande mercado a partir de um produto “must-have” de um mercado pequeno do que jogar isso fora e tentar encontrar outro mercado maior, mas que você ainda não provou que pode gerar valor lá.

Pergunta: Como vocês veem o MVP e como fazem geralmente?

David: MVP não pode ser só uma Landing Page. Tem que ser funcional de alguma forma. Customer Validation só vem a partir de produtos reais.

Cindy: Mostre protótipos do que seria a solução e veja se faz sentido para os clientes. Depois disso não faz mal  ”se esconder” por algumas semanas para implementar uma versão funcional.

Sean: Vídeos (como no exemplo da Dropbox) podem ser uma boa arma para testar uma reação emocional que apenas landing pages e screenshots não conseguem oferecer.

David: Passe pelos loops de validação das hipóteses o mais rápido possível.

Sean: O objetivo principal é descobrir o quanto antes se você está indo em direção a um beco-sem-saída, e corrigir o curso se for o caso. Mantenha a busca por validação do modelo.

Pergunta: Como validar um produto de network-effect?

Sean: Procure alcançar massa crítica em um recorte de mercado muito pequeno e definido, e assim provar o modelo. Depois tente replicar para outros segmentos.
Definitivamente é um processo diferente do que o do “Four Steps to the Epiphany”.

Brant: Se não for possível em cima do próprio produto, tente validar a capacidade de viralização de algumas ideias ou sub-elementos do produto.

Pergunta: Quais são boas táticas de Marketing após atingir Product/Market Fit?

Sean: Refine o processo de conversão e o modelo de negócio antes, a partir daí fica muito mais fácil encontrar canais acessíveis para se crescer. Depois busque por canais que sejam tanto lucrativos quanto escaláveis.

Matt: Não há fórmulas. As lições da Dropbox mostram que isso é completamente dependente do negócio que você tem.

Sean: Todos os canais pagos em algum ponto atingem saturação. A única forma completamente escalável de crescer é de forma orgânica, a partir de usuário/clientes extremamente satisfeitos.

Segue abaixo o vídeo na íntegra:

Depois de um pequeno hiato aqui no blog devido ao início de um novo projeto pessoal (compartilharei mais sobre isso em breve), volto ainda na série de resumos e observações sobre a Startup Lessons Learned Conference, desta vez com a palestra do Hiten Shah da KISSmetrics.

Hiten falou sobre os aprendizados e os consequentes pivôs pelos quais eles já passaram com a KISSmetrics desde o seu início. Mais do que as conclusões em si, foi muito interessante entender o processo de levantamento e prova de hipóteses que se passou a cada grande iteração, algo que pode ser replicado por qualquer Startup nas fases de Customer Development antes de se chegar ao Product/Market Fit. Farei o resumo a seguir, deixando o vídeo e os slides no final do post.

A palestra começou com Hiten falando rapidamente sobre o seu background como empreendedor. Ele contou que, apesar de ter alcançado um relativo sucesso numa empresa de projetos de consultoria de marketing online, ele e seu sócio Neil Patel perceberam que o negócio de consultoria não conseguia escalar, e foram diversas as iniciativas mal-sucedidas de lançamento de produtos com os quais eles cometeram erros de condução que os princípios de Lean Startups viriam a consertar depois. (Como link complementar, nesta entrevista para o Andrew Warner do Mixergy ele conta em mais detalhes suas história pessoal).

Ainda antes de entrar no caso específico do KISSmetrics, Hiten lembrou que fazer o pivô – mudar radicalmente o modelo de negócio da empresa – é muito difícil para todo mundo, mas as empresas de sucesso na área de tecnologia sempre o fazem, vide como exemplos PayPal, YouTube, Facebook, etc.

Ele também ressaltou que, apesar de ter flexibilidade para mudar o produto e o modelo de negócio, o propósito central da empresa deve ser consistente ao longo do tempo, o que permite alavancagem e assertividade a cada pivô executado. Isso também ficou bastante claro no case da Aardvark relatado anteriormente aqui no blog.

Sobre a KISSmetrics

Por estratégia, convicções e até objetivos pessoais com o negócio, os sócios definiram que a Visão da KISSmetrics era a de que:
- A ideia macro do produto era prover uma ferramenta de Web Analytics que desse subsídio à ação;
- O produto deveria ser baseado na Web e o modelo de receitas de assinatura (SaaS);
- O processo de venda e distribuição também deveria ser todo na Web, com pouco ou nenhum contato pessoal com o cliente (mais escalável).

Primeira Iteração

Na primeira grande iteração do produto, a ideia era desenvolver uma ferramenta de Analytics destinada aos desenvolvedores de aplicações sociais (ex. games no Facebook) para ajudá-los a entender o comportamento dos seus usuários. Suas premissas principais eram:
- Esses desenvolvedores precisavam de ferramentas específicas de Analytics;
- Estão dispostos a pagar por isso;
- Fazem parte de um segmento de mercado que cresce.

Eles levaram seis meses para construir o produto e atrair os primeiros clientes, e depois de experimentações perceberam que o produto era excessivamente segmentado e não-flexível o suficiente. Entre outras coisas, aprenderam que:
- Desenvolvedores de aplicativos precisam fazer dinheiro;
- Analytics é um problema universal (as ferramentas atuais não resolvem os principais problemas);
- As pessoas querem relatórios customizáveis de suas ferramentas.

Segunda Iteração

Premissas:
- Todo mundo precisa de Analytics;
- As pessoas sabem o que querem medir;
- Eles querem dashboards customizáveis.

O produto novamente levou seis meses para ser construído mas os primeiros clientes chegaram para os testes um pouco antes, com quatro meses de desenvolvimento (o que Hiten ressalta que ainda é demais). Durante esse processo, eles estavam acatando e implementando praticamente todos os pedidos dos usuários do produto. Depois de muito experimentar, essa nova tentativa também falhou e eles foram obrigados a fazer o pivô novamente. Ficaram como aprendizados:
- Na verdade as pessoas não sabem o que devem medir;
- Relatórios muito customizáveis requerem muitas adaptações individuais ao produto, o que não era escalável;
-  Nem todos os clientes são lucrativos.

Terceira Iteração

Dessa vez, o público-alvo do produto eram os Marketeiros online, pessoas responsáveis por promoção e aquisição de clientes em outros serviços Web. As premissas eram:
- Eles se preocupam com métricas que permitem tomada de decisão;
- Eles querem melhorar os seus índices de conversão (e assim conseguir aproveitar novos canais de aquisição);
- Desde que dê resultado, estão dispostos a pagar por Analytics;

A implementação deste produto teve o tempo de release inicial sensivelmente reduzido: apenas um mês de desenvolvimento. Até o momento da conferência, o produto ainda estava em beta fechado e sem clientes pagos, mas Hiten destacou que o feedback e a adesão estavam incomparavelmente melhores do que nos outros produtos, e que em pouco tempo eles estariam alcançando o Product/Market Fit (pela definição do Sean Ellis, 40% dos usuários identificando o produto como um must-have).

Dicas e Lições Aprendidas

Para fechar a palestra, Hiten deixou algumas dicas e lições aprendidas com o desenvolvimento dos produtos e os pivôs:

- Tenha foco em um segmento específico do mercado. Foco permite que se possa criar um produto classe A;
- Todo prospect é importante. Pessoas que não estavam usando os produtos iniciais foram os que deram o feedback mais relevante;
- Procure por padrões de comportamento e uso. Fica mais fácil identificar quando é a hora de fazer o pivô, bem como facilita a comunicação com colaboradores e investidores. Para isso, procure colher dados significativos, documente observações sobre conversas com clientes e, se possível, colha vídeos da experiência do usuário usando o produto;
-  Para conseguir essas entrevistas e vídeos, ofereça descontos e prazos estendidos de testes gratuitos do produto;
- Menos é Mais. Menos tempo deve ser gasto em implementar funcionalidades, e mais tempo deve ir para conversas com clientes (atuais e potenciais). Tente entrar o máximo possível nos seus problemas;
- Tente validar as funcionalidades com os clientes antes de implementá-las. (link complementar: Ash Maurya falou muito bem sobre isso na sua apresentação);
- Gratificação e user experience para os novos usuários é muito importante, mas pode ser acertada depois. Os early adopters tendem a perdoar muito mais deficiências de usabilidade;
- Siga a recomendação do Sean Ellis: não cobre pelo produto antes do Product/Market Fit, mas deixe claro que isso vai acontecer mais à frente. (cobri esse assunto neste post da série Freemium).

Finalizo o post deixando o vídeo e os slides da palestra:

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:

Nos posts iniciais desse blog, preocupei-me em fazer uma introdução mais conceitual – ainda que fundamental – para o entendimento do que se propõe o movimento das Lean Startups. Argumentei que o principal desafio das Startups é encontrar mercado para o seu produto visionário, que o modelo tradicional de desenvolvimento tem sido o responsável pela alta taxa de fracassos das Startups por alguns motivos bem conhecidos, e que há uma metodologia chamada Customer Development destinada a mitigar o risco de mercado associado à criação de qualquer produto de base tecnológica.

A Lean Startup é a forma prática de implementar a cultura de aprendizado necessária para as Startups, principalmente para o caso das empresas de software. Essa filosofia está ganhando cada vez mais corpo nos círculos de empreendedorismo tecnológico ao redor do mundo, especialmente em seu epicentro, o Vale do Silício, onde os efeitos da crise econômica têm refletido bastante na quantidade de Venture Capital disponível, o que consequentemente tem obrigado as Startups a serem muito mais eficientes e objetivas.

A premissa principal da Lean Startup é de que quanto maior a velocidade e menor o custo de cada grande iteração – onde a Startup valida ou descarta hipóteses importantes sobre o seu produto ou mercado – maiores são as suas chances de sucesso. Não raros são os casos onde essas iterações resultam em mudanças significativas na ideia original dos fundadores, o que Eric Ries chama de pivôs. De fato, em retrospectiva, um ponto em comum que caracteriza a grande maioria das Startups bem sucedidas (ex. Paypal, Flickr, Microsoft, eBay, Youtube, etc.),  é que elas souberam fazer esses pivôs conforme iam descobrindo novas evidências sobre o seu negócio. Esse fenômeno fica bastante claro na leitura do excelente Founders at Work.

A Lean Startup baseia-se na combinação do seguinte tripé:

- Customer Development: Processo detalhado para testar e validar suas hipóteses sobre clientes, produto e mercado. (mais detalhes no post anterior)

- Desenvolvimento Ágil: Aplicação de metodologias tais como XP e Scrum (ajustadas para o ambiente das Startups) que possibilitam grande redução do tempo de cada iteração de desenvolvimento,  aumentando a velocidade do aprendizado através de feedback real dos clientes/usuários.

- Plataforma Tecnológica como commodity: Uso de serviços, frameworks e tecnologias diversas (ex. WordPress, Amazon EC2, Google Adwords, Ruby on Rails, só para citar alguns), que garantem baixo custo e uma agilidade sem precedentes na construção de produtos de base tecnológica.

Em suma, a Lean Startup parte do princípio que tanto o Problema (necessidade do cliente) quanto a Solução (produto) são desconhecidos, e que a descoberta de ambos é um processo iterativo que aglutina o desenvolvimento do produto com atividades de Customer Development, seja por investigação qualitativa (entrevistas, testes de usabilidade, etc.) ou por experimentação quantitativa com software em produção com clientes reais. A figura abaixo ilustra essa integração.

Para o caso das experimentações quantitativas, Eric Ries fez um diagrama simplificado do que ele chama de Loop Fundamental de uma Lean Startup, que ilustra melhor como a equipe deve proceder nas atividades “dentro do escritório”.

O termo Lean aplicado para Startups vem do conceito de Lean Manufacturing,  filosofia de gestão focada na redução de desperdícios. No caso de empresas de software, a maior fonte de desperdício é “produzir software que ninguém quer”. Desta forma, a promessa da Lean Startup é a de acelerar o aprendizado e reduzir esse desperdício, garantindo que a Startup chegue o quanto antes ao Product/Market Fit.

Há uma série de técnicas para serem aplicadas que serão discutidas em posts futuros aqui no blog, tais como split-testing, métricas, MVP, Continuous deployment, Five Why´s, entre outras.

Para finalizar, deixo abaixo uma apresentação sobre Lean Startups feita pelo Eric Ries no Web 2.0 Expo em San Francisco deste ano. Tive o prazer de assisti-la presencialmente junto com meu amigo Miguel Cavalcanti, e depois participamos de uma sessão bate-papo com o Eric Ries e outro empreendedores sobre práticas mais específicas. Para quem ainda tiver tempo, recomendo também assistir ou escutar essa ótima entrevista dele com o Andrew Warner no Mixergy.