Aceleração e Metodologias

O MVP não é um produto, é um processo!

20/janeiro/2017

O MVP não é um produto, é um processo!

(o título do post é baseado no texto que inspirou este material, o texto da Y Combinator — “A Minimum Viable Product Is Not a Product, It’s a Process”)
Se você entrou nesse post achando que ia ver algo sobre o Most Valuable Player da NFL, infelizmente esse texto não é sobre isso (e se fosse, facilmente seria Aaron Rodgers, embora haja discussão dentro da Wylinka sobre o tema, pois temos os que apostam em Matt Ryan, Brady, Prescott … O editor resolveu cortar esse trecho pois aqui não é lugar para discussão. E é claro que seria Aaron Rodgers.). Esse texto é sobre a criação de uma startup — e sobre como há uma enorme confusão acerca dos processos de validação de um novo negócio, bem como as ferramentas a se utilizar.

Contextualizando: a arrogância é muito cara.

Entendemos que para explicar o conceito de MVP, é preciso compreender suas origens e como o modelo se desenvolveu com Steve Blank e avançou nas propostas de Eric Ries. A motivação central da proposta do MVP veio da experiência do Steve Blank, um professor de grandes universidades americanas (Stanford, Berkeley, NYU e outras), vivenciando a bolha .com e percebendo um padrão nas histórias de fracasso dos empreendedores da bolha: havia uma empolgação enorme em se criar novos negócios, mas uma preocupação mínima em entender o que o usuário queria. O caminho dessa empolgação na bolha era: ideia > plano de negócios > investimento > construção de uma estrutura > investimentos em marketing > produto no mercado. Qual o problema central neste caminho? Um investimento altíssimo antes de ir ao mercado. Em muitos dos casos, ao chegar ao mercado o empreendedor percebia que os clientes não queriam aquilo, e todo investimento ia para o ralo. Deste processo surgiu a premissa de Blank: “um plano de negócio não sobrevive à primeira interação com o mercado”.

A experiência de Blank na bolha .com trouxe o ponto central da tese dos criadores do MVP: a arrogância é muito cara. A arrogância de não querer ouvir os usuários, de querer empurrar um produto goela abaixo sem entender as dores dos mesmos e de não ir para a rua compreender a realidade das pessoas envolvidas foi a geradora de um novo processo para criar startups, o Customer Development. Neste processo o autor traz o contato com o usuário como o primeiro momento, invertendo a lógica antiga de Product Development e caminhando para uma lógica centrada no cliente. Surgia assim os 4 passos para a epifania:

Captura de Tela 2017-01-20 às 10.06.42

A proposta dos quatro passos, que tem como objetivo eliminar a arrogância do empreendedor e se concentrar no usuário, podem ser resumidas na imagem acima — no primeiro momento você vai para a rua descobrir quem é seu cliente (clique aqui para ver um excelente roteiro de entrevista), quais suas dores/problemas e como isso se relaciona com sua solução (problem-solution fit); no segundo momento, o momento do MVP, busca a validação da sua solução com os clientes (product-market fit); o terceiro momento é o de ganho de tração, de crescimento da operação e de desenvolvimento de um motor de vendas e distribuição; o quarto momento é o de organização do processo de escala do negócio e estruturação do negócio. Percebam a oposição do modelo antigo, que estruturava tudo em um plano, levantava investimentos para ter uma estrutura de distribuição e marketing sólidos e somente depois ia para a rua. Com isso surgiu o conceito de startup enxuta, de Eric Ries, um método voltado para eliminar os desperdícios gerados pela arrogância de não buscar entender o usuário da maneira mais econômica, mais eficiente.

As confusões feitas sobre MVP

O conceito de MVP espalhou-se com muita velocidade, e o apelo sexy do conceito de fazer algo mínimo e levar para a rua acabou se tornando uma grande confusão — a ponto de a Y Combinator, a maior aceleradora de startups do mundo, produzir um texto sobre. Sendo o ponto central do livro “Startup Enxuta”, de Eric Ries, ele passou a ser interpretado de diversas maneiras: um protótipo, um pitch, uma apresentação de slides, um formulário no google. Tudo acabou tornando-se um MVP, e parte disso deu-se por algumas confusões feitas pelo próprio Ries em seu livro — a principal delas, o ciclo de Build > Measure > Learn. O autor, ao reforçar muito o ciclo, acabou trazendo em torno do MVP a mentalidade de “construa qualquer coisa, colha feedback medindo os resultados e tire aprendizados disso”. E a verdade é: poucas pessoas leram o livro. O conceito de Build > Measure > Learn foi disseminado com essa mentalidade e faltou a atenção necessária por parte dos seus divulgadores para a página 78 do livro:

“The Lean Startup method builds capital-efficient companies because it allows startups to recognize that it’s time to pivot sooner, creating less waste of time and money. Although we write the feedback loop as Build- Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn, use innovation accounting to figure out what we need to measure to know if we are gaining validated learning, and then figure out what product we need to build to run that experiment and get that measurement.”

Tudo bem. É um problema grave de didática e de experiência do usuário colocar o nome do ciclo na sua estrutura reversa de execução, não culpemos os que disseminaram errado. Mas aprendamos: Lean Startup é um método para se criar startups de uma maneira eficiente, evitando os altos custos da arrogância e propondo uma mentalidade de — “o que eu quero aprender?” > “qual experimento posso fazer para gerar dados úteis?” > MVP. Em suma, o MVP é aplicar o pensamento científico e refletir sobre a maneira mais econômica de aprender sobre dúvidas e suposições. Inclusive, atualmente Steve Blank tem tratado o processo como “scientific entrepreneurship” — a mentalidade científica, baseada em dados e experimentos, para construir startups.

O MVP não é um produto, é um processo.

Agora, o fechamento reforçado pela Y Combinator: você não precisa construir um produto para validar hipóteses. O ponto central do MVP é o processo científico, é a mentalidade de elencar quais são suas hipóteses e refletir sobre as maneiras mais simples de executar um experimento que te ajude no processo de validação. Nos programas de desenvolvimento de startups/empresas de base tecnológica da Wylinka sempre dizemos: o que você pode fazer nas próximas 24 horas para validar suas hipóteses? Você não precisa criar uma primeira versão do app, você não precisa criar diversas funcionalidades, você só precisa pensar no mínimo a ser feito para começar a validar suas hipóteses. É um marketplace e quer conectar A com B? Crie uma lista de email com esses públicos e veja se a intermediação faz sentido. Está propondo uma nova estrutura de delivery concentrado? Crie um grupo de whatsapp e tente otimizar as entregas em uma localização específica. Em alguns casos será necessário criar algo mais robusto, não há problema, pois o MVP trata-se de criar maneiras eficientes de validar — e eficiência é uma medida comparativa (“o processo A economiza mais recursos que o B”). O importante aqui é a mentalidade de pensar hipóteses, pensar em experimentos mínimos e evoluir constantemente — sempre pensando em um processo, não em um produto.

“An MVP is not just a product with half of the features chopped out, or a way to get the product out the door a little earlier. In fact, the MVP doesn’t have to be a product at all. And it’s not something you build only once, and then consider the job done. An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.” (Y Combinator)

Conceito explicado, agora vamos às ferramentas práticas.

Duas ferramentas são úteis para reforçar essa mentalidade científica do MVP como um processo nas startups: a matriz de amarração e a matriz CSD. A primeira foi proposta por um dos gestores da Wylinka em um congresso científico e tem gerado resultados bem sólidos, a segunda é muito utilizada em processos de design centrado no usuário.

A matriz de amarração é uma matriz com três pilares: hipóteses (o que quero aprender), possíveis métricas (como medir) e experimentos (o que foi construído e aprendizados) — em alguns casos, indica-se o “aprendizados” em um quarto pilar isolado. A matriz de amarração é uma ferramenta do campo da metodologia científica em ciências sociais proposta pelo professor José Afonso Mazzon que tem como objetivo uma melhor organização lógica dos experimentos e maior alinhamento entre teorias, hipóteses e métodos — sendo desdobrada para o contexto da validação de empresas de base tecnológica por conta desta visão de alinhamento científico que ela carrega. Ter essa matriz em mente traz, além dos ganhos de clareza de raciocínio científico, maiores reflexões sobre os experimentos, tais como — “será que esse experimento me ajuda com outras hipóteses?”, “será que existem mais hipóteses?”, “os resultados fazem sentido com o que eu buscava aprender?”, “os aprendizados reforçam ou contradizem minhas hipóteses?”. Você pode entender melhor a matriz consultado o paper acadêmico publicado sobre sua aplicação (o paper também traz muitos detalhes sobre validação e desenvolvimento de startups) — clique aqui para acessar o texto.

A matriz CSD é uma lista com 3 tópicos: certezas, suposições e dúvidas. Com ela você organiza: quais são suas certezas (sempre colocar as certezas acompanhadas de “com base em…”, para trazer essa visão científica de que ela é embasada por dados/experimentos), suposições (ou hipóteses) e dúvidas (o que você não faz ideia — por exemplo, quanto seu cliente gasta em atividades físicas mensalmente). Esse é um quadro que toda startup deveria ter em alguma parede: as certezas, suposições e dúvidas sobre o usuário. Vai entrevistar um usuário? Olhe para suas suposições e dúvidas e veja quais podem ser exploradas na entrevista. Vai fazer um teste? Confira suas suposições. Está propondo uma nova feature? Veja em quais certezas ela se baseia. O processo de desenvolvimento de clientes deve ser um constante processo de melhor compreensão do usuário (aumento de certezas), bem como um constante exercício de elucidação sobre suposições e dúvidas.

CSD

Fonte: http://logobr.org/design-estrategico/matriz-csd/[/caption]

Esperamos ter sido úteis com a leitura, pois o tema “ciência e empreendedorismo” é o que move a Wylinka! Tentamos sempre propor novos modelos de desenvolvimento de startups, como fizemos no StartupTech da UFMG, que gerou empresas reais a partir da universidade (foi o evento que deu vida à Residuall), e esperamos poder ajudar cada vez mais startups de alta tecnologia no Brasil. Contem conosco e acompanhem-nos no Facebook, because when you rock, #wyrock!

…e o MVP é o Aaron Rodgers.

0 0 votos
Article Rating
Inscrever-se
Notificar de
guest
0 Comentários
mais recentes
mais antigos Mais votado
Feedbacks embutidos
Ver todos os comentários
Pular para o conteúdo