BT

Lean Startup e Business Model Generation na prática: uma análise do primeiro ano de uso

Postado por Fernando de La Riva em 08 Jun 2012 |

No artigo Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups, mostrei uma visão conceitual sobre o que é o entendimento corrente de Lean Startup e o papel do Business Model Generation na validação de modelos de negócios, por meio de técnicas de customer development (CustDev) e os métodos ágeis. O objetivo deste artigo é dar uma visão dinâmica do uso destas ferramentas com base em experiências práticas em casos reais, em três startups de tecnologia durante o ano de 2011.

Antes, porém, lembramos que não pretendemos nos apropriar dessa abordagem, nem concluímos que produzirá ativos de sucesso, uma vez que nenhuma das empresas dos casos estudados obteve sucesso comprovado até o momento (sendo "sucesso comprovado" definido como um faturamento relevante em 12 meses, uma nova rodada de investimentos ou venda).

Estrutura geral do negócio

O caso prático usado como base deste artigo vem da Concrete Solutions, uma empresa de serviços e consultoria global, e de seu Fundo Moonlight, uma unidade de negócios criada pela empresa para investir em startups de tecnologia dentro da própria organização. O processo de desenvolvimento de empresas e produtos digitais em questão é uma evolução de uma implantação de métodos ágeis iniciada em 2007.

Podemos enumerar quatro estágios da iniciativa:

a) Antes do pré-jogo: validação do problema e desenho inicial da solução;

b) Pré-jogo: detalhamento da solução, criação do backlog do produto, definição do Produto Mínimo Viável (MVP), da equipe de trabalho e planejamento de entregas (release plan);

c) Produto Mínimo Viável em execução: desenvolvimento de produto e cliente; hipóteses de negócio em validação;

d) Evolução contínua: Definição de hipóteses de negócio, execução das tarefas de validação e aprendizado, até chegar aos objetivos de negócio da empresa ou o Product Market Fit.

Abaixo detalhamos os quatro estágios.

Antes do Pré-jogo

Podemos dizer que o ciclo de validação do problema que inicia o processo funciona como uma sequência contínua e desordenada de criação de hipóteses fundamentais e estratégias de validação, formadas normalmente por entrevistas com e sem roteiro padronizado.

O objetivo desta sequência é eliminar erros grosseiros e garantir que temos um problema que vale a pena ser resolvido e uma solução viável pela qual um conjunto de clientes esteja disposto a pagar. Outras formas de validação do problema incluem as necessidades "puxadas" por clientes (um pedido feito numa das entrevistas por exemplo e não "empurradas" pelo PO), além das detectadas pelo time de desenvolvimento de negócio ou de operações.

Pré-jogo

O resultado do trabalho de Business Model Generation (BMG) é uma visão clara de qual é o problema a ser resolvido e qual é a visão da solução (proposição única de valor), além de uma visão inicial de modelo de custos e despesas. Este modelo de negócios, representado neste ponto por um Canvas, é elaborado em uma fase de pré-jogo, em que as atividades de desenvolvimento de produto e de desenvolvimento de clientes (customer development, ou CustDev) ainda são feitas de forma indistinta pelo time; ou seja, não há uma divisão formal entre o time de CustDev e o time de desenvolvimento de produtos. Neste ponto, são criados Canvas com as hipóteses fundamentais, que passam por rodadas internas de validação de solução, seguidas de reuniões e entrevistas externas.

Semanticamente, as três abordagens de Canvas (BMG de Osterwalder, Lean LaunchLab, e Lean Canvas de Ash Maurya) são idênticas, pois representam o modelo de negócio em si; isto é, os experimentos, suas tarefas e os critérios de validação. A diferença entre elas está na forma que documentam o trabalho e induzem o processo de validação empírico do modelo.

Tão logo haja uma maturidade mínima, surge a primeira visão de módulos e, finalmente, do backlog do produto. Assim, surge também uma rastreabilidade entre o modelo de negócio e o produto mínimo viável; entre hipótese e funcionalidade. E o mais importante: surge a evidência de validação. A redução do nível de abstração e o aumento da maturidade levam à criação de um plano de entregas e à definição da equipe.

Questões financeiras, planejamento e decisão de "Go no Go"

O modelo de negócios tem ainda as hipóteses de faturamento, que aparecem mais explicitamente no Lean Canvas do Ash Maurya. Estas hipóteses são representadas por análises de sensibilidade e um orçamento (meses de burn rate) aprovado. Os investimentos pontuais, como criação do veículo legal, escritório, equipe comercial e ativos em geral, são gerados à medida que níveis de aprendizado são atingidos.

O ciclo de desenvolvimento de produto e cliente até o MVP

A primeira mudança sobre a mentalidade agilista pura é que o Product Owner é naturalmente o time de CustDev. No caso da primeira geração de empresas que utilizaram este processo nos últimos doze meses, ele é um dos sócio-fundadores. Os ciclos de backlog grooming são precedidos de trabalhos de grooming (otimização) do Canvas. As sessões de planejamento, revisão e retrospectiva têm hoje componentes de informação de:

  • Quais hipóteses ainda estão em aberto (em validação);
  • Quais são os resultados de um determinado experimento;
  • Se o fechamento de hipóteses foi ou não validado;
  • Qual é a prioridade dentre as funcionalidades;
  • Como está a questão das finanças.

O time de Customer Development usa a mesma ferramenta de acompanhamento de oportunidades identificadas pelo time comercial. Esta ferramenta foi alterada para funcionar como backlog, sendo também criado um quadro Kanban para os pares cliente-hipótese. O time de CustDev trabalha com ciclos de uma semana de avaliação, sem planejamento e review. Existem dificuldades em manter o trabalho em andamento sobre controle e a gestão de impedimentos. Por outro lado, há a equipe de desenvolvimento do produto, que atua com Scrum nesta fase.

O Product Owner, ou o time de CustDev, tem o trabalho de comunicar aos sócios e outros envolvidos, as iniciativas em específico e o estado atual da empresa, por meio das revisões. Comunica ainda o que foi aprendido até o momento e se a taxa de progresso atual é suficiente para que negócio chegue em um patamar estável; em outras palavras, se o MVP pronto já pode gerar faturamento ou precisa de uma rodada adicional.

Atingido o MVP, a busca do "product market fit"

A principal mudança é a ampliação do trabalho de CustDev, uma vez que a equipe comercial assume esta função. Qualquer pessoa do desenvolvimento do negócio pode pegar uma oportunidade (lead) representando um experimento ou tarefa de validação de hipótese. Tipicamente, nesta fase o número de funcionalidades diminui e o trabalho da equipe de desenvolvimento de produto deixa de utilizar Scrum para utilizar Kanban. Isso faz com que os lotes se tornem ainda menores e o ciclo de hipóteses, experimentos e funcionalidades sejam criados diretamente.

O time de CustDev continua com ciclos periódicos de uma semana, com uma sessão de planejamento e revisão. A otimização do Canvas e do backlog é feita dentro do ciclo semanal.

Mudar de direção ou continuar, sintomas e processos

Nenhuma das empresas chegou no product market fit até o momento, nem deu sintomas de necessidade radical de pivoting (mudança radical de direção). Entretanto, os ciclos de aprendizados rápidos estão gerando um controle mais firme da taxa de progresso para garantir que se consiga manter o financiamento do negócio até que se atinja o sucesso do produto ou o seu fechamento.

Conclusões e próximas linhas de análise

Podemos considerar ainda baixo o estado de maturidade da implantação de Lean Startup nos times das três empresas analisadas, mas os ciclos de aprendizado têm se mostrado rápidos devido à experiência em Scrum e Kanban. A cultura de metódos empíricos aplicadas ao negócio já é aceita por todos os times envolvidos e e o efeito sobre o papel do PO já é considerado bastante relevante.

Manter a rastreabilidade do Canvas e do backlog é possível, mas trabalhoso, e as ferramentas de documentação de experimentos e hipóteses ainda estão imaturas. As ferramentas para análise de métricas e navegação se mostraram adequadas. Neste momento duas das empresas começam a ter faturamento e clientes relevantes, partindo brevemente para encontrar o seu product market fit, em que teremos um novo grande ciclo de aprendizado relacionado a novas rodadas de investimento e crescimento.


Sobre o autor

Fernando de La Riva (@fdelariva) é Diretor Executivo da Concrete Solutions, Engenheiro de computação pela PUC-RJ, com MBA na Columbia Gruaduate School of Business e mestre pela London Business School; pós-graduado em Gestão Empresarial pela COPPEAD. Atualmente é membro do conselho da iceleres, Fix e Cloudretail, além de mentor do Fundo Moonlight e colunista da Exame.com.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Uso de material para fins acadêmicos by Larri Figueiró

Olá Fernando,

Meu Nome é Larri Ernani Figueiró, sou aluno de administração de empresas na Faculdade Porto-Alegrense FAPA, (graduação final deste ano 2012)
Gostaria de ter a permisão para uso deste material para fins acadêmicos, pois estou escrevendo meu trabalho de conclusão de curso sobre o Business Model Canvas, Lean Startup com Agile.O material poderia enriquecer meu trabalho,
O nome do trabalho até agora esta sendo: Elaboração de um Modelo de Negócios para uma Startup Enxuta que proporcione o Social Commerce.
Lean Startup e Business Model Generation na prática: uma análise do primeiro ano de uso

Grato,
larri_figueiro@hotmail.com
inglestop@gmail.com

Re: Uso de material para fins acadêmicos by Fernando de la Riva

sem problema, é um prazer, me desculpe a demora mas só vi seu questionamento hoje. Por sinal checa também um draft de artigo que estou escrevendo sobre lean innovation, fernandodelariva.tumblr.com/post/34241880151/le...

att

FR

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT