Baralho de Métricas

Há um tempo, montei esse baralho de métricas pra você conseguir se encontrar e começar com suas primeiras métricas 🙂

Você pode imprimir e levar com você!

Clique no link abaixo para fazer o download!

Me conta aqui nos comentários o que você achou? Viu esse baralho na palestra do TDC? Me conta 😉

SPIDR – Abordagem para divisão de histórias de usuário

Você conhece a abordagem de quebra/divisão de histórias do Mike Cohn? O SPIDR é um acrônimo para Spikes, Paths, Interfaces, Data e Rules, e são abordagens para divisão de histórias em partes menores.

Tomei a liberdade de traduzir o material em inglês, espero que seja útil.

Você sabe o que é fatiar?

(Postado originalmente no meu LinkedIn)

Você sabe o que é fatiar?
Fatiar é uma técnica que visa a entrega de produtos menores, a fim de validar um experimento (se o produto atende ao problema de um cliente).
Os motivos e benefícios do fatiamento são vários:
-> Ter melhor gestão visual das pequenas partes que compõem o produto e como elas estão dentro do fluxo do time;
-> Possibilitar ciclos curtos de feedback (o mais curtos possível);
-> maior gestão de riscos e menos surpresas;
-> Melhor previsibilidade das entregas.
O fatiamento (do inglês “Slice”) deve ser feito no nível estratégico e de release, sempre com métricas baseadas na hipótese.
A quebra de histórias (do inglês “Rock Break”, “Split”) deve ser feita no nível de backlog, também para objetivos similares. (Referências: Jeff Patton’s User Story Mapping, Mike Cohn’s SPIDR approach to splitting user stories)

fatiar

Como acompanhar o ROI?

Depois de falar um pouco sobre Métricas e Retorno sobre o Investimento, vamos falar um pouquinho mais sobre como acompanhar o ROI de um produto ou serviço. Pra isso, vou trazer aqui pro palco, ninguém menos do que Dave McClure pra trazer as Métricas do Pirata.

Então, o que são as Métricas do Pirata? São elas que medem o comportamento do seu cliente durante o Ciclo de Vida dele em contato com seu produto. Como assim?

Continuar lendo “Como acompanhar o ROI?”

Métricas: Quais delas você usa para verificar a saúde do seu produto?

Quando estamos fazendo gestão de produtos, esta pergunta é bem comum: Como eu verifico e checo a saúde do meu produto utilizando métricas?

Quais métricas devo considerar? Todas as métricas possíveis? Algumas? Como ser mais assertivo em relação  a elas?

Primeiramente…

Uma métrica (ou várias delas) tem como objetivo medir a saúde de um problema que você está resolvendo. Leia-se problema como uma “dor do negócio” ou “oportunidade de negócio”. Leia aqui sobre problemas e oportunidades.

Uma vez definida a hipótese sobre o problema que você está resolvendo, chega a hora de definir as métricas. Na minha visão, existem métricas de nível operacional e de nível mais macro, que atingem necessariamente os resultados da empresa.

Eficiência ou Eficácia?

Como donos de produto, temos como dever perseguir as métricas de eficácia, mas nunca nos esquecer que as métricas de eficiência colaboram para a melhoria das métricas de eficácia e a nossa aproximação dos resultados de forma cada vez mais ágil. Não sabe do que tô falando? Se liga:

4Dominios_palavras
Fonte: K21

Pois bem, as métricas de negócio são responsáveis por medir a Eficácia, e as métricas organizacionais são responsáveis por medir a Eficiência. Combinado?

Entendi. Mas como é que vamos medir a Eficácia? Como é que eu sei que estou sendo eficaz com meu produto?

ROI

Você sabe o quanto está investindo no seu time? Por quantas pessoas ele é composto? Quanto custa este time?

Seu produto faz vendas diretas? É vendido? Monetizado? Qual o total de vendas que seu produto faz ou fará?

Seu produto facilita uma venda? O Quanto ele facilita essa venda? Quantas vendas seu produto ajuda a fazer?

Estes são exemplos de retornos de investimento direto que um produto pode gerar.

Como calcular um ROI?

ROI = [(Retorno – Investimento)/Investimento]*100

 

Cost of Delay

Cost of Delay é uma métrica que ajuda a tangibilizar o risco de não fazer determinada feature ou produto. Basicamente, o Cost of Delay mostra, caso um produto não possua ROI direto, formas de medir o impacto que um problema não resolvido pode ter. O Cost of Delay também pode ser usado juntamente com o ROI.

Dessa forma, Cost of Delay pode tangibilizar casos de:

  • Aumento de Receita
  • Proteção de Receita
  • Prevenção de Custo
  • Redução de custos

Como calcular o Cost of Delay?

Verifique qual o problema atual, exemplo: Quantos clientes eu posso suportar com a aplicação atual? Quantos clientes eu posso suportar com a aplicação nova?  Quanto de faturamento traz cada cliente? Quanto de faturamento eu terei com mais clientes?

A Diferença encontrada será o Cost of Delay.

O universo de métricas é extenso e estou mergulhando nele agora 🙂 Para que o post não fique também muito grande, pretendo criar alguns vários dedicados a esta disciplina.

Deixe aqui sua dúvida, comentário, vamos trocar! Eu te ajudo com o que aprendi e você me ajuda a pesquisar e entender coisas novas. Combinado?

Problemas e Oportunidades

No dia-a-dia de quem trabalha com produto, é frequente a pergunta: “Mas qual problema você está resolvendo?” e essa simples pergunta pode confundir o transeunte que acaba de chegar no meio.

O problema que você está resolvendo tem muito a ver com a hipótese que você está trabalhando.

MAS PRI DO CÉU SÓ COMPLICA! ISSO QUE EU TÔ TRABALHANDO NÃO É HIPÓTESE, É UMA DEMANDA REAL!!!!!111

Disse o PO transeunte…

Sobre hipóteses:

Toda iniciativa começa com uma hipótese. E a premissa de toda iniciativa é:

Este produto pode/deve ser construído? Qual o resultado de valor esperado desta iniciativa?

Quantas vezes você já viu um produto no mercado que não fazia muito sentido? Quantas vezes você viu uma demanda sendo atendida para um “total de zero pessoas”?

Uma hipótese abraça o conceito de que toda demanda merece um olhar atento e precisa resolver um problema. Portanto, toda iniciativa carrega em si o fato de que são apenas apostas, suposições de que algo vai dar certo.

MAS DAÍ PRI, ENTÃO A GENTE PODE SAIR TESTANDO?

Nossa missão aqui é reduzir o risco dessa hipótese. Mas como?

Sabendo qual problema estamos resolvendo.

A iniciativa é composta de três conceitos:

Output > Outcome > Impact

Onde output é a saída do seu produto, outcome são as métricas operacionais do seu produto, e impact são os resultados para o negócio.

Por exemplo

Output: Entreguei uma nova área de ofertas

Outcome: Rendeu 10000 visualizações e 1000 cliques no primeiro mês de vida

Impact: Ajudou a monetizar 1000 clientes no primeiro mês, trazendo R$ 5000,00 de incremento de faturamento.

Declarando em palavras esta hipótese, vou deixar aqui a colinha:

Nós acreditamos que será alcançado este

[outcome de negócio]

se [este usuário]

conseguir com sucesso [seu outcome de usuário]

com [esta funcionalidade].


Saberemos que isto é verdade se observarmos este feedback:

1) qualitativo e/ou

2) quantitativo e/ou

3) alteração em algum indicador/KPI.

Então, independente se um problema (dor já existente) ou oportunidade (resolvendo um problema futuro para obter algum resultado), as hipóteses nivelam esse conceito para que possamos acompanhá-las da mesma forma.

Workshop: Scrum na Prática, com Lego

É com muito orgulho que anuncio: Estou lançando meu primeiro workshop, de Scrum na Prática, com Lego!

Mas não se engane, diversos pilotos já foram realizados e posso garantir duas coisas:

  • A vivência de um ambiente ágil e
  • Muita diversão!!!

 

Desta vez, reservei um espaço bem bacana na Via Academy para fazermos nossas brincadeiras! Se interessou? Inscreva-se já no link:

Quero Participar!