Products and Hacks — MVP é para ser feito em horas…ou menos
Recorrentemente escuto algumas frases — que me incomodam — e sempre faço uma associação do tipo o que falam…o que ouço. Por exemplo:
"Estamos terminando nosso MVP"…"Não tenho a menor ideia do que o dev/cto/fábrica de software está fazendo".
"Nosso produto está parado porque perdemos o nosso CTO"…"A gente é analfabeto digital e não sabe para onde ir".
"Já validamos a solução, estamos construindo nosso MVP"…"Perguntei para meus pais e amigos e eles gostaram. Disseram que usariam/pagariam se eu fizesse esse app".
Claro, essas são apenas algumas e muitas vezes se encontram no gerundio — ou no pretérito mesmo — e demonstra como a maioria dos empreendedores/gerentes de produto não são independentes digitais, bem como não possuem a menor ideia de como realmente é lançar um produto.
Vamos recapitular: WordPress foi lançado em 2003, Facebook em 2004, Google comprou Android/YouTube em 2005 e iPhone foi lançado em 2007. Agora imagina, um mundo no qual as pessoas não chegassem para você e dissessem: “A nossa solução é um app (marketplace) para [COMPLETE AQUI]”. Pois é, estamos falando de uma época que a indústria de apps nem existia, já que a App Store foi lançada em 2008.
Logo, quando me falam de fazer o "customer discovery" antes do desenvolvimento do produto, já associo com alguém que acabou de ler algo do Steve Blank — ou participou de um Startup Weekend — e não alguém que já tenha desenvolvido um produto digital.
Normalmente, esta pessoa não reflete que o livro foi lançado em 2011 e hoje, a janela de tempo é maior entre o agora e o livro, do que entre o livro e o iPhone/ Lojas de apps! É preciso contextualizar e ponderar…continua válido focar tanto no customer discovery?
Atualmente é — em ordens de grandeza — mais barato lançar um produto e testar o uso, do que em 2011. As vezes é mais rápido até do que fazer uma landing page! Está cada vez mais simples lançar e manter um produto e no NITE nos perguntamos…em quanto tempo conseguimos lançar um produto digital? Depois de 2+ anos iterando com os participantes do Products and Hacks, chegamos ao formato de um um workshop de 12 horas, para lançar (quase) qualquer produto digital!
Revisitemos o conceito de MVP. Para tal, é importante lembrar, até o próprio Steve Blank considera a escolha ruim do nome MVP para quando se quer testar uma hipótese. Basicamente, é ver se há apelo comercial para o seu “produto”, o qual pode ser traduzido como vendas pelo WhatsApp ou consultoria disfarçada de produto.
Não é enganar o cliente, pelo contrário(!), é encontrar aquele early adopter o qual topa ser inovador e testar um produto que não existe ou ainda está muito aquém do objetivo, mas resolve o problema. Entretanto, o que muitas pessoas não entenderam é que o importante disto é iterar rápido, resolvendo o problema, pois, vai se perder o momentum. Se perder nesse estágio é um fator para quebra de vários produtos/startups. Ou seja, encontra-se o apelo comercial, mas nunca se lança o produto e isso é mais comum do que se acha, principalmente para os hustlers analfabetos digitais.
Só para ficar claro, o conceito — MVP — foi criado pelo Frank Robinson o qual define como o ponto ótimo entre o que desenvolvo do produto e o que o mercado precisa de fato. Isso não invalida o customer discovery, mas não adianta fazer apenas este — ou aquele — isoladamente.
Inovar é iterar de maneira ágil no ciclo de aprendizagem entre o customer development e a entrega da solução para o mercado! É mais importante essa iteração e a aprendizagem decorrente do ciclo do que fazer muito bem feita uma ou outra. Se a fase é de aprendizagem, deve-se ficar claro o tipo de produto para tal.
O Jeff Paton tem uma definição boa para isso: “Don’t confuse build to earn with building to learn…Don’t overspend to learn…Nail it before you scale it”. Ou seja, se preocupe em ter um produto “bom” para aprender.
Quando aprender e necessitar de escala é que se preocupe em automatizar tal parte do produto. Vale muito começar como consultoria — modelo do Steve Blank — e ir automatizando o que for ficando repetitivo.
Hoje as infraestruturas em nuvem, os SaaS e os projetos opensource evoluíram MUITO — obrigado GitHub ❤ — e muitos dos projetos/plataformas já atendem a vários casos de uso. SEMPRE pense: como eu poderia resolver isso com o que já existe? Se você não conhece, dá um google com “how to [COMPLETE COM O JOB TO BE DONE]”. Lembre-se, provavelmente alguém já pensou algo similar ou igual — talvez em contexto diferente — e se não, comece a ficar desconfiado.
Outro ponto importante é esclarecer o processo de discovery e não só do customer (discovery). Como o Raphael Farinazzo diz, muito do tempo de um gerente de produto é fazendo descoberta. Trata-se de um ciclo de aprendizado e como tal, é importante ITERAR entre a idéia (hipótese), a descoberta (do job to be done) e a entrega (da solução — que pode ser manual) para o cliente, como o Marty Cagan apresenta na imagem acima (na primeira imagem está descrito como Agile Development, de novo, lembre-se da época). O que realmente importa é esse ciclo de aprendizagem contínuo e ágil entre idéia, descoberta e entrega.
Alex Rampell define bem o motivo para tal que é a startup precisa conseguir chegar na distribuição antes do incubente chegar na inovação. Quem trabalha shipando produtos e acompanha o ecossistema de startup, sabe bem, a dificuldade hoje não é mais técnica — só em raros casos — mas na criação da comunidade em volta do produto (clientes, fornecedores, parceiros e usuários). Pegue as grandes empresas por exemplo: o app de podcast da Google ou o Office Online da Microsoft. Tratam-se de produtos sempre inacabados — ou ruins mesmo, as vezes muito ruins mesmo — e sempre estão no ciclo de vender, ajeitar, vender mais, ajeitar…
Entretanto, o que eles têm forte? A comunidade em volta deles, o qual se torna uma barreira de entrada para outros players. Outros exemplos de produtos — em termos técnicos — que são piores que os concorrentes, mas possuem alto engajamento e uso:
- [Comunicação] Whatsapp <<< Telegram;
- [Comunicação] Slack <<< Workplace;
- [Blogging] WordPress <<< [Preencha qualquer outra ferramenta].
Todos possuem uma comunidade — entenda, são plataformas e/ou possuem uma grande comunidade de usuários — ativa, nutrida e evangelista em torno delas. Por isso, quando se fala de gestão de produtos, se fala em gestão de comunidades! Logo, ao se criar um MVP, deve-se ter em mente principalmente como gerir os clientes/usuários, fornecedores e parceiros.
Vamos ao exemplo, peguemos duas das startups de maior crescimento no Brasil: Resultados Digitais (RD) e Hotmart. A RD realiza eventos para parcerios e clientes, possui time de on boarding, nutre os parceiros (nesse caso, as agências) e a gestão dessa comunidade é que faz o produto crescer, muito mais do que um produto tecnicamente impecável.
No produto em si, neste momento da startup, há melhoras incrementais com uso — o tal de vende, ajeita, vende mais, ajeita. No caso da Hotmart, a rede de afiliados é defensora voraz da ferramenta/startup. A ferramenta em si não é o diferencial e isso pode ser visto no evento deles, o Fire. Como no caso das agências e o onboarding da RD, esta comunidade é que faz toda a diferença do produto/startup.Por isso, vamos parar de “ lamber” o produto e focar em lançar ele muito rápido!
O pior caso é perder vendas/clientes porque o produto está inacabado ou nunca saiu — agora ficou pensando como já fez isso né?! Nessa lacuna que chegamos em um modelo no qual — até agora —(quase) tudo que vimos se encaixa em um dos templates de MVP:
- Marketplace — Sugestão: Jotform+Shopify;
- “App” — Sugestão: Bubble.is ou Wordpress;
- Chatbot — Sugestão: Dialogflow ou Landbot.io;
- Comunidade — Discourse ou Wordpress;
- Sistemas de Gestão — G Suite+Google Apps Script ou Pipefy.
Todos eles têm hacks simples para lançar e o benefício disso é aproveitar do UI/UX, desenvolvimento e testes feitos por outras pessoas — no caso de SaaS e Infra de Nuvem é aproveitar do que o fornecedor já fez e no caso do open source do que a comunidade já fez— o qual acaba acelerando (e muito!) o processo de lançamento.
Entretanto, é preciso ficar claro, há uma dificuldade para usar esses hacks para o lançamento de produtos muito técnicos ou com o mercado muito regulamentado, exemplo: Antivírus, jogos 3D,IoT, transações financeiras e corporate com governança pesada. Para produtos técnicos, fica claro que é necessário entender da área.
Entretanto, muitas vezes se confunde ignorância e desconhecimento com ser um produto técnico. Para o último, infelizmente — ou felizmente — regulamentos impedem o uso de hacks. Isso torna o lançamento de um produto deste um processo intensivo em capital e em conhecimento técnico/da área MAS, felizmente, raramente há produtos deste tipo, como já disse, a maioria das vezes é ignorância mesmo.
Acredito que precisamos perder menos tempo na parte técnica do produto e mais no ciclo de aprendizagem: criação da comunidade -> entrega constante do produto. Se quiser saber mais, eu ❤ open source e tento manter o máximo de conteúdo aberto no site do Products and Hacks (com os casos), nessa apresentação e nas trilhas de aprendizagem da Universidade Agora. Fiquem a vontade para entrar em contato com a gente! :)
Valeu Raphael Farinazzo, Lai Amorim e Rafael Hundrão Campos Bezerra pelas leituras e milhares de correções/dicas nos drafts! :*
