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 » aprendizado 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 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
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