O que atacar em produto? User Impact Score pode te ajudar a começar!
Tags: product, user, impact, roadmap
Published: 2020-09-08 23:31:18

Criar e manter um produto digital não é tarefa das mais fáceis. No começo tudo é novidade, qualquer nova feature é recebida com festa e desenvolvida com uma baita agilidade.

Com o passar do tempo o produto que era simples começa a criar dependências e uma estrutura mais robusta. Isso traz um impacto grande na empresa pois a agilidade no desenvolvimento já não é o mesmo. E isso não está errado, ou até pode estar, existem maneiras de manter agilidade no desenvolvimento, mas isso é assunto para outro post.

O que quero abordar aqui é a necessidade de colocar na esteira de desenvolvimento algo que realmente faça sentido para o produto. Aqui entra o papel do Product Owner - PO, o cara responsável por orientar o time sobre quais tarefas/features devem ser atacadas, sempre seguindo a estratégia da empresa, que pode ser definida por um Product Manager - PM ou/e C-Levels. 

Mas as vezes a empresa está no começo e não possuí estes papéis tão bem definidos, muito menos uma estratégia de priorização de produto. Lembra acima quando mencionei que o desenvolvimento de produto tende a perder a agilidade com o tempo? Imagina demandar features para o time que não tragam benefícios reais para os usuários/produto? Imagina o tempo, o custo, seus concorrentes crescendo... Tudo isso entra no pacote.

Por isso priorizar corretamente é importante, e uma maneira simples de **começar** é utilizar o básico do **UIS - User Impact Score**.

UIS: Pontuação de impacto do usuário, referente a alguma ação.

Para isso temos uma passo a passo:

1 - **VOCÊ PRECISA** escutar o seu usuário, seja por e-mail, chat, telefone, etc...

2 - **MAPEIE** as demandas e problemas, falando com os usuários você vai conseguir ter informações valiosas do que funciona no seu produto, o que seus usuários precisam, e o que mais gostam. Organize isso em alguma ferramenta, pode ser um Trello, uma planilha em excel. 
Dados como Nome do cliente, tamanho da empresa, região, quantidade de funcionários etc.. O máximo de dado aqui pode ajudar no futuro.

3 - **CATEGORIZE**, separe as demandas e problemas por áreas do sistema, por tamanho de empresa, por região do país, algo que faça sentido para o seu modelo de negócio.

4 - **FILTRE** as demandas que não fazem parte da sua estratégia. Parece que não, mas irão aparecer demandas que não fazem sentido algum com o seu modelo de negócio.

Pronto, agora temos uma lista bem organizada =), com sugestões de melhorias dos usuários, problemas recorrentes e novas features. Agora é só escolher uma e atacar, certo? **Errado!**

5 - **PONTUE** cada solicitação.

Saber o impacto que cada demanda leva ao seu usuário deve ser levada em consideração.

Imagine a mesma demanda: 

**Fulano da Empresa ACME**
"Gostaria de cadastrar a data de nascimento dos meus clientes para que no futuro eu consiga enviar um cartão de aniversário para eles."

**Ciclano da Empresa XPTO**
"Preciso saber a data de nascimento do meu cliente para conseguir finalizar o fluxo de pedido"

Podemos pontuar com as seguintes opções.

Not important (+0 pontos)
Nice-to-have (+1 pontos)
Important (+2 pontos)
Critical (+3 pontos)

O responsável pelo board de demandas é quem dita a pontuação, pois conhece a estratégia da empresa, possuí empatia com os usuários dos sistema, ou seja, tem uma linha/padrão de pontuação e que deve ser respeitada para todas as demandas.

Fazendo uma análise simples, para a demanda do **Fulano**, eu daria a pontuação: **Nice-to-have (+1 ponto)**, me parece que não é algo que faça com que o usuário deixe de usar o meu produto, ou que impeça ele de realizar as principais tarefas que o meu software se propõem a fazer, mas pode ser uma melhoria bacana no futuro.

Para a demanda do **Ciclano**, entendo que o mesmo não consegue finalizar um fluxo importante que o meu produto se propõem a resolver, sendo assim, existem motivos para que o usuário se sinta insatisfeito com o produto ao ponto de cancelar, por isso, minha pontuação seria: **Critical (+3 pontos)**

Agora sim, temos uma demanda de inclusão de data de nascimento no cadastro do cliente mapeada, categorizada e com UIS de 4 pontos.

Fazendo isso com todas as demandas teremos uma visão macro do que é mais demandado pelos usuários, fornecendo assim um norte de evolução para o produto.

Então agora é só escolher a demanda com mais pontuação e desenvolver? Nem sempre é tão fácil, outras variáveis devem ser levadas em consideração, como tempo, custo, esforço, assunto para outro post também. =)

Fiz um post um tempo atrás sobre [Funil de conversão - Validando um MVP](https://dev.to/convenia/funil-de-conversao-validando-um-mvp-1393), acredito que pode agregar bastante no processo.

Além disso conseguimos atacar um pouco a questão de levar visibilidade para o restante da empresa sobre o que está sendo feito.

Veja abaixo um relatório de uma Sprint de desenvolvimento com a evolução do UIS aqui no [Convenia](https://convenia.com.br). Separando por áreas temos:

![Evolução](https://dev-to-uploads.s3.amazonaws.com/i/eohuwj4hlivcvo3wpgeq.png)
 
- bloco rosa claro antes de iniciar a Sprint
- bloco roxo após o término da Sprint

Na imagem fica claro que: o time trabalhou fortemente em demandas relacionadas ao segundo bloco, saindo de 242 pontos de UIS para 212, diminuindo as demandas e evoluindo o produto em uma áreas específica do sistema.

Com isso, temos o básico do básico para iniciar uma priorização de produto e apresentar resultados. O que achou?

Em caso de dúvidas fico a disposição =)

Além disso estamos sempre com vagas para o time de produto [https://convenia.gupy.io](https://convenia.gupy.io)

Abs