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?

Continue 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.

Personas: Chegando ao cerne do negócio com um mapa de empatia

TIPS FROMSUCCESSFULPEOPLE.

Em contextos voltados ao sucesso do cliente, uma das abordagens mais populares para mapear requisitos de cliente é o Mapa de Empatia, para mapear as personas.

Mas o que é isso?

Personas são personagens fictícios criados para representar os diferentes tipos de usuário dentro de um alvo demográfico, atitude e/ou comportamento definido que poderia utilizar um site, uma marca ou produto de um modo similar. Personas são uma ferramenta ou método de segmentação de mercado. O termo persona é usado amplamente em aplicações online e tecnológicas, bem como em publicidade, onde outros termos como retratos de pena também podem ser usados. (Wikipédia)

Tá, entendi. Então vamos criar personagens fictícios para representar usuários? Sim!!! E por que se faz isso?

Continue lendo “Personas: Chegando ao cerne do negócio com um mapa de empatia”

Sobre o PMBOK Ágil (Por Jorge Audy)

Fiz vários posts nas redes desde que as primeiras resenhas sobre o PMBOK 6ª edição começaram a sair, mas não aqui no blog para registro. Não é um passo a frente, é apenas o resgate de um gap de 30 anos, desde o mítico artigo de Takeushi e Nonaka em 1986 com “The New New […]

via PMI Agile Practice Guide – boas práticas ágeis há 30 anos — Jorge Horácio “Kotick” Audy

Utilizando Canvas para entender melhor seu produto

Dando uma pausa..pngJá é uma prática de mercado utilizar canvas para obtenção de dados para o que quer que seja, já vi scrum team canvas, machine learning canvas… Tem Canvas para todos os gostos. O canvas acabou caindo no gosto dos analistas, product owners e demais profissionais do mercado porque facilita o entendimento de todas as partes e direciona um brainstorm, por exemplo.

Uma das estratégias comuns para entendimento do produto (e da visão da empresa), são os Business Model Canvas e o Product Vision Board.  Vou focar, hoje, nestes dois canvas.

Continue lendo “Utilizando Canvas para entender melhor seu produto”

PO Proxy – PO Linha

 

BusinessAnalystAsProxyProductOwner

“O Product Owner é aquele que determina as metas e conduz o time na entrega constante de valor” (Cohn, 2009, Succeeding with Agile)

Recentemente assumi um projeto (iniciado a 3 meses por um fornecedor em metodologia tradicional), e projeto apresentava a cada status report a dependência/premissa de ter declarado o PRODUCT OWNER, mas neste caso leia-se dono do projeto, a pessoa que aprova ou não as entregas.

Para o fornecedor essa pessoa deveria ser alguém da área de negócios, e por isto foi apontado um gerente de uma área de negocio, que além de todas as suas atividades diárias ele deveria também tocar as atividades deste projeto (o profissional atribuído a este papel deveria estudar o produto, testar conceitos e construir o produto).

Scrum Guide , uma das referências do assunto, descreve o PO como:

“É o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. (…)

Sendo o “Product Owner uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.”

Cerejinha do bolo, este projeto possui duas áreas de negócios envolvidas (Limão e Laranja e por este motivo não será possível UM Product Owner.

Qual a probabilidade destes DOIS gerentes quererem assumir mais uma função, com uma parte da atividade que eles desconhecem, de um projeto já iniciado e que ele não tinha conhecimento do escopo que foi fechado?

O PO neste cenário é o que chamamos de “cliente”, ele tem noção do que o produto precisa solucionar, mas não tem conhecimentos técnicos para realizar testes, cuidar da evolução do produto e dar diretrizes para o time (pensando na questão técnica), principalmente, sendo dois clientes com objetivos distintos dentro do produto.

Quando me coloquei a par do projeto sugeri trazer uma “nova” função/papel para o projeto, um PO LINHA (tem quem conheça essa função como PO Proxy), essa pessoa tem o perfil de um analista de negócios/requisitos que prepara todo o material (escreve user stories (traduz as necessidades do cliente – E ELE É TIME!), deixa as estórias em critério de ready para inicio da Sprint, declara os critérios de aceite das histórias, faz a ponte com o time) tudo isto em conjunto com os Product Owners do projeto, neste caso os gerentes das áreas de negócio.

Esse caso que estou contanto é recente e tem 10 dias que se iniciaram as atividades e venho contar aqui as evoluções de 2 semanas:

                – O Product Owner consegue tocar todas as suas atividades diárias e o projeto não é considerado um peso (declaração do próprio PO)

                – O PO linha já apresentou as regras de negócio para a primeira Sprint para que o Product Owner valide e dê o seu de acordo (DOR/DOD) e já estamos trabalhando nas histórias de 2 Sprints a frente.

Organize. (3)

4 Livros sobre AN e Scrum que vão revolucionar seu dia-a-dia

Volta e meia venho aqui e posto a capinha de um livro. Hoje resolvi compilar uma série de títulos que acho relevantes para a área de negócios, requisitos e cultura ágil.

Vamos ao primeiro deles:

Apesar de Casos de Uso estarem fora de moda, Alistair Cockburn explora neste livro vários níveis de abstração em requisitos. Se você trabalha com requisitos, seja em times ágeis ou times tradicionais, este livro com certeza é uma boa pedida.

Jeff Sutherland, um dos criadores do Scrum, ensina como usar Scrum pra fazer qualquer coisa. Ele até me inspirou a escrever este artigo.

No livro Gamestorming, existem diversas dinâmicas para reuniões, que podem transformá-las em verdadeiros Games. Com objetivo definido e tempo restrito, a produtividade cresce! Vale a pena ter como livro de referências.

E por último, mas não menos importante:

O BABOK contém importantes referências sobre o mundo da análise de negócios e também requisitos. Vale a leitura completa e depois ter como livro de referência.

E você, tem algum livro pra acrescentar nessa lista? Vamos dividir!

 

curte-compartilha

Uma forma eficiente de escrever user stories

Em outro artigo, escrevi sobre o framework para requisitos ágeis. De fato, ele não existe. Existem boas práticas, como o INVEST e também sempre consultar o time a respeito da abordagem da documentação.

Aliás, a abordagem do analista de negócios é uma boa prática segundo o BABOK.

Tá vendo? Ali, 3.1: Plan Business Analysis Approach. É a forma como você vai conduzir as atividades de análise de negócio. Fechar com seu time o que ele precisa para desenvolver o produto passa pelo planejamento da abordagem do PO ou Analista, e também é refinado através de groomings, o que significa que a abordagem pode mudar de acordo com novos aprendizados.

Uma forma de ser assertivo na escrita de uma User Story é respeitar as 7 dimensões do produto: Continue lendo “Uma forma eficiente de escrever user stories”