MVP ou SLC? Simples Amavel e completo!
“MVP” implica um processo egoísta, abusando dos clientes para que você possa “aprender”. Em vez disso, torne a primeira versão simples, adorável e completa.
As equipes de produto vêm repetindo o mantra MVP (Produto Mínimo Viável) há uma década, sem reavaliar se é a maneira certa de maximizar o aprendizado e ao mesmo tempo agradar o cliente.
Bem, não é o melhor sistema. É egoísta e prejudica os clientes. Não construímos MVPs no WP Engine.
A motivação por trás do MVP ainda é válida:
- Construa algo pequeno, porque coisas pequenas são rápidas e baratas de testar.
- Coloque-o no mercado rapidamente, porque o verdadeiro aprendizado ocorre apenas quando clientes reais usam um produto real.
- Jogue fora ou gire com força se for um fracasso , ou invista se for uma muda com potencial.
Os MVPs são ótimos para startups e equipes de produtos porque maximizam o chamado “aprendizado validado” o mais rápido possível. E embora as entrevistas com clientes sejam úteis, você aprende coisas totalmente novas quando um cliente realmente usa o produto. Mas os MVPs são um ato egoísta.
O problema é: os clientes odeiam MVPs. As startups são incentivadas pelo grande Reid Hoffman a “lançar cedo o suficiente para que você fique envergonhado com o lançamento da versão 1.0”. Mas nenhum cliente quer usar um produto inacabado que deixe os criadores envergonhados. Os clientes desejam ótimos produtos que possam usar agora .
MVPs são muito M e raramente V. Os clientes veem isso e odeiam. Pode ser ótimo para a equipe de produto, mas é ruim para os clientes. E, em última análise, o que é ruim para os clientes é ruim para a empresa.
Felizmente, existe uma maneira melhor de construir e validar produtos. O insight surge ao honrar a utilidade dos MVPs (listados acima), ao mesmo tempo em que levamos em consideração a experiência do cliente.
Por exemplo, estava tudo bem que as primeiras versões do Google Docs tivessem apenas 3% dos recursos do Microsoft Word, porque o Docs fez um ótimo trabalho naquilo para o qual foi projetado principalmente, que é simplicidade e colaboração em tempo real.
O Google Docs era simples, mas também completo . Isto é decididamente diferente do MVP clássico, que por definição não é completo (na verdade, é “embaraçoso”). “Simples” é bom, “incompleto” não é. O cliente deve ter um desejo genuíno de usar o produto, tal como está . Não porque seja a versão 0.1 de algo complexo, mas porque é a versão 1.0 de algo simples.
Não é contraditório que os produtos sejam simples e completos. Os exemplos incluem as primeiras versões do WhatsApp, Snapchat, Stripe, Twilio, Twitter e Slack. Alguns deles foram posteriormente expandidos para adicionar complexidade (Snapchat, Stripe, Slack), enquanto outros mantiveram a simplicidade como um valor permanente (Twitter, WhatsApp). Virgin Air e Southwest Airlines começaram com apenas uma rota – pequena, mas completa.
O ingrediente final é que o produto deve ser adorável . As pessoas têm que querer usá-lo. Produtos que fazem menos, mas são amados, têm mais sucesso do que produtos que têm mais recursos, mas dos quais as pessoas não gostam. As primeiras versões originais, com recursos muito baixos, muito apreciadas e muito bem-sucedidas de todos os produtos listados no parágrafo anterior são exemplos. O ciclo darwiniano de sucesso de um produto é uma função de amor, não de características.
Simples, Amável e Completo (SLC).
Noções básicas de SLC
Um SLC é um protótipo que é:
- Simples,
- Adorável, e
- Completo.
Para resumir rapidamente, o autor Jason Cohen argumenta que os MVPs costumam ser uma experiência horrível para os clientes, já que os fundadores estão apenas tentando validar e obter feedback rapidamente. Ele argumenta que você deveria abandonar o MVP e construir um SLC. Ele continua dizendo que SLC é uma versão do produto simples em sua funcionalidade, os clientes adoram utilizá-lo e oferece uma experiência completa .
Isso contrasta com os MVPs, onde os fundadores tendem a se concentrar na parte “mínima”.
SLC x MVP
Como mudei para ser um fundador solo em tempo integral, o conselho para construir SLCs parece mais oportuno agora do que nunca. Mas não consigo afastar a sensação de que o humilde MVP ainda serve a um propósito muito útil à medida que desenvolvemos novos softwares.
Minha sugestão? Ainda construa um MVP. Construa rápido; filmar por um fim de semana. Não se preocupe com o quão desagradável isso é. Apenas faça isso.
Em seguida, use esse MVP para testar seu conceito com amigos, familiares e colegas, mas não com clientes reais. Se forem bons amigos, o feedback deles será duro, mas necessário. Esse feedback inicial forçará você a ajustar seu MVP, mudar para um MVP diferente ou validar seu conceito. Depois de obter a validação, você poderá construir um lindo SLC que resolva um problema complicado de uma forma simples e adorável.
Quais são os princípios mais importantes a serem seguidos ao desenvolver a primeira versão do seu software?
Você está no time MVP, no time SLC ou em ambos?
Este texto foi retirado sem edições de 2 textos linkados a baixo, para saber mais
leia-os!
Fontes:
https://www.indiehackers.com/post/your-customers-hate-mvps-should-you-use-an-slc-instead-c6c2bb0f22