Warning: ob_start(): non-static method wpGoogleAnalytics::get_links() should not be called statically in /home/ericnsantos/manualdastartup.com.br/blog/wp-content/plugins/wp-google-analytics/wp-google-analytics.php on line 259

Warning: Cannot modify header information - headers already sent by (output started at /home/ericnsantos/manualdastartup.com.br/blog/wp-content/plugins/wp-google-analytics/wp-google-analytics.php:259) in /home/ericnsantos/manualdastartup.com.br/blog/wp-includes/feed-rss2.php on line 8
Manual da Startup » sllconf http://www.manualdastartup.com.br/blog Práticas sobre Lean Startups, Customer Development e empreendedorismo em geral Thu, 12 Apr 2012 16:08:11 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Dicas de Customer Development na prática (SLLConf) http://www.manualdastartup.com.br/blog/dicas-de-customer-development-na-pratica-sllconf/ http://www.manualdastartup.com.br/blog/dicas-de-customer-development-na-pratica-sllconf/#comments Wed, 25 Aug 2010 11:29:29 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=411

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:

]]>
http://www.manualdastartup.com.br/blog/dicas-de-customer-development-na-pratica-sllconf/feed/ 3
Do zero a milhões de usuários – as lições de marketing da Dropbox http://www.manualdastartup.com.br/blog/do-zero-a-milhoes-de-usuarios-as-licoes-de-marketing-da-dropbox/ http://www.manualdastartup.com.br/blog/do-zero-a-milhoes-de-usuarios-as-licoes-de-marketing-da-dropbox/#comments Wed, 28 Jul 2010 15:21:27 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=400

A palestra da Dropbox na SLLConf não foi um caso tão elaborado de Customer Development como os da Food on the Table ou da Aardvark, por exemplo, mas foi um ótimo exemplo em termos de lições de Marketing antes e depois do Product/Market Fit.

Para complementar esse post, além das notas sobre a palestra fiz um apanhado das boas práticas de Marketing que fizeram com que a Dropbox chegasse a quatro milhões de usuários em apenas 18 meses depois do lançamento do produto, mantendo até hoje um crescimento sustentado de 15% a 20% mês após mês.




Com relação às práticas de Lean Startups, a palestra do Drew Houston (CEO da Dropbox) se resumiu a três pontos fundamentais:

O MVP deve estar adequado às possibilidades técnicas que permitem iniciar as iterações e o aprendizado

Ao contrário de grande parte das aplicações Web, pelas características inerentes ao produto – compartilhamento de arquivos – a Dropbox não podia se dar ao luxo de disponibilizar uma versão rústica (bugada) do produto para seus usuários, e então iniciar as iterações. Mesmo que a versão inicial do produto tivesse poucas funcionalidades, ela deveria ser necessariamente robusta.

Para eles, o bordão “release early, release often” não se aplicava, mas isso não significa que não havia a necessidade e nem formas de iniciar a validação das hipóteses, especialmente neste mercado onde já existiam várias soluções disponíveis. Então eles decidiram fazer um protótipo só com as telas do futuro produto e produziram um vídeo de demonstração deste protótipo. Depois submeteram esse vídeo no Hacker News e Digg, junto com uma landing page para coletar emails de possíveis interessados. Só com o buzz deste vídeo, eles conseguiram 75.000 emails cadastrados, o que validou que havia um bom sinal de demanda para aquele tipo de solução proposta.

Product/Market Fit é o que mais importa

Como Startup da YCombinator, a Dropbox levou bastante a sério o mantra “Make something people want”. Sabendo que o Product/Market Fit é o maior risco de uma nova iniciativa, a preocupação sempre foi aprender bastante com o mercado e direcionar o produto para atender uma necessidade real, mesmo com as limitações do MVP como falado acima. Segundo o próprio Drew, “não lançar é doloroso, mas não aprender é fatal”.

Entender essa geração de valor foi fundamental para o desenvolvimento do produto. A Dropbox intencionalmente deixou de fora diversas funcionalidades que os produtos dos concorrentes apresentavam, focando no refinamento da experiência em cima do que eles iam identificando que os clientes adoravam no produto (falei antes aqui e aqui sobre um dos métodos de pesquisa para essa descoberta). O próprio Sean Ellis, que foi um dos responsáveis pelo sucesso no Marketing da Dropbox, comentou sobre o poder que um forte Product/Market Fit tem no crescimento da empresa.

Não há “receita de bolo” nas táticas de Marketing

No processo de crescimento, a Dropbox testou uma série de formas de aquisição de clientes (com potencial de escalar), especialmente através de links patrocinados. O resultado não foi nem perto de satisfatório, pois o Custo de Aquisição de Cliente via busca paga chegava próximo de US$ 300,00, o que obviamente não era sustentável para o negócio. Segundo Drew, “a busca é excelente para colher demanda, mas não para criá-la”, o que era necessário no caso do produto deles.

Mais do que isso, eles perceberam que apesar das técnicas tradicionais de Marketing online não estarem funcionando, o número de usuários continuava crescendo rapidamente via boca-a-boca. Então, ao invés de forçar os outros canais, eles preferiram trabalhar para otimizar esse processo de recomendação. Novamente, essa otimização partiu de um conhecimento muito grande sobre a percepção de valor pelos usuários e de um entendimento claro sobre o processo de adesão e gratificação de um usuário típico. Foi em cima disso que eles criaram o programa de afiliados, por exemplo.

Bônus: Outras boas práticas de Marketing da Dropbox

- Tenha um produto simples de se usar;
- Entenda o “amor” ao produto e reforce sua gratificação (isso funcionou muito bem na hora de calibrar o Freemium e construir o programa de afiliados);
- Dê aos usuários boas ferramentas e motivação extra para recomendar o produto;
- Simplifique a sua mensagem. Depois simplifique mais e mais;
- Entenda o seu funil de vendas e otimize-o;
- Faça benchmarking com outros produtos que crescem muito rapidamente (ex. social games);
- Invista muito em analytics;
- Saiba onde seus early adopters estão e fale apropriadamente com eles (forma de abordagem, linguagem, etc.);

Para finalizar as dicas de Marketing, deixo a seguir outro ppt que o Drew Houston apresentou na Web 2.0 Expo junto com o Adam Smith da Xobni, outra Startup que conseguiu crescer muito rapidamente depois de descobrir o Product/Market Fit.

]]>
http://www.manualdastartup.com.br/blog/do-zero-a-milhoes-de-usuarios-as-licoes-de-marketing-da-dropbox/feed/ 7
Customer Validation sem uma linha de código – o case da Food on the Table http://www.manualdastartup.com.br/blog/customer-validation-sem-uma-linha-de-codigo-o-case-da-food-on-the-table/ http://www.manualdastartup.com.br/blog/customer-validation-sem-uma-linha-de-codigo-o-case-da-food-on-the-table/#comments Mon, 05 Jul 2010 12:26:30 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=392

Entrando no bloco Learn da SLLConf,  o primeiro estudo de caso foi apresentado pelo Manuel Rosso da Food on the Table. O case foi impressionante pela forma como os empreendedores conduziram as etapas de Customer Discovery e Customer Validation. Faço a seguir o resumo da palestra, deixando ao final o vídeo e os slides da apresentação.

Manuel começou a apresentação falando sobre como foi a sua introdução ao conceito de Customer Development e do paralelo que ele encontrou com as técnicas de Pesquisas de Mercado com as quais ele estava habituado nos seus trabalhos anteriores em grandes empresas.

Ele lembrou que a Pesquisa de Mercado surgiu pouco depois do período pós-guerra, quando a explosão da produção e distribuição de produtos em massa fez com que as empresas ficassem distantes dos seus consumidores, e taxa de fracasso no lançamento de produtos aumentasse significativamente.

Estas técnicas de Pesquisa de Mercado mostraram ótimos resultados a princípio, porém com o tempo elas começaram a ficar cada vez mais caras e demoradas para se manter efetivas, o que hoje apenas viabiliza a sua utilização por grandes empresas com grandes verbas de marketing. Customer Development seria então a evolução do conceito de Pesquisa de Mercado aplicado ao contexto de Startups.

Customer Development no Food on the Table

O Food on the Table é um serviço Web que ajuda as mães a planejar e a economizar com as refeições semanais da família. No entanto, Manuel contou que no início da Startup eles ainda não tinham essa forma de produto.  Pelo contrário, não havia nem hipóteses claras para serem testadas. O que eles tinham era uma ideia de mercado (mães “ocupadas”) e uma ideia de área de atuação (comida).

A estratégia deles foi conversar livremente com um grande número de mães (mais de 150) e entender pontos de “dor” em comum, e assim começar a desenhar possíveis soluções para esses problemas.

Customer Validation – a prova do problema com uma solução “manual”

Na fase de validação, a estratégia utilizada foi a de provar a solução na sua forma mais completa possível, de forma manual, com um serviço de consultoria embutido. Manuel brincou com a abordagem e chamou isso de Maximum Viable Product. A premissa principal deles era: se não tivermos demanda para essa solução “segurando na mão dos clientes”, definitivamente não teremos demanda para uma solução fria automatizada online.

A Food on the Table levou essa abordagem ainda mais além do que no case relatado da Aardvark. Eles vêem código (programação) essencialmente como uma forma de poder escalar a oferta e reduzir custos de um serviço para qual já se provou a demanda. Em outras palavras, só é produzido código quando uma tarefa está exigindo muito tempo pela sua execução “manual”. Parafraseando Manuel: “Os clientes se interessam somente pela resolução dos problemas deles. Eles não se importam com a sua tecnologia”.

Customer Acquisition – Landing Pages como ferramenta de aprendizado

Toda a evolução na aquisição dos clientes se deu através de melhorias nas Landing Pages. Essas melhorias foram derivadas de muitos testes quantitativos no site, mas também através de conversas com o público que foram importantes para aprender o porquê de determinados comportamentos.

Para cada iteração, eles se perguntavam: É possível acompanhar uma métrica-chave para nosso próximo objetivo? Se sim, se focarmos nossos esforços podemos impactar essa métrica?

Duas lições sobre Landing Pages:
- Invista em tráfego (compra de anúncios) para acelerar o aprendizado. Os experimentos estatísticos (ex. A/B tests) exigem uma grande amostra para serem conclusivos, portanto deve-se chegar a essa amostra o mais rápido possível para evitar a espera paralizante.
- As “Melhores Práticas” de produção de Landing Pages são sempre relativas. Cada segmento é diferente, portanto tome cuidado ao implantar as técnicas que deram certo para outros.

Para finalizar, Manuel compartilhou o email de reclamação de uma usuária sobre o serviço e comentou que não se deve ter medo de se expor por consequência das eventuais críticas. Pelo contrário, é excelente poder iterar a partir desses pontos de reclamação dos clientes. (Isso lembrou mantra “Maximize for Love or Hate” do Dave McClure)
Deixo abaixo o vídeo e os slides:

]]>
http://www.manualdastartup.com.br/blog/customer-validation-sem-uma-linha-de-codigo-o-case-da-food-on-the-table/feed/ 2
Os pivôs da KISSmetrics na busca pelo Product-Market Fit http://www.manualdastartup.com.br/blog/os-pivos-da-kissmetrics-na-busca-pelo-product-market-fit/ http://www.manualdastartup.com.br/blog/os-pivos-da-kissmetrics-na-busca-pelo-product-market-fit/#comments Mon, 28 Jun 2010 23:24:23 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=378

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:





]]>
http://www.manualdastartup.com.br/blog/os-pivos-da-kissmetrics-na-busca-pelo-product-market-fit/feed/ 10
Como a Flowtown usou MVPs e um Pivô para encontrar o seu modelo de negócio http://www.manualdastartup.com.br/blog/como-a-flowtown-usou-mvps-e-um-pivo-para-encontrar-o-seu-modelo-de-negocio/ http://www.manualdastartup.com.br/blog/como-a-flowtown-usou-mvps-e-um-pivo-para-encontrar-o-seu-modelo-de-negocio/#comments Thu, 27 May 2010 22:02:09 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=364

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ô

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.


]]>
http://www.manualdastartup.com.br/blog/como-a-flowtown-usou-mvps-e-um-pivo-para-encontrar-o-seu-modelo-de-negocio/feed/ 3
Como a Aardvark aplicou MVPs e Pivôs do início até a venda para o Google – notas da SLLConf http://www.manualdastartup.com.br/blog/como-a-aardvark-aplicou-mvps-e-pivos-do-inicio-ate-a-venda-para-o-google-notas-da-sllconf/ http://www.manualdastartup.com.br/blog/como-a-aardvark-aplicou-mvps-e-pivos-do-inicio-ate-a-venda-para-o-google-notas-da-sllconf/#comments Fri, 21 May 2010 15:00:36 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=353

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 DevelopmentLean 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.

Aardvark Social Search

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.

Processo de desenvolvimento Aardvark

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:

]]>
http://www.manualdastartup.com.br/blog/como-a-aardvark-aplicou-mvps-e-pivos-do-inicio-ate-a-venda-para-o-google-notas-da-sllconf/feed/ 6
Design vs. Métricas – notas do painel da SLLConf http://www.manualdastartup.com.br/blog/design-vs-metricas-notas-do-painel-da-sllconf/ http://www.manualdastartup.com.br/blog/design-vs-metricas-notas-do-painel-da-sllconf/#comments Fri, 14 May 2010 15:15:33 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=331

No final do primeiro bloco da Startup Lessons Learned Conference, tivemos a chance de acompanhar uma excelente discussão sobre o papel do Design em uma Startup e como ele se relaciona com uma postura de rigor e atenção com relação a Métricas.

Quem moderou o painel foi o Dave McClure, investidor e advisor de várias empresas conhecidas (ex. Bit.ly, Mint, SimpleHired, Slideshare, etc.) e completaram o painel pessoas não menos gabaritadas: Andrew Chen, Laura Klein, Siqi Chen e Rashmi Sinha.

Como o formato de painel é bastante difícil de se fazer um resumo em forma de narrativa, vou deixar abaixo algumas passagens interessantes de cada participante, bem como o vídeo e os links para os conteúdos relacionados.



Dave McClure

“Para Startups Web, Design geralmente é mais importante do que Engenharia”
(artigo relacionado: http://www.businessweek.com/innovate/content/jan2010/id20100120_303529.htm)
“Design não é sobre aparência. É sobre storytelling. O teste de um design é a resposta no cérebro de um usuário e as ações que ele toma”.
“Em uma Startup, há duas coisas que o empreendedor precisa trabalhar para otimizar: satisfação/felicidade do usuário e valor de negócio.”
“É melhor obter dos usuários uma reação extrema de amor ou ódio do que uma reação de indiferença. É mais fácil iterar sobre o ódio do que sobre a indiferença. No início, busque amplificar a magnitude dessa reação.”

Amor ou odio sobre o produto


“Uma boa parte do Design pode ser testada sem a necessidade de produção de código (palavras, imagens, call-to-actions, etc.)”
Lean Design significa buscar descobrir e testar a reação do seu produto nos usuários, e tentar descobrir mais e melhores formas de converter essa reação em felicidade do usuário ou valor de negócio.”


Pergunta para os painelistas: ” O que é Design?”


Andrew Chen
“Design é aplicar ao produto um conceito sobre o que você precisa fazer dado o seu objetivo de negócio no momento, mantendo uma User Experience consistente ao longo do produto”.


Rashmi Sinha
“Design é a maneira como você expressa sua visão de negócio. Por isso é difícil saber a diferença entre ótimo e  péssimo design (ex. eBay e Craigslist têm um design ruim?). Métricas são a maneira de mensurar se o Design está funcionando, ou seja, se você está caminhando em direção à sua visão de negócio”.
“Design Visual muitas vezes pode ser bem simples ou até ruim”.
“Otimização para uma métrica local às vezes pode causar danos à experiência geral do produto.”


Siqi Chen
“Quotando Steve Jobs: “Design is not about how something looks, but how something works.”"
“Métricas são muito importantes, mas não é possível criar uma ótima experiência de usuário (prazer, entretenimento, etc.) apenas com dados. No final, User Experience também é uma arte.”
“A hipótese inicial tem que ser criativa. Já a prova é analítica. Use métricas para comprovar suas hipóteses”.
“Métricas são excelentes para testar coisas que são tanto fáceis quanto rápidas de se mensurar. Para se chegar a outras coisas, a abordagem deve ser necessariamente através de bom Design.”
“Basicamente, não dá para fazer Split-Tests em qualquer coisa que dure mais de uma semana, a não ser que o seu produto não mude toda semana, o que já é uma má-ideia por si só.”


(vídeo complementar)



Andrew Chen
“Em uma Startup, você tem hipóteses em diferentes níveis do negócio. Mesmo que testes quantitativos sejam excelentes para várias situações, cuidado para não querer usá-los para tudo.”


Dave McClure
“Analytics e métricas podem te levar a um ponto máximo local. A criatividade tem um papel importante em ajudar a descobrir outros pontos de máximo não-locais.”


Laura Klein
“Há uma diferença entre Design de Interação e Design Visual. Design de interação tem a ver com fazer um produto que o usuário consiga entender e usar. Design Visual é para fazer um produto bonito. Ambos funcionam melhor juntos”.
“Foque no Design de Interação antes. Deixe o produto bonito depois. Ande sempre na direção de fazer o produto ficar mais fácil de ser usado.”


Andrew Chen
“Para muitas Startups Web, a otimização para o usuário vem antes da otimização para valor de negócio. Nesses casos, o Minimum Viable Product (MVP) toma a forma de Minimum Desirable Product (MDP).”
(artigo relacionado: http://andrewchenblog.com/2009/12/07/minimum-desirable-product/)

Minimum Desirable Product



“No início, a questão principal para o empreendedor é: Quanto de valor eu consigo gerar para as pessoas?. Otimização vem depois disso.”
“O que fazer primeiro: MVP, MDP ou MFP? Depende do tipo de negócio e dos objetivos do empreendedor.”


Laura Klein
“Coisas artísticas podem ser “mensuradas” qualitativamente. Use e abuse de mockups para testar a reação dos usuários. Coloque-os na frente das pessoas e assista o seu uso. Veja o que eles gostam e não gostam, no que eles reagem e no que eles não reagem. Tente entender os porquês depois.”
“Faça com o que o seu loop de feedback tenha tanto feedback qualitativo quanto quantitativo.”


Siqi Chen
“Trabalhe de forma obcecada para melhorar a experiência dos primeiros 5 minutos dos novos usuários. É isso que define se eles voltam ou não ao produto.”


Dave McClure
Falando sobre experiências de Design e Marketing com o Mint.com
“Eles estavam “atrasados” no mercado. Tinham ainda três meses para ter uma versão aceitável do produto e os concorrentes já tinham lançado. O que fizemos:
- Criamos um blog e começamos a criar conteúdo próprios ou de autores convidados sobre o assunto Gestão Financeira Pessoal.
- Muitos testes com links patrocinados (SEM) e Landing Pages. Os dados coletados serviam para realimentar o braço de produção de conteúdo.
Resultado:
- Mesmo antes do lançamento do produto eles já estavam com um ranking muito melhor do que os concorrentes nos termos de busca mais importantes.
- Mais de 10.000 usuários cadastrados para serem beta-testers antes do produto entrar em Beta. ”




Pergunta sobre testes com usuários de diferentes perfis:


Laura Klein
“Separar os usuários em diferentes perfis para testes qualitativos e quantitativos tem uma importância muito grande nas definições do marketing: segmentação, mensagem, etc.
Após um certo tempo, já é possível começar a “prever” quem vai gostar do produto e porque, e aí a geração de demanda se torna muito mais efetiva.”




Pergunta sobre o papel dos Designers e sua integração com o time de desenvolvimento


Laura Klein
Os designers têm que estar completamente integrados com a equipe de programação.


Dave McClure
Designers devem saber sobre qual é o objetivo (no nível tático ou de negócio) e trabalhar para alcançá-lo junto com a equipe.


Andrew Chen
De uma forma geral, a grande maioria dos desenvolvedores já “abraçaram” a ideia do Desenvolvimento Ágil, mas muitos designers – especialmente os provenientes de agências – ainda não. Eles tendem a guardar o trabalho e só mostrá-lo quando sentem que está muito bom. Isso é extremamente prejudicial em uma Startup.


Rashmi Sinha
“Nós só contratamos pessoas que já fizeram Design para produtos Web e estão acostumadas com os ciclos curtos de desenvolvimento. Garanta que eles saibam da parte técnica o suficiente para conseguirem conversar e interagir bem diretamente com os engenheiros/programadores.”




Observações finais do Dave McClure
“Quando você está começando sua Startup, o maior risco é de que os usuários não dêem a mínima para o seu produto. É por isso que é melhor buscar a otimização para uma reação de extremos – amor ou ódio.”
“Coloque o produto no ar e comece a iterar o quanto antes. Não se preocupe com a ideia de que “a primeira impressão é a que fica”. Mesmo que a experiência dos primeiros usuários seja ruim, a impressão deles sobre o produto não é irreversível, e  ainda assim eles representam uma parcela minúscula do público total potencial do produto.

Segue abaixo o video do painel:



]]>
http://www.manualdastartup.com.br/blog/design-vs-metricas-notas-do-painel-da-sllconf/feed/ 3
Continuous Deployment em uma Lean Startup – notas da palestra do Ash Maurya na SLLConf http://www.manualdastartup.com.br/blog/continuous-deployment-em-uma-lean-startup-notas-da-palestra-do-ash-maurya-na-sllconf/ http://www.manualdastartup.com.br/blog/continuous-deployment-em-uma-lean-startup-notas-da-palestra-do-ash-maurya-na-sllconf/#comments Fri, 07 May 2010 14:18:57 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=313

Uma dos estudos de caso da SLLConf que eu esperava bastante era o do Ash Maurya, da WiredReach. Ash escreve ótimos posts em seu blog,  especialmente sobre práticas e aprendizados específicos da aplicação dos conceitos de Customer Development e Lean Startup no mais novo produto da sua empresa, chamado CloudFire.

Quando assisti ao vivo, achei que a apresentação ficou muito cheia, e consequentemente, corrida demais. Já quando vi pela segunda vez com mais calma, pude perceber uma série de ótimos insights escondidos nas entrelinhas dos slides. Faço a seguir o resumo e deixo no final o vídeo e os slides da apresentação.

Como maximizar o progresso em uma Lean Startup?

Ash começou a palestra relembrando a definição do Eric Ries sobre progresso em uma Startup: Aprendizado Validado sobre Clientes. Ou seja, para maximizar o progresso, temos que buscar maximizar o aprendizado ao longo do processo de desenvolvimento.

O problema é que muitas vezes o desenvolvimento do produto acaba “atrapalhando” o aprendizado. A figura abaixo mostra como isso acontece quando usamos processos tradicionais de desenvolvimento.

Onde ocorre o Aprendizado no processo tradicional de desenvolvimento

Onde ocorre o Aprendizado no processo tradicional de desenvolvimento

A ideia central do Continuous Deployment é minimizar o tempo gasto na parte intermediária deste ciclo, e consequentemente, aumentar a quantidade de aprendizado ao longo do processo.

Continuous Deployment diminuindo o tempo no ciclo de desenvolvimento

Continuous Deployment diminuindo o tempo no ciclo de desenvolvimento

O Antes e Depois da Aplicação de Continuous Deployment na WiredReach

Antes: Ciclos de desenvolvimento de duas semanas
Depois: Múltiplos releases todo dia

Antes: Área comum (centralizada) de testes pré-produção
Depois: Sandboxes individuais, possibilitando escalar a infraestrutura de desenvolvimento horizontalmente

Antes: Releases eram “eventos de um dia inteiro”
Depois: Releases não são “eventos”.
(Obs. Quando os releases vão para o ar, eles monitoram as métricas por algum tempo e revertem caso alguma coisa ruim aconteça. Há medidas automáticas e manuais para essa reversão.)

Antes: Tamanho médio de um Release – centenas de linhas de código
Depois: Tamanho médio de um Release – menos de 25 linhas de código

Antes: Mais Releases de emergência
Depois: Menos “apagar incêndio”

Antes: “Dias de Programação” vs. “Dias de Clientes” (atividades de Customer Development)
Depois: “Dias de Programação” E “Dias de Clientes” juntos
(Obs. Ash mencionou o artigo do Paul Graham: Maker´s Schedule, Manager´s Schedule.  Ele concentra suas atividades de programação nas horas iniciais da manhã, enquanto deixa as atividades de clientes e marketing para mais tarde. Para mais sobre esse assunto, recomendo a leitura desse post dele.)


Dicas para começar a implementar Continous Deployment

- A coisa mais importante: Dividir a programação em lotes muito pequenos (no caso dele, esse tamanho é definido como o resultado de 2 horas de programação);

- Fazer antes as modificações que não envolvam a interface com o usuário (banco de dados, APIs, etc.), diminuindo o risco geral de integração;

- Não tentar alcançar 100% de automação desde o início. Fazer o deploy manualmente primeiro, e depois ver o que vale a pena automatizar. Isso também ajuda a estabelecer confiança aos poucos na parte automática do processo;

- Monitorar o tempo do ciclo de Release;

- Esteja pronto para “parar a linha de produção” em caso de falha nos testes. Não subestime o fato de que os testes estão falhando, já que em pouco tempo eles serão a única linha de defesa do sistema;

- Construir, devagar e incrementalmente, um Cluster Immune System. (sobre isso, recomendo a leitura desse artigo do Eric Ries no Venture Hacks sobre Five Why´s e Immune System)

Como construir as Funcionalidades

Ash lembrou que Continuous Deployment ajuda na tarefa de diminuir o tempo em que uma funcionalidade é construída, mas não diz nada sobre quais são as funcionalidades certas para entrar em desenvolvimento. (o que lembra a proposição do Kent Beck para inverter a ordem do Loop da Startup para Learn->Measure->Build).

Para isso, na WiredReach eles criaram duas regras simples:

Regra #1: Não “empurrar funcionalidades”
Para isso, 20% do esforço é aplicado na construção de novas funcionalidades, enquanto 80% do esforço vai para as melhorias das funcionalidades atuais. A demanda pelas novas funcionalidades deve ser validada por atividades de Customer Discovery.

Regra #2: Restringir o número de funcionalidades que entra na fila
- Novas funcionalidades não podem ser desenvolvidas sem que as funcionalidades anteriores possam ser validadas.
- Para entrar no Backlog, a funcionalidade deve ser pedida por mais de um cliente. Isso aumenta a resistência para entrar uma nova feature no software (ajudando a regra #1) e evita que se faça customizações para clientes específicos, atividade que não escala e ainda tem o risco do efeito “colcha de retalhos”.

Como validar uma Funcionalidade?

Fila de desenvolvimento de funcionalidades

Fila de desenvolvimento de funcionalidades

Depois de desenvolvida, é importante validar a funcionalidade, ou seja, saber responder se ela atendeu de fato o problema que o cliente tinha. Especialmente quando não se tem uma massa de usuários muito grande, a validação Qualitativa (conversa com o cliente) é mais importante do que a Quantitativa (métricas).

Para Validação Qualitativa, Ash sugere que se contate os clientes que pediram a funcionalidade e disponibilize-a só para eles, coletando feedback depois do uso. As duas perguntas que ele procura responder são: Essa feature funciona de forma a resolver o problema que o cliente tinha? E em um nível mais macro, ela afeta a capacidade de fazer ou manter uma venda para ele?

Se não conseguir extrair um sinal positivo para essas perguntas, é importante tentar entender o porquê: se a funcionalidade foi mal implementada ou se o problema foi mal interpretado. No caso desse último, a sugestão do Ash é matar a funcionalidade imediatamente.

Para Validação Quantitativa, ele sugere a combinação do uso de ferramentas como Mixpanel, KISSMetrics e Google Analytics, mas focando mais no macro-efeito da implementação da funcionalidade (resultado nas métricas de negócio) do que nos dados de taxa de Click-Through ou uso da mesma.



Para fechar a apresentação, Ash lembrou que os benefícios do uso de Continuous Deployment são incrementais, e que o quanto antes iniciar a sua prática no desenvolvimento do produto, melhor.

Deixo agora o vídeo e os slides da apresentação:

Continuous Deployment: Startup Lessons Learned

]]>
http://www.manualdastartup.com.br/blog/continuous-deployment-em-uma-lean-startup-notas-da-palestra-do-ash-maurya-na-sllconf/feed/ 0
Revisando o Manifesto Ágil – Kent Beck na SLLConf http://www.manualdastartup.com.br/blog/revisando-o-manifesto-agil-%e2%80%93-notas-da-palestra-do-kent-beck-na-sllconf/ http://www.manualdastartup.com.br/blog/revisando-o-manifesto-agil-%e2%80%93-notas-da-palestra-do-kent-beck-na-sllconf/#comments Tue, 04 May 2010 14:54:54 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=302

Seguindo a série de notas sobre a SLLConf iniciada com a mensagem de abertura do Eric Ries, nesse post vou cobrir as observações sobre a palestra do Kent Beck, que abriu o bloco Build do evento. Também estão no final o vídeo e os slides da palestra.

Para quem é da área de software, Kent Beck não necessita de apresentação. Entre diversas outras coisas memoráveis, ele foi um dos signatários originais do Manifesto Ágil e criador da metodologia Extreme Programming e dos conceitos de Desenvolvimento Orientado a Testes.

Ele iniciou sua palestra comentando o fato de que os conceitos de Lean Startup e a comunidade de prática que se formou em torno do tema foram responsáveis por trazer uma nova “energia” para que ele continue criando negócios através da sua capacidade de desenvolver software. Na sequência, ele fez uma série de análises que geraram muita discussão e comentários na blogosfera. Abaixo faço o resumo dos principais conceitos:

Encontrando o “ponto da coceira”

Essa foi uma analogia bem-humorada entre as Startups e uma experiência que ele teve com uma das cabras de sua criação. A estória é a de que um dia ele estava brincando com uma das cabras, fazendo um movimento de cócegas com os dedos ao longo do corpo da cabra, que por sua vez não reagia àquele movimento. Em um determinado momento, Kent achou um ponto (itchy spot) onde, com o mesmo movimento nos dedos, a cabra teve uma reação desproporcional às cócegas.

Com as Startups, a coisa é parecida. Você tenta uma, duas, três, várias vezes, e recebe quase nada de resposta do mercado. De repente, nesse processo iterativo, a Startup encontra algo que tem uma demanda e uma alavancagem desproporcional ao resto. Achar esse “ponto da coceira” requer timing, sorte, mas principalmente, muitas “cócegas”.

É aí que entra uma das ideias principais das Lean Startups: aumentar a velocidade de iteração para garantir que se ache esse “itchy spot” o quanto antes, maximizando as chances de sucesso do empreendimento.

O princípio de “Pull”

Nas suas apresentações, Eric Ries sempre mostra o Loop Fundamental da Lean Startup, que é composto pelo ciclo Build->Measure->Learn (clique aqui para ver a imagem).

Kent Beck analisou esse loop e percebeu que, se quisermos extrair o máximo de valor de cada iteração, a sequência está na verdade invertida. Ele então propôs que adotássemos algo mais próximo do conceito de “Pull” do Lean Manufacturing, ou seja, começar com uma necessidade concreta (de aprendizado ou demanda dos clientes). Desta forma, o Loop deveria estar na sequência: Learn->Measure->Build.

Loop Learn Measure Build

Loop Learn Measure Build

Kent também escreveu um post explicando melhor sobre essa ideia do Learn->Measure->Build, dando alguns exemplos práticos de como isso altera a maneira de agir.

Essa ideia também se alinha com a forma que os princípios Ágeis são praticados hoje. Segundo ele, as metodologias ágeis por si só trazem bastante micro-eficiências ao processo de desenvolvimento de software, porém se não alinhadas a esse processo maior de aprendizado e Customer Development, perdem macro-eficiências por permitir que se construa coisas que as pessoas não querem ou precisam.

Revisando o Manifesto Ágil

Aproveitando o insight acima, Kent Beck fez uma revisão do Manifesto Ágil aplicado ao contexto das Startups:

Valorizar:

Visão da Equipe e Disciplina mais do que Indivíduos e Interações (e mais do que Processos e Ferramentas);

Aprendizado Validado mais do que Software em Funcionamento (e mais do que Documentação Abrangente);

Descoberta do Cliente mais do que Colaboração com o Cliente (e mais do que Negociação de Contratos);

Iniciar as Mudanças mais do que Responder às Mudanças (e mais do que Seguir um Plano);

Esse post traz mais detalhes sobre esses pontos.

O princípio de “Flow”

Para fechar a palestra, Kent falou sobre o quanto o princípio de “Flow” está alinhado ao de “Pull” para as Startups. A ideia central é que devemos buscar minimizar o tempo total gasto no Loop para cada iteração.

Para o processo de aprendizado, ter “meia-entrega” em menos tempo é mais valioso do que uma entrega completa em mais tempo. Devemos então sempre nos perguntar: Como podemos diminuir o tempo nesse próximo ciclo Build->Measure->Learn para o que queremos aprender? Qual o atalho que podemos tomar ou a redução que podemos fazer no Build?

Ele exemplificou usando um caso próprio de aplicação de um MVP, e brincou: “Not having a customers is a blessing. You can make mistakes all along.”

Deixo também mais dois quotes provocantes que geraram alguns debates interessantes.

“As a developer, you have to realize that the solutions to shortening the cicle might not be the better technicaly.
Sometimes, it´s gonna look like hackery.”

“Good engineering sometimes isn´t good startup engineering. It depends on the Learning you need to create.”

Seguem agora o vídeo e os slides da palestra:

To agility, and beyond…

]]>
http://www.manualdastartup.com.br/blog/revisando-o-manifesto-agil-%e2%80%93-notas-da-palestra-do-kent-beck-na-sllconf/feed/ 5
Os mitos das Lean Startups – abertura da SLLConf http://www.manualdastartup.com.br/blog/notas-da-startup-lessons-learned-conference-abertura/ http://www.manualdastartup.com.br/blog/notas-da-startup-lessons-learned-conference-abertura/#comments Mon, 26 Apr 2010 19:50:41 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=285

Nesta última sexta-feira, aconteceu em San Francisco a Startup Lessons Learned Conference, primeiro grande encontro dedicado a discutir os conceitos e técnicas das Lean Startups, tais como Customer Development, Minimum Viable Product (MVP), Pivôs, Métricas, Continuous Deployment, entre outros. O evento teve um conteúdo excelente, composto por palestras, estudos de casos e painéis diversos. Steve Blank batizou a conferência de Woodstock para empreendedores, e até veículos tradicionais como o New York Times mostraram como a natureza da criação e desenvolvimento de Startups está mudando bruscamente com a ajuda deste movimento. Aqui no Brasil, muita gente assistiu o evento presencialmente nos simulcasts em Floripa ou BH, ou até diretamente via streaming Web que o pessoal da organização resolveu abrir para todos no último momento devido à forte demanda.

Para aproveitar um pouco melhor a riqueza das apresentações da conferência, vou fazer aqui no blog uma sequência de posts com o resumo, observações e indicações de recursos complementares sobre os diferentes assuntos discutidos.

Começando a série, deixo abaixo os highlights e vídeo da mensagem de abertura pelo Eric Ries, organizador do evento e um dos principais ícones do movimento das Lean Startups.

Notas:

- Eric Ries ressaltou que a conferência se insere em um contexto onde a forma de se pensar o empreendedorismo tecnológico está mudando mundialmente, mas que ainda estamos nos primeiros passos deste grande processo.

- Startups são iniciativas designadas a entregar novos produtos ou serviços sob condições de extrema incerteza. As técnicas de gestão tradicionais (estilo MBAs) não são adequadas para lidar com essas condições, e por isso fracassam quando aplicadas ao contexto empreendedor.

- O significado do termo Lean da Lean Startup remete a um dos princípios fundamentais da revolução do Lean Manufacturing, que define que dentro da empresa é preciso separar quais são as atividades geradoras de valor para o cliente de todas as outras atividades que seriam desperdício. Em uma Startup, é ainda mais difícil do que na indústria identificar quais atividades são de fato geradoras de valor, já que tanto o Problema (necessidade do cliente) quanto a Solução (produto) são desconhecidos. Por isso o progresso em uma Startup deve ser definido por Aprendizado Validado sobre os Clientes.

- O ciclo de Feedback de uma Startup é composto pelos passos Build->Measure->Learn. Quanto menor o tempo gasto neste ciclo, maior o aprendizado e consequentemente, maiores as chances de sucesso do empreendimento.

Loop de Aprendizado da Startup

Loop de Aprendizado da Startup

- O crescimento do movimento de Lean Startups tem gerado algumas críticas baseadas em má-interpretações dos conceitos por algumas pessoas. Ele entende que se formaram quatro mitos sobre as Lean Startups:

Mito #1 – Lean significa barato.
Mito #2- Os conceitos de Lean Startups servem apenas para empresas Web 2.0.
Mito #3- Lean Startups são pequenas empresas financiadas com capital próprio (bootstrapped).
Mito #4- Em uma Lean Startup, a Visão do empreendedor é substituída por Dados e feedback do cliente.

Especialmente sobre este último, o objetivo da Lean Startup é justamente validar os elementos da Visão que são verdadeiros, e eliminar aqueles que não são. Quando se fala “Fail Fast”, isso não se refere às empresas, mas sim às ideias ruins dentro de uma Startup.

Por fim, Eric Ries falou sobre a rápida evolução do movimento neste último ano, algo que também comentei no post pré-conferência.

Seguem abaixo o vídeo e os slides da apresentação:

]]>
http://www.manualdastartup.com.br/blog/notas-da-startup-lessons-learned-conference-abertura/feed/ 6