Até onde consigo segurar meu MVP no meu SaaS
Ter uma ideia e construir o seu MVP é a parte mais fácil na hora de criar sua Startup. O difícil é metrificá-lo, identificar os problemas do produto e principalmente saber quando é hora de matar o seu MVP e construir seu novo scalable product.
Inicialmente, a cada 5 minutos nasce alguém dizendo que MVP deveria ser chamado de MAP, MTP, Viable, Valuable, Tinky Winky (tá, essa última eu inventei). Isso é irrelevante, pois no fim, o que importa é o mindset da sua empresa, e no fim, MVP funciona bem para um mindset de produto/processo.
Muitos se enganam a acreditar que MVP é um termo para produto, design, tecnologia. Ele está ligado diretamente a validação da sua startup. Ele te ajuda a definir validações on-the-fly em cima do seu modelo de negócio, proposta de valor e até comportamento do seu cliente.
— Ok Bernard, eu entendo na teoria, mas na prática, para que um MVP?
MVP foi definido e criado por Frank Robinson (CEO da Syncdev), onde você precisa desenvolver o "mínimo viável" para conseguir diminuir o seu risco de negócio. O conceito é fantástico, e bastante recomendado por Eric Ryes e Steve Blank em seus livros (The lean startup e Four steps to the epiphany, respectivamente).
O grande problema é que o termo se banalizou, onde muita gente utiliza o nome MVP para cunhar Protótipos, Landing Pages e até mesmo o "MVP Concierge".
O que é e o que não é um MVP?
- Testei meu MVP com 30 BETA Testers — Isso não é um MVP, é um protótipo funcional.
- Criei um MVP de uma Landing Page para pegar cadastro de interessados — Isso não é um MVP, é uma Landing Page.
- Contratei um time de 4 desenvolvedores, em 6 meses terei o meu MVP para meus clientes usarem — Isso não é um MVP, é um produto já fechado e com risco bem avançado.
Veja o caso da Bunee.io (minha startup de Inteligência Artificial para Recrutamento).
- Setembro de 2016: Início do desenvolvimento de nossa tecnologia
- Novembro de 2016: Lançamento do protótipo funcional para BETA Testers
- Janeiro de 2017: Lançamento do MVP para clientes.
- Julho de 2017: Lançamento da V2 do MVP para clientes (535 cadastros de clientes até o momento).
- Janeiro de 2018: Início do desenvolvimento do nosso produto estável (+1000 cadastros de clientes até o momento).
Gostaria de destacar duas coisas interessantes nesse roadmap de lançamentos.
A primeira coisa é que o primeiro semestre de 2017 foi para validar qual modelo de negócios tinha mais aderência para nossos clientes, assim validamos o modelo de negócios para uso de créditos, planos semestrais, plano mensal, no touch de signup, low touch, high touch, mudamos de preço, mudamos 2 vezes o formato do card dos nossos talentos, fechamos mais de 3 parcerias para qualificar ainda mais os nossos talentos, e alteramos nossos algoritmos mais de 5 vezes, para serem mais assertivos para nossos clientes.
A segunda coisa que gostaria de destacar é a V2 do MVP, pois nela já validamos as coisas mais críticas do nosso negócio, valendo um esforço maior para melhorar a experiência do nosso cliente, visto que embora a entrada de clientes estivesse crescendo bastante, estávamos perdendo bastante em engajamento do nosso cliente na plataforma.
No sentido de business, era muito claro nossa validação. No 1º semestre nosso objetivo era ter pessoas usando nossa plataforma, para ela aprender, e validarmos hipóteses, então era basicamente 1–3 releases por semana. No 2º semestre nosso objetivo era ter clientes pagantes, e entregar sucesso para eles.
No nosso último quarter de 2017, nosso foco foi aumentar o tempo de vida do nosso cliente, engajando mais, não só colocamos tooltips, wizard, como contratamos uma pessoa de sucesso para ajudar nessa etapa.
Por que trocar MVP no meu SaaS? Trocar por?
Ao validar as primeiras premissas, está na hora de escalar o processo. Produtos mais estruturados, mais escaláveis, geralmente é nesse momento que a Startup recebe seu SEED Money, já com dezenas ou centenas de clientes ativos.
Nesse momento, você já tem hipóteses já confirmadas ou mais maduras, onde você se permite investir um pouco mais, ou seja, tomar um pouco mais de risco, para levar seu usuário onde você deseja. Alguns exemplos de possibilidades nesse momento:
- Trabalhar melhor o Upsell para seus heavyusers
- Gerar mais estratégias para reter seus clientes em planos de longo prazo (semestrais, anuais)
- Gerenciamento de mais usuários (pensando em grandes clientes)
- Ferramenta atrelada de BI para seus clientes
O interessante de startups SaaS é o uso contínuo de nossos clientes, então, você tem muita informação acontecendo no seu produto (downloads, stickiness, dau, mau, session, clt, clv, cr, crc, rr, saas quick ratio, contraction, expansion, churn, reactivation, retention, engagement, satisfaction, etc) , que precisa de análise contextual. Lembre-se, analisar dados sem ter um contexto definido pode gerar muita perda de tempo em algo improdutivo.
O que muda no MVP para um produto estável é o tempo, pois no MVP, gasta-se 80% em tarefas pequenas e 20% em tarefas grandes, por conta de releases curtos, enquanto no Produto estável, gasta-se 20% em tarefas pequenas e 80% em tarefas grandes, pois o produto já está mais maduro, muitas features já estão devidamente estáveis e planeja-se grandes lançamentos em períodos estratégicos de tempo, baseado em quarter, semestre ou ano.
O MVP nunca morrerá!
O MVP, mais do que um produto, é uma forma de mitigar seu risco, desde que seja em um ambiente real, com clientes reais. Alguns o chamam de processo, mas eu prefiro chamar de mindset, pois existem muitos processos que se encaixam para se criar MVPs de sucesso.
Mesmo com nosso produto próximo do estável, estamos hoje com 3 features em teste (usando conceito de MVP), que podem ser incorporadas ou não com mais robustez na nova versão:
- Anotações em cima do candidato: Hoje é apenas um textarea que guarda a informação. Agora que vimos que uma quantidade relevante de usuários a utiliza, vamos redesenhá-la para organizar melhor o conteúdo de dentro, coisa que o textarea não consegue nos dar como recurso.
- Salário da empresa/cidade: Hoje temos uma barra que entende a empresa ou cidade do candidato e mostra uma estimativa do range salarial. Ela não tem funcionado como gostaríamos, o que nos levará ou a refazê-la ou simplesmente removê-la na próxima versão.
- Tempo de experiência: É um dos itens mais pedidos por nossos clientes, mas exige uma complexidade na hora de evoluir isso de forma proativa. Pois uma medição errada, pode desfavorecer um talento, e isso é o que menos queremos. Por isso, mais testes são necessários para assumirmos essa feature de forma estável.
Dica final: Cuidado com grandes mudanças de processo
Um dos maiores perigos ao transformar seu MVP no produto estável é a mudança em fluxos, visual e usabilidade.
O ser humano tende a superestimar ou subestimar mudanças, e nunca ser realista em cima de suas expectativas. Ou seja, grandes mudanças podem fazer suas métricas caírem em primeira análise, porém, essa curva pode crescer de forma mais acentuada depois (dê tempo para mudanças). Cuidado ao efetuar grandes mudanças no processo e visuais ao mesmo tempo, pois isso pode assustar o seu cliente, que pode deixá-lo por não estar disposto a aprender tudo de novo sem nenhuma recompensa.
Algumas plataformas permitem que o cliente possa clicar em uma barra e ativar a nova versão, assim ele consegue identificar os early adopters, usando como base experimental de correção de bugs, lançamentos betas e melhorias, antes de se tornar padrão.
Espero que você tenha um bom crescimento e bons problemas que vem com ele, para o seu Saas:)
