MVP – Quando construir, medir, aprender não é apenas jogar as coisas contra a parede
Publicados: 2017-05-29E vendo se eles funcionam
Sempre fico surpreso quando os críticos reclamam que a abordagem Build, Measure, Learn da Lean Startup nada mais é do que “jogar produtos incompletos fora do prédio para ver se funcionam”.
Infelizmente, o diagrama Build, Measure, Learn é a causa dessa confusão. À primeira vista, parece um processo de mira pronta para o fogo.
É hora de atualizar Build, Measure, Learn para o que agora sabemos ser a melhor maneira de construir startups Lean.
Aqui está como.
Construir, medir, aprender soa bem simples. Construa um produto, coloque-o no mundo real, meça as reações e comportamentos dos clientes, aprenda com isso e use o que você aprendeu para construir algo melhor. Repita, aprendendo se deve iterar, dinamizar ou reiniciar até ter algo que os clientes adoram .
Desenvolvimento de Cachoeira
Embora pareça simples , a abordagem Build Measure Learn para o desenvolvimento de produtos é uma melhoria radical em relação ao modelo Waterfall tradicional usado ao longo do século 20 para construir e enviar produtos. Naquela época, um empresário usava um processo de desenvolvimento de produtos em série que prosseguia passo a passo com pouco ou nenhum feedback do cliente. Os fundadores presumiram que entendiam os problemas/necessidades do cliente, escreveram documentos de requisitos de engenharia, projetaram o produto, implementaram /construíram o hardware/software, verificaram que funcionava testando -o e, em seguida, apresentaram o produto aos clientes em um lançamento formal chamado primeiro navio do cliente .
O desenvolvimento em cascata foi sobre a execução do documento de requisitos. Embora as primeiras versões do produto fossem compartilhadas com os clientes nos testes Alfa e Beta, o objetivo do acesso antecipado do cliente ao produto era descobrir bugs e não fornecer feedback sobre recursos ou usabilidade. Somente depois de enviar e tentar vender o produto, uma startup ouviria algum feedback substantivo dos clientes. E muitas vezes, após meses ou mesmo anos de desenvolvimento, os empreendedores aprenderam da maneira mais difícil que os clientes não estavam comprando seu produto porque não precisavam ou não queriam a maioria de seus recursos .
Muitas vezes, as empresas precisavam de três tentativas para acertar os produtos. A versão 1 foi construída sem feedback do cliente, e antes que a versão 1 estivesse completa, o trabalho já havia começado na versão 2, então demorou até a versão 3 antes que o cliente fosse realmente ouvido (por exemplo, Microsoft Windows 3.0)
As melhores práticas em desenvolvimento de software começaram a migrar para o desenvolvimento ágil no início dos anos 2000. Essa metodologia melhorou em cascata ao construir software de forma iterativa e envolver o cliente. Mas faltava uma estrutura para testar toda a comercialização hipóteses fora do edifício. Com o Agile, você pode acabar satisfazendo todos os recursos solicitados por um cliente e ainda sair do negócio.
Em seguida, veio o foco Build Measure Learn da Lean Startup.
Construir Medir Aprendizagem
O objetivo do Build-Measure-Learn não é construir um produto final para enviar ou mesmo construir um protótipo de um produto, mas maximizar o aprendizado por meio de engenharia incremental e iterativa. (Aprender pode ser sobre características do produto, necessidades do cliente, preço certo e canal de distribuição, etc.) A etapa de “construção” refere-se à construção de um produto mínimo viável (um MVP). menos recursos. Pelo contrário, é a coisa mais simples que você pode mostrar aos clientes para obter o máximo de aprendizado naquele momento . No início de uma inicialização, um MVP pode ser simplesmente um slide do PowerPoint, wireframe, modelo de argila, conjunto de dados de amostra, etc. Cada vez que você cria um MVP, você também define o que está tentando testar/ medir . Mais tarde, à medida que se aprende mais, os MVPs passam de baixa fidelidade para alta fidelidade, mas o objetivo continua sendo maximizar o aprendizado e não construir um protótipo beta/completo do produto.
Recomendado para você:
Como o Metaverse transformará a indústria automobilística indiana
O que significa a provisão antilucratividade para startups indianas?
Como as startups de Edtech estão ajudando a qualificação da força de trabalho da Índia e se preparando para o futuro
Ações de tecnologia da nova era esta semana: os problemas do Zomato continuam, EaseMyTrip publica...
Startups indianas pegam atalhos em busca de financiamento
Plataforma de marketing digital Logicserve Bags Financiamento de INR 80 Cr, renomeia como LS Dig...
Uma grande melhoria em relação ao desenvolvimento Waterfall, o Build Measure Learn permite que as startups sejam rápidas, ágeis e eficientes.
O diagrama de três círculos do Build Measure Learn é uma boa aproximação do processo. Infelizmente, usar a palavra “construir” primeiro muitas vezes confunde as pessoas. O diagrama parece implicar construir coisas e jogá-las fora do prédio. Uma versão mais detalhada do diagrama Build Measure Learn ajuda a esclarecer o significado adicionando mais três elementos: Ideas -Build- Code -Measure- Data -Learn.
A versão em cinco partes do diagrama Build Measure Learn nos ajuda a ver que a real intenção da construção é testar “ideias” – não apenas construir cegamente sem um objetivo. O círculo rotulado como “código” poderia facilmente ser rotulado como “construir hardware” ou “construir genoma artificial”. O círculo rotulado como “dados” indica que, depois de medirmos nossos experimentos, usaremos os dados para refinar ainda mais nosso aprendizado. E o novo aprendizado influenciará nossas próximas ideias. Assim, podemos ver que o objetivo do Build-Measure-Learn não é apenas construir coisas, o objetivo é construir coisas para validar ou invalidar a ideia inicial.
O foco em testar ideias específicas contraria a preocupação de que construir-medir-aprender é apenas jogar as coisas contra a parede e ver se elas funcionam.
Mas ainda não é bom o suficiente. Agora podemos fazer melhor.
Comece com hipóteses
O que o Build-Measure-Learn perde é que novos empreendimentos (tanto startups quanto novas ideias em empresas existentes) não começam com “ideias”, eles começam com hipóteses (uma palavra chique para suposições). É importante entender que as palavras “ ideia” e “hipóteses” significam duas coisas muito diferentes. Para a maioria dos inovadores, a palavra “ideia” evoca um insight que requer imediatamente um plano para torná-lo realidade. Em contraste, uma hipótese significa que temos um palpite que requer experimentação e dados para validar ou invalidar .
Essas hipóteses abrangem a gama de quem é o(s) cliente(s), qual é a proposta de valor (recursos do produto/serviço), preços, canal de distribuição e criação de demanda (aquisição de clientes, ativação, retenção, etc.)
Que a startup enxuta comece com o reconhecimento de que sua ideia é simplesmente uma série de hipóteses não testadas é uma grande ideia . É uma grande ideia porque o que você constrói precisa corresponder à hipótese que você quer testar.
O produto mínimo viável que você precisará construir para encontrar os clientes certos é diferente do produto mínimo viável que você precisa para testar preços, que é diferente de um MVP que você construiria para testar recursos específicos do produto. E todas essas hipóteses (e produtos viáveis mínimos) mudam com o tempo à medida que você aprende mais. Então , em vez de Construir-Medir-Aprender, o diagrama para construir produtos viáveis mínimos em uma startup enxuta se parece com Hipóteses – Experimentos – Testes – Insights.
Gerando Hipóteses
Usando este novo diagrama de Hipóteses – Experimentos – Testes – Insights , a pergunta se torna: “Quais hipóteses devo testar?” Felizmente, a tela do modelo de negócios de Alexander Osterwalder apresenta uma visão geral dos nove componentes de um negócio em uma página. Eles são:
- Proposta de valor, produto/serviço que a empresa oferece (juntamente com seus benefícios para os clientes).
- Segmentos de clientes, como usuários e pagadores ou mães ou adolescentes.
- Canais de distribuição para alcançar os clientes e oferecer a eles a proposta de valor
- Relacionamento com o cliente para criar demanda.
- Fluxos de receita gerados pela(s) proposta(s) de valor.
- Atividades necessárias para implementar o modelo de negócios.
- Recursos necessários para viabilizar as atividades.
- Parceiros terceiros necessários para viabilizar as atividades.
- Estrutura de custos resultante do modelo de negócio.
E isso nos leva à definição de startup: uma startup é uma organização temporária projetada para buscar um modelo de negócios repetível e escalável .
Testando hipóteses
E uma vez que essas hipóteses preenchem o Business Model Canvas, como um empreendedor faz para testá-las? Se você é um cientista, a resposta é fácil: você faz experimentos . O mesmo vale para uma startup enxuta. (A National Science Foundation descreveu a classe Lean LaunchPad como o método científico para o empreendedorismo.)
O processo de Desenvolvimento de Clientes é uma metodologia simples para levantar hipóteses de novos empreendimentos e sair do prédio para testá-las. A descoberta do cliente captura a visão dos fundadores e a transforma em uma série de hipóteses de modelo de negócios. Em seguida, desenvolve uma série de experimentos para testar as reações dos clientes a essas hipóteses e transformá-las em fatos. Os experimentos podem ser uma série de perguntas que você faz aos clientes, mas na maioria das vezes um produto mínimo viável para ajudar os clientes em potencial a entender sua solução acompanha as perguntas.
Então, outra grande ideia aqui é que as startups não estão construindo produtos viáveis mínimos para construir um protótipo. Eles estão construindo produtos mínimos viáveis para aprender o máximo que podem .
Finalmente, o objetivo de projetar esses experimentos e produtos viáveis mínimos não é obter dados. Os dados não são o ponto de extremidade. Qualquer pessoa pode coletar dados. Grupos focais coletam dados. Este não é um grupo focal. O objetivo é obter insights . Todo o objetivo de sair do prédio é informar a visão do fundador . O insight pode vir da análise das respostas dos clientes, mas também pode vir de ignorar os dados ou perceber que o que você está descrevendo é um mercado novo e disruptivo que não existe e que você precisa mudar seus experimentos de medir especificidades para inventar o futuro.
[Esta postagem de Steve Blank apareceu pela primeira vez no site oficial e foi reproduzida com permissão.]