3 Perguntas para responder antes de começar a idealizar um MVP

3 Perguntas para responder antes de começar a idealizar um MVP

O MVP - Produto Mínimo Viável - precisa chegar rápido à fase de validação. É o momento em que algumas etapas são adiadas para que se possa respeitar a "voz do cliente" em relação à proposta essencial de valor que se pretende oferecer.

Ward Cunningham cunhou o termo "Technical Debt", explicado por ele aqui neste vídeo (em inglês). Sua intenção foi criar uma metáfora para a noção de que se produz uma espécie de passivo quando são liberadas versões incompletas de um programa. Quanto maior o atraso para reconduzir o programa segundo o melhor entendimento possível do domínio do problema a resolver, mais difícil se torna fazer isto. É como se incidissem "juros" sobre este dito "Passivo Técnico".

Vejo muitos projetos abusarem deste "Technical Debt". Minha sugestão é que suas equipes se façam pelo menos 3 perguntas:

I. Qual o tipo de produto que será oferecido?

Pode se tratar de apenas um aplicativo móvel, sem que haja necessidade de infraestrutura (banco de dados, APIs, aplicativos Web) existentes na nuvem. Se não for este o caso, será necessário pensar em governança para os dados, segurança para as API's, etc. Tais características podem ser adiadas no MVP, mas cedo ou tarde será necessário incorporá-las.

II. B2B ou B2C?

O cliente será o consumidor final? Ou a compra será feita por um comprador institucional? Deixando de lado a questão do investimento em Marketing - muito diferente em cada um dos casos acima - a resposta tem influência direta sobre a escalabilidade da solução. Já que o número de acessos B2C tende a ser maior e mais concentrado, se o produto não puder reagir a picos de utilização, seu primeiro MVP bem sucedido pode se tornar, também, o último. Convém dar atenção aos indícios que o mercado oferece sobre a utilização de micro serviços, uma resposta moderna e eficiente aos problemas de escala.

III. Será Multi-tenant?

Uma aplicação é dita "Multi-tenant” quando parece se comportar como se fossem várias aplicações independentes hospedadas para diferentes clientes (ou seja, organizações). Isto pode não parecer importante, porém, quando o número de clientes aumenta, torna-se mais evidente que é mais fácil e mais rentável executar um único aplicativo hospedado para todos os clientes, ao invés de hospedar uma aplicação independente para cada cliente. Deixar esta característica de lado no MVP pode aumentar consideravelmente o "Technical Debt".

Minha conclusão é que é tão importante validar de maneira coerente uma ou mais propostas de valor para cada segmento de clientes escolhido, quanto reter a capacidade da equipe em implementar a forma de monetização o quanto antes. Isto implica em gerenciar o "Technical Debt" de forma eficiente. A utilização de micro serviços e o emprego de técnicas como "Domain Driven Design" podem contribuir significativamente, mas o essencial é o compromisso de toda a equipe com um "Road Map" consistente.

Entre para ver ou adicionar um comentário

Outras pessoas também visualizaram

Conferir tópicos