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 » Apresentações 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 Como saber se um conselho é adequado para a sua Startup http://www.manualdastartup.com.br/blog/como-saber-se-um-conselho-e-adequado-para-a-sua-startup/ http://www.manualdastartup.com.br/blog/como-saber-se-um-conselho-e-adequado-para-a-sua-startup/#comments Fri, 17 Jun 2011 03:49:14 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=639

Recentemente escutei o Andrew Warner do Mixergy - que já fez mais 300 entrevistas com empreendedores bem sucedidos por lá – dizer que a coisa que mais chamou a atenção dele nesse tempo todo foi descobrir que não existe um padrão claro para o sucesso. Pessoas diferentes com negócios diferentes podem ter práticas radicalmente diferentes umas das outras e ainda assim serem bem sucedidas. Isso sem contar que a própria definição de sucesso também é extremamente relativa.

Por isso é tão difícil interpretar e filtrar toda a quantidade de informação e conselhos – muitas vezes contraditórios – que recebemos todos os dias via Twitter, RSS, livros, podcasts, etc.

Fiz toda essa introdução para adiantar o assunto desta ótima apresentação do Jason Cohen na Business of Software Conference que compartilho abaixo.

No vídeo ele conta três boas histórias que ilustram passagens na sua carreira onde ele falhou tentando aplicar os conselhos “convencionais” para alguns problemas específicos, e foi só depois de seguir o seu feeling e ir ao contrário deste conselhos que ele conseguiu virar o jogo.

Deixo o vídeo a seguir, e logo abaixo algumas citações que achei relevante.

- Você define as regras;

- Todo conselho vem com um contexto;

- Nunca diga: “Eu não consigo ser__ _______” (ex. vendedor, programador, marketeiro, etc.)

- Confie no seu instinto, mesmo que inexperiente;

- Nunca faça as coisas só porque a convenção diz que  ”é assim que tem que ser feito”;

- Pensar e agir de uma forma diferente pode ser a sua vantagem competitiva;

- Nenhuma regra ou conselho vai fazer você ser bem ou mal sucedido por si só. Portanto, pegue o que soar mais natural para a pessoa que você é;

- ”Less reading, less worrying, more doing.”

]]>
http://www.manualdastartup.com.br/blog/como-saber-se-um-conselho-e-adequado-para-a-sua-startup/feed/ 4
Mike Maples falando sobre a importância do pivô http://www.manualdastartup.com.br/blog/mike-maples-falando-sobre-a-importancia-do-pivo/ http://www.manualdastartup.com.br/blog/mike-maples-falando-sobre-a-importancia-do-pivo/#comments Fri, 05 Nov 2010 11:52:51 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=455

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:

]]>
http://www.manualdastartup.com.br/blog/mike-maples-falando-sobre-a-importancia-do-pivo/feed/ 0
Repensando a formação dos empreendedores de tecnologia http://www.manualdastartup.com.br/blog/repensando-a-formacao-dos-empreendedores-de-tecnologia/ http://www.manualdastartup.com.br/blog/repensando-a-formacao-dos-empreendedores-de-tecnologia/#comments Thu, 09 Sep 2010 13:01:54 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=434

Uma Startup de tecnologia é um “bicho” completamente diferente de uma empresa tradicional. Por razões óbvias as Startups não têm as mesmas características de uma grande empresa (recursos, processos, hierarquia, etc.), mas também diferem muito de uma Pequena ou Média Empresa tradicional (franquias, concessionárias, padarias, consultórios, agências, etc.). Comparado com as PMEs, as Startups de tecnologia possuem um grau de risco muito mais elevado, mas por outro lado também têm potencial de escalar muito além de um crescimento linear. Porém, especialmente aqui no Brasil, há um vácuo na formação desse tipo de empreendedor.

As escolas e cursos de administração tradicionais são capazes de formar bem o gestor de nível médio de grandes empresas. Todo o contexto dos cursos (graduação, pós, MBA, etc.) das principais universidades é orientado para “formar o aluno para o mercado de trabalho”. Além das instituições formais e diversos eventos, publicações como a HSM ou a Exame também são voltadas para auxiliar bastante nessa formação de gestores de grandes empresas.

Já para as PMEs, apesar de faltarem universidades com bons programas de formação de empreendedores, há instituições que fazem um ótimo trabalho neste campo, tais como o SEBRAE e a Endeavor. Também existem publicações voltadas para esse público, como a Exame PME, PEGN, entre outros. O mesmo acontece com os livros sobre empreendedorismo, que estão bem voltados para esse tipo de empresa. Até o empreendedorismo social está coberto com organizações como a Artemisia, Aliança Empreendedora e The Hub.

No parágrafo anterior, não foi por acaso que apontei os links para os blogs de algumas dessas organizações. Nessa seara de empreendedorismo, os blogs já fazem um papel muito importante na formação do empreendedor. Além desses, há outros ótimos como o Saia do Lugar, Blog do Empreendedor, Miguel Cavalcanti, ResultsOn, Fabio SeixasLeo Kuba, Pierre SchurmannInsistimento, Marcelo ToledoTribo do MouseBizRevolution, entre outros. Muitos desses blogs cobrem tecnologia e Web de diversas formas, mas não são necessariamente orientados para discutir empreendedorismo de base tecnológica.

E as Startups de Tecnologia?

Como eu disse acima, Startups de tecnologia (principalmente Web-based) são um “bicho” diferente, e por isso também exigem técnicas, recursos, equipe, processos e investimento de natureza diferente. É nesse campo que acredito que temos muito a andar ainda.

Primeiro, as instituições formais (universidades) não estão nem um pouco preparadas para ensinar isso. Ainda próximo do ambiente acadêmico, as incubadoras de empresas de tecnologia funcionam muito mais como apoio básico para Startups – escritório mais barato, ajuda legal, contábil, de RH, etc. – do que para ensinar e fazer mentoring para empreendedores.

Há algumas iniciativas esparsas que ajudam no aprendizado e motivação dos empreendedores de tecnologia, como por exemplo o Startup Meetup, o Desafio Brasil, o BizSpark e o Seed Forum FINEP. Ainda nas instituições, ao contrário do que acontece nos EUA, os Angels e fundos de Seed Money aqui no Brasil ainda têm um papel bastante tímido na disseminação de conhecimento (confira a lista deles aqui nesse post da Aceleradora). Já a Aceleradora é uma iniciativa diferenciada, tanto pelo seu trabalho com as Startups selecionadas quanto pelo conteúdo do seu blog.

E por falar em blogs, é aqui que o empreendedor Web brasileiro consegue aprender alguma coisa de verdade, mas em geral tem que recorrer aos blogs e livros de empreendedores/investidores dos EUA. Sem dúvida é possível aprender muito com eles, mas há momentos em que as práticas não se aplicam ao contexto específico do Brasil. Por aqui há bons blogs de cobertura e análise da indústria, como ReadWriteWeb Brasil, Habilidade 20%Startupi (fora alguns regionais, como o TISC) e outros bons (ainda que um pouco parados), como o Acelerando a Inovação e Aprendendo Empreendendo. Uma das minhas intenções aqui no Manual da Startup é ajudar nessa tarefa de formação.

O problema é que, pela natureza e grande diversidade dos blogs, é muito difícil aprender de uma maneira mais sólida, mais profunda. Os blogs são ótimas fontes de dicas, práticas e até motivação pessoal, mas falta um modelo (framework) para encaixar essas informações e ajudar o empreendedor a tomar decisões, sabendo o que priorizar a cada momento e identificar o que é progresso em cada fase da Startup.

Apesar do grande degrau entre o Brasil e EUA, essa falta de modelo não é exclusividade nossa. Criar esse framework de forma conjunta e inseri-lo nas instituições de ensino (americanas, no caso) é o desafio que o Steve Blank assumiu. O vídeo abaixo – último da série sobre a Startup Lessons Learned Conference – é indispensável para entender direito esse desafio de formação de empreendedores de Startups de tecnologia.

Steve fala sobre como esse movimento de Lean Startups está ajudando a criar a primeira grande “metodologia” para empreendedorismo em Startups de tecnologia, baseada nos conceitos de Customer Development e apimentada com práticas e experiências que estão sendo compartilhadas de forma bastante rápida e transparente por diversos empreendedores. Em paralelo a isso, incubadoras 2.0 como a YCombinator e TechStars têm feito um ótimo trabalho na parte de mentoring, mas sem uma grande preocupação com processos. A junção dessas duas coisas seria um ótimo passo mais escalável nessa formação de empreendedores, o que segundo Steve após algum tempo seria seguido por instituições como Stanford, Harvard, etc.

Acredito que podemos fazer coisas bem semelhantes aqui no Brasil. Ideias? ;)

Para fechar, deixo o vídeo e os slides da palestra dele abaixo:


Watch live video from Startup Lessons Learned on Justin.tv

]]>
http://www.manualdastartup.com.br/blog/repensando-a-formacao-dos-empreendedores-de-tecnologia/feed/ 21
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
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 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