Um começo de sucesso
Descobri o Produto Mínimo Viável (MVP do inglês Minimum Viable Products) como 99% dos demais Gerentes de Produto, através do livro A Startup Enxuta, de Eric Ries. Quando deparei com o livro e com o método criado por Eric, pensei "SIM! Isto era o que vinha procurando. Isto faz muito sentido." Testar produtos antes de construí-los? Que ideia original! Estava empolgada. Estava energizada. Agora seria capaz de construir coisas que importavam para meus clientes.
Francamente, esta abordagem chegou na hora certa para mim. Estava cansada de construir produtos que ninguém usava. Assistir e esperar os números aumentarem no Google Analytics, apenas para me decepcionar novamente. A equipe gastou meses construindo produtos que pensamos que seriam sucesso, apenas para nos desapontar. Quando tive uma oportunidade para testar a abordagem de MVP em um novo produto, me agarrei nela.
O CEO da companhia de e-commerce me abordou com uma ideia para um novo produto que iria aumentar a retenção e vender mais itens. Ele queria implementar um feed similar ao Twitter, no qual as celebridades que vendiam produtos no site poderiam também postar a respeito de suas vidas. Esta ideia era excelente para teste. Ela era cheia de suposições: "Nossos clientes querem ouvir o que as celebridades têm a dizer diretamente na nossa plataforma? Isso irá vender mais itens ou aumentar retenção?
Fui aos engenheiros e perguntei quanto tempo demoraria para implantar completamente a ideia a partir do zero, da forma que o CEO estava propondo. Com estimativas aproximadas, conversei com o líder e disse: "Isso custará $75.000,00 para a implementação completa, e não temos sequer certeza que os clientes irão se interessar. Posso verificar em uma semana com $2.000,00 se isso irá causar algum impacto". Apenas com este argumento, a ideia estava lançada.
Em uma semana, provei que era uma ideia terrível. Uma semana depois disso, encontramos uma solução que aumentou a taxa de cliques em nossos produtos. Também dobramos a taxa de conversão. Toda a companhia ficou interessada, e recebemos permissão para continuar experimentando. "Ótimo", pensei, "Todo mundo pode ver o valor disso! É uma decisão óbvia".
Depois de algum tempo, mudei de emprego. Estava empolgada para levar o conceito de MVP para esta equipe também. Honestamente, estava meio chocada que ninguém naquela companhia estivesse usando MVP ainda. Eles simplesmente não conheciam esta magia maravilhosa? Estava muito confidente que tudo iria acontecer exatamente como na companhia anterior.
Não fazemos isso aqui
Quando as palavras "Produto Mínimo Viável" saíram da minha boca pela primeira vez, a reação na sala foi bem diferente do esperado. Era como se tivesse recitado todos palavrões do dicionário. Como se simplesmente tivesse começado a cantar uma música do Biggie Smalls no meio da reunião, sem blips sobre as frases mais cabeludas. Eles responderam como se tivesse ofendido seus antepassados. Finalmente, o Diretor de Marketing quebrou o silêncio e disse: "Não fazemos isso aqui. Não vendemos produtos terríveis."
Nas semanas seguintes, vivenciei a mesma reação incontáveis vezes.
Descobri que um MVP é largamente mal compreendido. Algumas pessoas têm medo de tentar construir MVPs por causa de entendimentos pré-concebidos. Outros usam tanto a palavra, que ela perde seu sentido. "Deveríamos MVP isso!" se tornou um grito de guerra em desenvolvimento de produtos que simplesmente significa fazer algo minimalista, fazer barato, e fazer rápido.
Como as pessoas acabaram assim? A história é quase sempre a mesma. Alguém se deparou com A Startup Enxuta, se impressionou e disse "Deveríamos fazer isso!" Eles viram uma maneira rápida e barata de construir um produto, sem entender completamente qual era o propósito de um MVP ou como fazer da maneira correta. Em em uma companhia especialmente esgotada, um desenvolvedor acabou criando um hack para testar uma nova funcionalidade que quebrava toda vez que alguém tentava usá-la. Os clientes estavam irritados. A companhia culpou o MVP como um todo, ao invés do desenvolvimento negligente.
Não é culpa do MVP. O problema deriva da falta de entendimento sobre o que é um MVP e da má comunicação ao longo do caminho.
O que é um MVP?
Minha definição de MVP é a menor quantidade de esforço que se precisa fazer para aprender. Quando ensino isso em workshops, geralmente encontro discordâncias. "MVP são o menor conjunto de funcionalidades que se pode construir e vender! Não apenas um experimento".
Então qual é a verdade? Um MVP é um produto, um subconjunto de um produto, ou apenas um experimento?
O termo Produto Mínimo Viável foi cunhado por Steve Blank e depois popularizado por Eric Ries em A Startup Enxuta. Pesquisei como esses dois experts, e alguns outros, definem o termo.
"Um produto mínimo viável é aquele produto que tem apenas as funcionalidades necessárias para colocá-lo em produção e nada mais, para que early adopters possam vê-lo e, de acordo com alguns, pagar por ele, e começar a lhe enviar feedback." - Eric Ries, 2009
"Conjunto mínimo de funcionalidades ("produto mínimo viável") é uma tática de desenvolvimento de clientes para reduzir desperdícios de engenharia e entregar o produto na mão de early evangelistas o quanto antes." - Steve Blank, 2010
"Um produto mínimo viável (MVP) nem sempre é uma versão menor/mais barata do seu produto final." - Steve Blank, 2013
"Um MVP não é apenas um produto com metade das funcionalidades cortadas foras, ou uma maneira de colocar o produto na rua um pouco antes. Na verdade, um MVP não precisa sequer ser um produto. E não é algo que se constrói apenas uma vez, e então considera como trabalho feito." - Yevgeniy Brikman, Y Combinator, 2016
Confuso, né? A única coisa que ficou clara através desta pesquisa é que a definição de MVP evoluiu. No começo, falávamos sobre este conceito como algo para validar ideias de startups. Todos estes produtos estavam procurando por product-market-fit. Fiquei sabendo a respeito do Concierge Experiment and Wizard of Oz nesses dias, que me ajudaram a dar forma a minha definição e entendimento. Conforme continuava a usar esses métodos como Gerente de Produto em companhias e outras organizações mais maduras, tive que customizar tanto minha definição quanto a prática de construir MVP. Aprendi que é necessário ambos - o conceito de experimentar e construir um conjunto mínimo de funcionalidades para ter sucesso.
Enquanto existem toneladas de dissidentes a respeito da definição de MVP, praticamente todo mundo concorda sobre o objetivo. O objetivo do MVP é aprender rapidamente o que o cliente quer. Se quer fazer isso tão rápido quanto possível, então pode focar na coisa certa. Vamos nos livrar dessa buzzword e focar na premissa. Vamos parar de discutir sobre o que é um MVP e começar a falar sobre o que precisamos para aprender enquanto companhia.
Como e quando aprender
Quando começamos a construir uma nova funcionalidade ou produto, existem milhões de perguntas para responder. "Isto está resolvendo o problema do cliente? Este problema realmente existe? O que o usuário espera ganhar com o resultado final?" Precisamos encontrar as respostas para estas questões antes de nos comprometermos a construir uma solução.
É por isso que começar com um conjunto mínimo de funcionalidades é perigoso. Quando começa a construir a primeira versão de um novo produto ou funcionalidade, se esquece de aprender. Experimentar lhe ajuda a descobrir os problemas dos seus clientes, e a solução apropriada através da resposta para estas perguntas. E também não acaba com apenas um experimento. É necessário fazer múltiplos follow-ups que continuem respondendo questões. Quanto mais responder antes de se comprometer com a solução final, menos incerteza haverá se os usuários usarão ou não.
Uma vez que se tenha provado que o usuário quer o produto, é hora de investigar um conjunto mínimo de funcionalidades. Agora podemos começar a definir um produto que é apto de ir para o mercado e vendável, mas também atende às necessidades que foram descobertas pelos usuários através de experimentação. Entregar este produto para o mercado tão rápido quanto possível é o maior objetivo, desta forma conseguindo ter feedback dos clientes e iterar. Mas tem que ser cuidadoso para entregar um produto de qualidade, mesmo que ele seja pequeno. Produtos defeituosos não produzem valor para seus clientes, apenas problemas. Qualquer versão de um produto que não entrega valor é inútil.
Como isso é na prática? Em uma companhia de SaaS com na qual estava trabalhando, tivemos que criar uma nova funcionalidade que ajudaria nossos clientes a projetarem suas metas. Recebemos feedback através da equipe de vendas ao cliente, de suas conversas com o cliente. Depois de revisar a informação, sabíamos que tínhamos que aprender mais.
Encontramos com o cliente para entender para que eles precisavam desta projeção. Quando pensamos que tínhamos uma boa compreensão das necessidades, construímos uma planilha para eles, e inserimos dados atuais do cliente na planilha. Isso nos tomou menos de uma semana. Apresentamos a planilha para o cliente e o deixamos utilizando-a por uma semana antes de receber seu feedback. Não entendemos bem da primeira vez, ou da segunda vez, ou da terceira. Mas, na quarta iteração, conseguimos entregar exatamente os resultados que o cliente estava procurando. Fizemos o mesmo processo com alguns outros clientes para ter certeza que era escalável.
Embora a planilha estivesse provendo valor imediato para alguns de nossos clientes, não tínhamos recursos para fazer isso por todos eles. Então tivemos que construir uma solução de software. Começamos explorando o conjunto mínimo de funcionalidades, usando o feedback que havíamos recebido da planilha. Havia diversos outros acessórios que os clientes queriam, mas mantivemos apenas os essenciais na primeira versão. Trabalhamos algumas semanas para fazer a primeira versão funcionar e incluir as peças mais importantes. Depois liberamos o software para os clientes que tinham a planilha, para ouvir seu feedback. Depois de iterar algumas vezes, começamos a vendê-lo para os demais.
Este processo ajudará sua companhia a encontrar a combinação o problema e solução. Se está criando uma nova funcionalidade ou uma nova linha de negócio que resolve um problema para seus usuários, este método pode ajudar a garantir que está construindo a coisa certa para seu cliente. Mas e se tiver um produto maduro e não começando um novo do zero?
Experimentação nas companhias
Diversas companhias hoje são apresentadas ao MVP por consultorias que propõe criar um produto inteiramente novo a partir do zero. Esta nem sempre é a melhor ideia. Quando sua companhia já possui um produto que se encaixa no mercado, seus clientes já estão usando seu produto. Não é preciso reconstruir seu produto, é preciso melhorá-lo. Os métodos deveriam ser adaptados para esta situação.
Uma das coisas que separa estes dois métodos é o objetivo. Quando a companhia já possui um produto que se encaixa no mercado, queremos que o usuário adote e provavelmente pague pelo produto. Mas isto nem sempre é o objetivo quando estamos melhorando os produtos já existentes. Poderia ser melhorar a retenção ou aumentar o engajamento com certas partes do produto. Qualquer que seja o objetivo, deveria ser claro para a equipe e orientar todas as decisões.
Assim que o objetivo estiver claro, o foco deve ser novamente o aprendizado. O que precisamos aprender para nos comprometer com uma solução. Escreva as hipóteses sobre o que precisa ser feito e então desenhe um protótipo para testar. Não é preciso criar um produto inteiramente novo. Talvez possamos descobrir que um produto novo é necessário durante a experimentação, mas este não deveria ser o objetivo final.
Uma companhia para a qual estava prestando coach queria aumentar a taxa de conversões em todo o site. Eles já tinham um e-commerce baseado em assinatura com milhares de usuários. Havia tráfico, mas os usuários não estavam convertendo tanto quanto projetado. Nada estava movendo os números, então decidiram fazer testes. Procuraram as fontes de onde os usuários estavam vindo e descobriram que muitos chegavam através de indicação. Mas, apenas alguns usuários estavam realmente enviando referências. Através de pesquisas com usuários, descobrimos duas razões principais: eles não sabiam que podiam enviar indicações e não tinham certeza se a indicação beneficiou seus amigos.
A equipe decidiu solucionar o primeiro problema com a hipótese "Se deixarmos os usuários saberem claramente que eles têm a funcionalidade de indicações disponível, eles irão utilizá-la". O primeiro experimento mostrava uma pop-up que encorajava os usuários a enviar indicações na próxima vez que eles fizessem login no site. O envio de indicações aumentou em 30%, levando a um aumento da taxa de conversão. Eles não tiveram que implementar um programa inteiramente novo; eles tiveram apenas que criar meios de tornar o programa existente mais visível.
Esta equipe continua a ir fundo nos problemas relacionados a conversão. Eles descobriram que os três principais problemas de experiência no site eram:
- Os clientes não tinham certeza de como o serviço funcionava;
- Os clientes queriam saber quais produtos específicos vinham com a assinatura;
- Os clientes não tinham certeza por que o produto era mais caro que o dos concorrentes.
O próximo passo para solucionar estes problemas foi identificar se poderiam entregar valor e aprender ao mesmo tempo. Criaram então a hipótese: "Se dermos aos usuários a informação que estãoprocurando no processo de cadastro, irão converter mais". Outro objetivo era o de descobrir em que perguntas as pessoas mais clicariam, para ver qual problema era o maior. Desta forma, planejaram uma maneira simples para dar às pessoas a informação que precisavam enquanto se cadastravam: adicionar alguns links no processo de cadastro, devolvendo perguntas de volta para os usuários. Quando um link era clicado, um pop-up abria explicando a resposta para a pergunta. Ao final da semana de construção e testespuderam ver que o experimento havia aumentando a taxa de conversão para próximo do objetivo original. E também descobriram que mostrar a informação sobre o que exatamente vinha na assinatura foi a coisa mais importante. A equipe continuou a descobrir o que estava impedindo prospects de assinarem o serviço e sistematicamente responderam a todas questões através de experimentos.
Precaução adiante
Um erro que as companhias cometem quando estão lidando com experimentação de produtos é mantê-los no jogo mesmo depois do aprendizado. Estas funcionalidades então começam a falhar e causar problemas para os usuários. Se está projetando para aprender e depois seguir adiante, não para implementar algo que irá durar para sempre.
Com a equipe anterior, aprenderam que a informação que disponibilizaram estava ajudando a responder as perguntas dos prospects, mas não havia pessoas suficiente vendo a solução. Depois de experimentarem mais, descobriram que uma solução mais robusta seria necessária.
Chegou a hora de começar a planejar uma solução sustentável que incorporasse o aprendizado dos experimentos. Ir das experimentações para a próxima fase não é uma desculpa para parar de medir. Esta equipe ainda estava lançando componentes em pequenos lotes, mas aqueles lotes eram completos com bom design e uma visão mais holística. Depois de cada release, o que acontecia a cada duas semanas, eles mediam o efeito do release sobre as conversões e testavam na frente dos clientes. O feedback os ajudava a iterar em direção ao produto que iria atingir a meta da taxa de conversão.
Chris Matts eloquentemente chamou isso de Investimento Mínimo Viável. Ele também chamou a atenção que não deveríamos apenas tentar melhorar nossos produtos focados no usuário, mas melhorar também a infraestrutura que ajuda a criar estes produtos rapidamente. A equipe também está melhorando a arquitetura do site para experimentar mais rapidamente enquanto aguardam pelos resultados. Apresentei o Produto Kata para as equipes que estavam melhorando seus produtos para ajudá-los a encontrar uma estrutura através de experimentação de produtos e Investimento Mínimo Viável.
Aprender é a meta
Uma das partes mais assustadoras deste processo para companhias é lançar coisas que não são perfeitas. É importante balancear bom design com design rápido, e bom desenvolvimento com desenvolvimento rápido. A melhor maneira de fazer isso é fazendo designers de interfaces trabalharem em conjunto com desenvolvedores. Depois de definir qual é a meta para iteração ou experimento, sentem-se juntos e conversem sobre as ideias e como executá-las. Se planejarem de uma maneira levemente diferente, é igualmente útil para o usuário, mas mais fácil de construir? Criem um protótipo juntos. Criem o esboço juntos. Trabalhem lado a lado e conversem sobre as contrapartidas o tempo inteiro. É assim que boas equipes se movem rapidamente e evitam retrabalho.
Descobrindo cedo o que o usuário quer, evitei incontáveis horas de retrabalho e desperdício de funcionalidades ao mesmo tempo. É por isso que experimentar é tão importante para equipes, sejam elas B2B ou B2C. Dê às equipes de produto acesso aos usuários. Vi companhias com medo que seus funcionários dissessem ou fizessem coisas que incomodariam seus usuários. Ensine sua equipe de produtos a maneira correta de se comunicar e experimentar que isto não acontecerá. Treine as equipes em pesquisa de usuários. Não lance experimentos para todos. Crie um grupo de Facebook com um subgrupo de usuários. Construa infraestrutura para que consiga disponibilizar experimentos e funcionalidades apenas para pequenos grupos. Estes usuários irão lhe guiar na criação de funcionalidades que irão atender às suas necessidades.
Sonho com o dia no qual possa entrar em uma companhia e mencionar "MVP" e não ouvir "Não fazemos isso aqui". Embora a definição de MVP ocasionalmente nos deixe tensos, o objetivo por trás dela é extremamente valioso para as companhias que desenvolvem produtos. Caso esteja enfrentando problemas para implementar estas práticas em uma companhia, procure deixar as buzzwords de lado. Use termos como experimentação e foco na premissa. Entender o que os usuários querem antes de construir algo é bom para o desenvolvimento dos produtos. Ao investir em uma funcionalidade ou solução, tenha certeza que é a certa.
Sobre a autora
Melissa Perri é gerente de produtos, designer de experiência, palestrante e coach. Fundou a ProdUX Labs para ajudar equipes que trabalham com produtos a criarem estratégias que satisfaçam os usuários e orientem os objetivos do negócio através de respostas para duas perguntas importantes - "Deveríamos construir isso?" e "Por quê?" Sua lista de clientes inclui companhias como Spotify, Rovio, Valtech, Plated, Wayra UK, e Levo League. Além de trabalhar com clientes, está concluindo o livro "The Build Trap" e lançando a Product Management School para gerentes de produto juniores e seniores. @lissijean
