Vou fazer um Spin-off da análise de negócios do protótipo de forma mais detalhada na série Primeira Versão do Seu Produto porque é muito importante para entenderem melhor do porquê de termos escolhido a funcionalidade de “Registrar Atividades” para iniciar com os usuários antes de definir o MVP.

No meu curso Product Ownership nós fazemos bem detalhado, mas vou tentar dar uma visão geral sobre o assunto.

Eu sempre comento sobre a importância de ter sócios com skills em áreas importantes que envolvem o produto, mas principalmente um especialista imerso nos detalhes que o produto atuará. Comento sempre sobre o ideal para uma Startup com Co-founders como: Um jornalista; um vendedor; um programador e um especialista no negócio.

Critérios de Escolha na Priorização

Esse especialista imerso no problema ajudará a guiar a funcionalidade mais importante primeiro seguindo 3 critérios básicos: Negócio, UX e código. Aplicamos a nossa listagem inicial:

1. Geração de gráficos.
2. Registro de Atividades.
3. Montagem da Agenda Diária de Atividades.

A dinâmica é excluir uma das Features em cada critério, se tivesse que sair do MVP, qual ficaria de fora.

Negócio

Aplicando a regra de negócio para as 3 features, devemos sempre focar em duas nuances:

1. Qual funcionalidade é independente possível para o usuário continuar fazendo o mesmo esforço sem retrabalho;
2. Qual funcionalidade dá um ganho direto melhorando o serviço que ele já faz.

A funcionalidade de “Geração de gráficos” salta em importância no negócio desse produto, naturalmente ela não pode ficar de fora do MVP porque guia o foco do produto, mas para esse exercício podemos aplicar os critérios. Em termos de negócio não traria um ganho direto aos usuários porque hoje o Coach pega os dados, popula uma planilha que já gera os gráficos, em termos de trabalho ele continuaria fazendo praticamente o mesmo serviço.

O “Registro de Atividades” tem uma importância fundamental em negócio porque atua no “Em resolver o problema de” do nosso template de foco do produto. O usuário “Aluno/Cliente” do nosso usuário Coach também continuará realizando o mesmo serviço, então não trará retrabalho, já que hoje ele recebe uma planilha compartilhada e tem que informar se cumpriu marcando o item com a cor azul ou alterar o horário da atividade e incluir um registro caso tenha saído do planejado.

A “Montagem da Agenda Diária de Atividades” provavelmente traria retrabalho para o Coach, porque hoje ele já compartilha com o usuário e necessitaria de outras Features planejadas no MVP.

Então para Negócios foram escolhidas: 1, 2.

User eXperience

“Geração de gráficos” não requer muita expertise, praticamente as ferramentas existentes são satisfatórias, vai exigir mais do trabalho no Backend e um pouco de usabilidade na montagem dos filtros.

“Registro de Atividades” como já citado vai resolver o foco do problema que esse produto se propõe a resolver, então ela salta pra primeiro lugar nesse critério. Teremos um desafio de justamente criar o mais clean e poderoso possível em relação aos concorrentes.

“Montagem da Agenda Diária de Atividades” trará também alguns dilemas, principalmente um formato não tão enfadonho e Enterprisey para algo que parece muito com um CRUD em cima de um Calendar.

UX: 2, 3 escolhidos.

Código

Aqui vão as discussões técnicas mais profundas em termos de arquitetura e tecnologias existentes para implementação.

“Geração de gráficos” com certeza trará um grande desafio, principalmente porque foi escolhido entrar com hashtags para o registro de atividades durante Brainstormings com os usuários, algo sugerido de features que até poderiam mudar o foco do produto e gerar uma “pitovação” no negócio (veremos mais a frente sobre isso).

“Registro de Atividades” trará desafios de Front-end justamente para resolver o problema do produto, ainda não sabemos ou temos idéia de como resolveríamos, portanto experimentar logo em campo e mudar o código frequentemente seria requisito.

“Montagem da Agenda Diária de Atividades” é trabalhoso, provavelmente demoraria mais do que todo o resto, mas não tem diferencial algum em relação ao código, foi unânime que todos sabiam como fazer, desde que usássemos uma Lib gráfica no Front-end que já montasse o Calendar.

Código: 1, 2 foram escolhidas.

Pela ordem de importância então seguindo os 3 critérios ficaram organizadas como:

1. Registro de Atividades (3 votos)
2. Geração de Gráficos (2 votos)
3. Montagem da Agenda Diária (1 voto)

Então se o MVP fosse mais reduzido, o que ficaria de fora seria a “Montagem da Agenda Diária”, isso ajudou a conceituar um Feeling que começamos a ganhar sobre o produto (guarde essa lembraça que falaremos em artigos a frente).

Evidente que a análise de negócios para entendimento das Features e ajuste constante do foco do produto é um trabalho da concepção ao fim, mas essa fase que compreende desde a identificação de um problema ao formato do MVP é crucial já colocar algo em campo para ter alguma idéia também do modelo de faturamento (se é que dá pra conseguir na maioria das vezes), portanto pela funcionalidade que resolve o problema proposto, o “Registro de Atividades” teria vencido caso tivesse empatado com “Geração de Gráficos”.

Essa proposta é antecipar ainda mais os problemas e ajustar o roteiro a ser seguido, tradicionalmente o MVP já é uma quebra de paradigmas por propor colocar uma versão reduzida do software o mais cedo possível que faça sentido para resolver o problema detectado, mas conseguimos desbravar mais cedo problemas técnicos e de usabilidade desde o primeiro dia.