O cinto de utilidades do Product Manager
O Batman não é o mais forte, nem tem os poderes do Super-Homem ou de qualquer outro super-herói, mas certamente é um dos personagens mais inteligentes e um especialista na resolução de problemas impossíveis; o melhor detetive e escapista do mundo da DC Comics. Sobrevive à queda de prédio ou avião, sai de cofre e desarma uma bomba, ou ainda se livra das algemas dentro de uma caixa jogada no fundo do mar, entre outros desafios. Um super-herói que ficou marcado por conta de sua sagacidade, bravura, habilidades como lutador e, principalmente, pelo uso de suas incríveis traquitanas tecnológicas.
Cinto de utilidades do Batman
Para combater o crime organizado, super vilões e até duelar com outros heróis, além das habilidades já conhecidas, o homem morcego usa seu famoso e misterioso cinto de utilidades que, entre outros poderosos artefatos, contém o polêmico anel de kryptonita (métricas de produto), que quando é usado com destreza, pode proteger o seu produto das intermináveis opiniões sem dados dos Super HIPPOs — Highest Paid Person’s Opinion (Opinião da pessoa mais bem paga da empresa).
Mas pouco adianta carregar um cinto tão poderoso se você não souber para que serve cada uma de suas utilidades, quando devem ser acionadas e, principalmente, como devem ser utilizadas. Por exemplo, ao cair de um prédio, Batman tem poucos segundos para escolher e utilizar com destreza uma das utilidades e assim impedir a sua queda.
Ele sabe que se cometer um erro poderá colocar a sua vida em risco, assim como de outras pessoas. Por isso é um especialista no manejo das utilidades de seu cinto e está sempre treinando, aprendendo, em processo de melhoria contínua.
Product Managers
Assim como o Batman, o profissional de produto precisa saber identificar e escolher alvos, gostar de resolver problemas, ter senso de urgência e fazer escolhas difíceis (tradeoffs*) durante seu dia a dia de trabalho. A expectativa com o produto é sempre grande, assim como a cobrança pelo seu crescimento e a urgência pelos resultados.
“Quando vamos mexer o ponteiro? Quando sobe essa funcionalidade? Precisamos de um cronograma…”. Algum PM aí já ouviu algo parecido?
Sempre que as iniciativas de produto dão certo, o mérito é do time, com razão, mas quando dão errado é o CPF do Product Manager que paga a conta. Pode parecer exagero ou mesmo injusto, mas é o PM que vai ter que prestar contas da evolução do produto com todos envolvidos.
Aliás, pressão, críticas e cobranças de todos os lados fazem parte do nosso dia a dia quando trabalhamos com Product Management.
“O Product Manager é uma espécie de herói às avessas” (Arthur Castro), onde:
“Com grandes responsabilidades, não vem nenhum poder” (Dan Olsen):
Sendo ou não um herói (você não é), lembre-se que a cadeira de Product Manager é muito nova e todos nós estamos aprendendo, em construção, em processo de melhoria contínua. Cada produto, time, empresa, cultura e clientes sempre será uma nova e desafiadora jornada, inclusive para profissionais experientes. Até mesmo as empresas que nasceram com agilidade em seu DNA e que conquistaram uma certa maturidade em Product Management, ainda estão azeitando seus processos e cultura na criação de produtos digitais de qualidade. E o que podemos dizer da grande maioria das empresas que está em processo de transformação digital, passando por um longo, difícil e doloroso processo de mudança?
A boa notícia é que com o tempo e experiência, erros e acertos ao longo da caminhada, vamos aprendendo a fazer melhores escolhas, minimizar riscos, antever alguns problemas, incluir os atores certos no jogo e alinhar expectativas, principalmente com os stakeholders*.
Mas é importante deixar claro que em Product Management não há certezas, verdades absolutas, receitas de bolo, atalhos, mapas da mina ou frameworks milagrosos que garantam que as iniciativas de produto vão funcionar. Vivemos em um mundo de incertezas, sem garantias e, que no final do jogo, parte significativa do nosso trabalho é aumentar a probabilidade de sucesso das iniciativas de produto.
Mas faz parte da brincadeira cometer erros, certo? Sim, podemos e devemos correr riscos “controlados” e cometer erros, mas isso não exclui a responsabilidade do Product Manager em mitigar os riscos, testar, rodar experimentos e (in)validar as hipóteses o quanto antes, além acompanhar de perto os resultados das iniciativas de produto. É fundamental saber o que está acontecendo com seu produto, como e por quê estão dando certo ou errado, para, se necessário, mudar a sua trajetória, “pivotar”* o produto quanto antes.
Se não sabemos ao certo o que está acontecendo com nosso produto, provavelmente voltaremos a cometer os mesmos erros do passado e não resolveremos os problemas em sua causa raiz, mantendo vivo o ciclo do Product Manager bombeiro, sempre apagando incêndios e continuaremos sob a cobrança e influência dos achismos dos HIPPOs.
Todo produto é impactado por inúmeras variáveis, como a inclusão de novas funcionalidades, mudanças no produto, campanhas, promoções, performance, eventos, sazonalidades, destaques, recomendações positivas ou negativas, erros, mudanças no mercado, concorrência, entre tantas outras variáveis, por isso, saber identificar o que está acontecendo, como e por quê, é de longe um dos mais desafiadores e importantes superpoderes do Product Manager.
Trabalhamos com hipóteses e faz parte do processo de desenvolvimento de produtos (in)validar ideias geniais, acabar com achismos, despriorizar funcionalidades desnecessárias e parar com o infinito copy & paste das modinhas ou de algum paradigma do mercado, só porque ele lançou algo que nosso produto ainda não tem.
Alvo certo!
Errar está incluído no processo de desenvolvimento de produtos, entretanto, uma coisa é invalidar hipóteses e outra é tomar decisões orientadas por dados errados (qualitativos e/ou quantitativos), enviesados ou mal interpretados. Pior do que a falta de informações, é ser orientado por dados incorretos e acabar investindo tempo e esforço em um alvo errado.
Se o Batman utilizar errado as utilidades de seu cinto, o resultado será desastroso. E o mesmo vale para o Product Manager, que deve tomar decisões de produto baseadas em métricas quantitativas e qualitativas corretas, sem vieses.
Se for para gastar tempo e energia no alvo errado, melhor não atirar.
É natural querermos tentar validar uma hipótese “genial”, que acreditamos muito, nem que para isso tenhamos que empurrar as métricas contra a parede, dar na cara delas e fazer com que cantem a música que queremos ouvir, não a música que o nosso produto precisa. Ao tentar validar algo, mesmo que não seja de forma intencional, acabamos validando a hipótese, de um jeito ou de outro, mas totalmente enviesada.
Como alternativa, deveríamos tentar invalidar as hipóteses, assim como faz a academia e, se não forem invalidadas, são grandes as chances de serem válidas. Essa é uma mudança importante de cultura, não somente do Product Manager, mas de todo o time. Ainda nessa linha de raciocínio, recomendo o artigo: Testar para aprender, não para validar.
E como disse o mestre e amigo Huxley Dias ao ler o artigo, "e sempre se certificar de que cada hipótese esteja associada com objetivo do time squad/tribo, e com a métrica que pretende mexer muito bem definida. É comum ver muitas hipóteses que se desprendem dos objetivos (OKRs) do time, um grande indicativo que a energia está sendo posta no local errado.
E mesmo as empresas grandes e com fôlego financeiro não podem perder tempo, energia e dinheiro dobrando apostas em alvos errados, mas para as pequenas, os tiros na água podem colocar as suas existências em jogo.
O que, como e por quê isso está acontecendo com meu produto?
Fica a cargo do Product Manager a direção para onde o produto está indo e a priorização dos problemas que serão resolvidos, sempre orientados pelas métricas quantitativas e qualitativas, dados da indústria, oportunidades de mercado, objetivos do negócio, dores dos clientes, viabilidade técnica, esforço e os erros e acertos do passado.
E se você não está acompanhando de perto as métricas e priorizando as iniciativas do seu produto, certamente alguém está fazendo isso por você.
A única maneira do Product Manager não virar um Proxy* (um tirador de pedidos), é acompanhar de perto o que está acontecendo com seu produto, como e por quê? Sem essas informações, o Product Manager fica 100% vulnerável aos achismos e as vontades alheias.
A falta de métricas é sem dúvida o caminho mais rápido para o ciclo de morte do produto, onde os clientes e Stakeholders solicitam novas funcionalidades e mudanças no produto, uma atrás da outra, os times constroem as features (funcionalidades), mas como elas não resolvem de fato um problema, acabam não sendo utilizadas pelos usuários.
Como o produto não vai melhorar, voltamos a receber pedidos e novas funcionalidades serão implementadas, aumentando assim exponencialmente a complexidade da experiência do usuário, performance do produto, manutenção, etc. É o ciclo de morte do produto.
Produto XPTO
Uma forma de parar esse fluxo é utilizar as métricas do produto como norte para priorizar o que é de fato importante, (in)validar hipóteses e se livrar de ideias mirabolantes e pedidos sem fundamento.
E para materializar algumas das métricas que podem nos informar o que está acontecendo com o produto, como e por quê, vamos usar como exemplo um produto fictício que chamaremos de XPTO.
XPTO é um aplicativo de música freemium bem parecido com o Spotify, com opção de assinatura mensal para eliminar as propagandas do aplicativo e liberar funcionalidades adicionais.
Como saber O QUE está acontecendo com o aplicativo de música XPTO?
Quem vai responder o que está acontecendo são as métricas quantitativas: absolutas e relativas, como, por exemplo:
- Quantidade de Downloads do produto.
- Quantidade de usuários ativos no dia (DAU — Daily Active User), na semana (WAU) e no mês (MAU)
- Número de desinstalações do aplicativo.
- Quantidade de novos usuários
- Percentual de usuários que criaram uma conta.
- Percentual de usuários que iniciaram uma versão Trial (experimentaram a versão Pro por um período de tempo determinado)
- Percentual de usuários que assinaram a versão paga
- Quantidade de cancelamentos (assinaturas) por dia, semana, mês (Churn)
- Tempo médio de sessão
- Funcionalidades mais utilizadas
- % de Crash Free Users (percentual de usuários livres de crashes, quando o aplicativo fecha do nada e o usuário precisa reiniciar o aplicativo)
- Funil de conversão
Entre tantas outras métricas que nos dizem o que está acontecendo com nosso produto/aplicativo e o que os clientes estão fazendo.
COMO isso está acontecendo com o XPTO?
Quem vai responder como seus usuários estão utilizando seu produto, são as dimensões de produto, técnicas, negócio, comportamentos, demográficas, temporais, Coortes, entre outras.
Segmentações, como, por exemplo:
- Dos usuários novos, 20% possuem iPhone (iOS), 80% são Android.
- Apesar de somente 25% da base, os usuários de iOS representam mais de 50% da receita mensal recorrente.
- 50% dos usuários que iniciam o Trial na primeira semana assinam o produto. No iOS esse percentual é de 68%.
- 70% dos assinantes são do gênero feminino, 42% da cidade de São Paulo.
- O tempo de sessão dos usuários assinantes é 75% maior do que dos outros usuários.
- Os usuários que escolheram fazer parte de uma comunidade no seu primeiro dia de uso, ou seja, no D0 (D zero), têm 60% de retenção no dia seguinte ao primeiro acesso, no D1. Aqueles que não participaram de nenhuma comunidade no primeiro dia (D0), têm retenção de 39% no dia seguinte (D1).
Obs: O aplicativo de música é de frequência de uso diário, por isso, acompanhamos o Cohort* por dia. Caso fosse um aplicativo de uso semanal, assim como, por exemplo, o Uber, poderíamos acompanhar o Cohort por semana.
- Os usuários que favoritaram três ou mais músicas no primeiro dia de uso (D0) tiveram uma taxa de conversão da assinatura de 18%, enquanto os que favoritaram menos de três músicas no primeiro dia, tiveram apenas 9,8% de conversão.
- A conversão de assinatura de novos usuários indicados por amigos é de 27%.
As dimensões são fundamentais para entender como os diferentes grupos de usuários estão utilizando o produto. Quais são as ações e comportamentos dos clientes fiéis, quais geram mais conversões, receita? Olhar os funis de produto com essas segmentações trazem ótimos insights do que está funcionando, o que pode ser melhorado e o que devemos priorizar.
E POR QUÊ tudo isso está acontecendo?
Com as métricas quantitativas conseguimos saber o que e como nossos usuários estão utilizando nosso produto, mas como saber o que leva os usuários a favoritarem três ou mais músicas no primeiro dia de uso do XPTO? Por que esse público tem retenção e conversão melhor do que os outros usuários? Por que grande parte de seus clientes está desinstalando o aplicativo e/ou cancelando a assinatura, entre tantas outras perguntas sem respostas?
Quem vai esclarecer essas e outras dúvidas são as análises qualitativas, resultado das entrevistas contextuais, grupos de foco, etnografia, testes de usabilidade, testes remotos, rápidos, que além de esclarecer os porquês, ainda nos dão Insights de como resolver os problemas e melhorar o produto.
O que levar no Cinto de Utilidades do Product Manager?
Assim como o homem morcego, o profissional de produto também deve montar seu cinto de utilidades de produto, mas como o Batman, precisa conhecer bem para que servem, quando e como devem ser utilizadas. Nada adianta levar no cinto utilidades que não serão utilizadas nunca, ou serão aplicadas em contexto errado e da forma errada.
Em 2014, Christian Rohrer escreveu o artigo When to Use Which User-Experience Research Methods um artigo onde distribui 20 métodos (utilidades) populares de pesquisa em uma estrutura tridimensional com os eixos:
- Atitudes x Comportamentos
- Qualitativo x Quantitativo
- Contexto de Uso
Na parte superior do gráfico, Rorher agrupou os métodos de comportamentos (Behavioral), que indicam: “O que as pessoas estão fazendo”.
Já na parte inferior do gráfico, reuniu os métodos que revelam quais são as suas atitudes (Attitudinal) e sentimentos, representando: “O que as pessoas falam”.
Na direita do gráfico, compilou os métodos quantitativos, que configuram: “A quantidade, frequência, quanto os clientes pagaram, etc.”.
E na esquerda, os métodos qualitativos, que traduzem: “Por que seus usuários estão fazendo algo e nos dão insights de como consertar”.
As dimensões auxiliam o Product Manager a identificar quais perguntas cada utilidade poderá responder e para quais objetivos elas são mais apropriadas. Essa estrutura pode auxiliar o PM na escolha das utilidades mais adequadas ao seu contexto.
Fazendo uma adaptação do excelente trabalho do Rohrer, distribuímos algumas utilidades (ferramentas, métodos, metodologias e Frameworks) que podem compor o cinto de utilidades dos Product Managers:
Alguns dos métodos são híbridos, como o CardSorting*, por exemplo, que pode ser tanto qualitativo, quanto quantitativo.
Não faz parte do escopo deste artigo passar por todas utilidades do cinto do Product Manager, mas vamos passar por algumas delas para exemplificar cada um dos quatro quadrantes.
Quadrante: Comportamento + Quantitativo
Este quadrante informa, quantitativamente, o que os usuários estão fazendo e como estão utilizando o seu produto. São as métricas que representam os diferentes comportamentos e ações dos usuários sobre seu produto.
Para exemplificar esse quadrante, vamos utilizar a utilidade: funil.
Funil
Os funis são muito úteis para quantificar os fluxos ou as jornadas dos clientes em seu produto, revelando onde há gargalos, se em alguma das etapas do funil os usuários estão “vazando”, ou seja, abandonando o fluxo antes de completarem a ação iniciada. Montar e acompanhar de perto os diferentes funis de seu produto é uma das melhores formas de saber se as otimizações, melhorias e novas iniciativas de produto estão realmente funcionando.
Por exemplo, podemos montar um funil que siga o fluxo de ações dos clientes na tarefa de criar um cadastro de um site/App, iniciando no seu primeiro passo, na criação da nova conta, até o login (identificação) do usuário com sucesso.
Ao acompanhar os principais fluxos no produto pelos seus respectivos funis, somos capazes de analisar o comportamento dos usuários durante a execução de suas tarefas, identificando oportunidades de melhoria, problemas e gargalos.
O objetivo sempre será levar mais clientes para cada uma das etapas do funil e assim aumentar o percentual de clientes que chegam na última etapa e finalizam a tarefa iniciada.
Para exemplificar, vamos imaginar que em um funil de conversão de compra de um ecommerce, dos 20k (20 mil) clientes que visualizaram a página de produto (PDP) em um determinado período de tempo, 20% (4K) dos clientes adicionou produtos ao carrinho de compras.
Destes, 35% (1,4k) decidiram seguir o fluxo de compra e clicaram em finalizar a compra a partir do carrinho de compras.
Mas quando um cliente decide finalizar a compra, antes de seguir para a etapa de endereço e entrega, ele precisa se identificar.
Caso seja novo cliente, terá que criar um cadastro no site/App. Se o cliente já possui conta e está “logado” (identificado pelo site/App), será levado direto para a etapa de entrega. Mas se não estiver “logado”, vai precisar se identificar antes de seguir em frente.
Seguindo o funil, dos 1,4K clientes que passaram pela etapa de identificação (login), somente 30% (420) chegaram na etapa seguinte, de entrega. Ou seja, dos clientes que decidiram finalizar uma compra, 70% não seguiram em frente no funil, parando na etapa de identificação.
É um percentual muito alto e a etapa de login (identificação dos clientes) não deveria ser responsável pelo vazamento de 70% dos clientes no funil de compra. Esse vazamento precisa ser investigado e endereçado o mais rápido possível.
Seguindo o funil, dos 420 clientes que passaram para a etapa de entrega, 80% (336) seguiram para o pagamento. Destes, 78% (242) seguiram de pagamento para etapa de confirmação.
Quadrante: Atitude + Quantitativo
Neste quadrante, os clientes informam, quantitativamente, suas percepções e sentimentos sobre o produto.
Como exemplo desse quadrante, vamos usar a utilidade Reviews, que são as resenhas escritas pelos clientes dos aplicativos, canal bastante relevante de feedback sobre os Apps.
Reviews
Corroborando a hipótese de um problema no login/cadastro identificado no funil de compra, das 2 mil resenhas (Reviews) dos últimos 30 dias nas lojinhas do aplicativo na Google e Apple, o termo cadastro aparece como o principal tema de reclamações nas resenhas.
Com alto volume de Reviews, não é viável fazer essa análise de forma manual, muito menos diretamente pelas lojas da Google e Apple, por isso, recomendamos o agrupamento e análise com auxílio de uma ferramenta extra, por exemplo, o Appbot.co.
Quadrante: Comportamento + Qualitativo
Neste quadrante observamos, qualitativamente, o que os clientes estão fazendo.
Para descobrir por que estamos com problema no cadastro e como vamos consertar, vamos usar a utilidade: testes de usabilidade.
Como os números quantitativos, tanto no quadrante de comportamento, quanto de atitude apontaram, respectivamente, para um grande percentual de abandono de clientes na etapa de cadastro e muitas reclamações negativas sobre o tema, foram aplicados testes de usabilidade com objetivo de identificar o por quê isso está acontecendo?
Nos testes de usabilidade foi observado que, mesmo os clientes mais experientes no uso de aplicativos, tiveram dificuldade na etapa de criação de um novo cadastro.
Foram encontrados achados interessantes, como, por exemplo, a dificuldade apresentada pelos clientes ao entrarem com dados numéricos em um teclado alfanumérico não otimizado. Feedbacks do sistema nada amigáveis durante as interações com o formulário, excessivo número de campos no cadastro, textos com tamanho reduzido e lentidão e erros no sistema na criação da conta.
Quadrante: Atitude + Qualitativo
Neste quadrante, os usuários falam quais são os seus sentimentos com relação ao produto, experiências com e-commerce, dificuldades e atitudes como cliente.
Aqui, para nos ajudar na investigação sobre o problema no cadastro e entender quais as percepções dos clientes na experiência de cadastro, vamos usar a utilidade: entrevistas.
Nas entrevistas, os clientes relataram algumas experiências passadas ruins, onde abandonaram o cadastro em sites/aplicativos de ecommerce por razões como: bugs, excesso de campos, teclado não otimização, usabilidade ruim, falta de login social e tempo elevado para finalizar a tarefa, principalmente em um Smartphone.
Parte dos entrevistados disse gostar de utilizar o login social (redes sociais como Google e Facebook) para criação de cadastros. Alguns disseram que não gostam da obrigação de ter que criar uma conta para finalizar um pedido.
<Atualização>
Ainda sobre os métodos de pesquisa, recomendo o artigo:
Muito além do teste de usabilidade: os vários tipos de pesquisas com usuários em UX
— Por: Fabricio Teixeira
</Atualização>
O super poder do Product Manager
Saber o que está acontecendo, como e por quê, é sem dúvida um dos super poderes que todo Product Manager precisa desenvolver e deve ser usado nas tomadas de decisão de produto. Chega de achismos e os infinitos pedidos de novas funcionalidades que colocam o produto mais uma vez no perigoso caminho do ciclo da morte. É preciso que o PM tenha o controle do leme do produto e consiga priorizar as iniciativas baseadas em dados, endereçando problemas e oportunidades reais, deixando para trás as síndromes de bombeiro e proxy.
Quando abrimos a cortina das métricas e colocamos todos na mesma página sobre o que está acontecendo com o produto e quais são os problemas e dores dos clientes, tudo fica mais claro para o time, pares e stakeholders, de qual caminho devemos seguir, quais hipóteses devem ser testadas, tanto para o produto, quanto para o negócio.
E você, Product Manager, quais utilidades carrega em seu cinto?
#PausaProJabá
Quer saber mais sobre gerenciamento de produto, se liga nos próximos workshops da Product Arena:
Métricas de Produto, com Horácio Soares e Gustavo Esteves
Tecnologia para PMs e UX Designers, com Mauricio Brizoti
UX Writing, com Bruno Rodrigues
Product Manager, com Arthur Castro e Horácio Soares
Product Discovery, com Rafael Louzada e Rafael Xavier
Use o cupom “productarena” para ganhar 10% de desconto.
Glossário
ARPU (Average Revenue Per User):
Em português, receita média por usuário.
Métrica que indica o quanto cada um dos clientes gasta durante um determinado período. Para calcular, basta dividir a receita média por cliente pela quantidade de clientes.
CardSorting:
Técnica de pesquisa para compreender como o usuário classifica informações de um sistema e como nomeia as categorias por ele criadas.
O participante é convidado a criar pilhas de cartões, agrupando-os de acordo com o que faz sentido para ele. O card sorting pode ser aplicado em papel, com cartões, ferramentas de software ou online.
— Por Luiz Agner — Cards de Produto
Churn:
É uma métrica que aponta o número de clientes que deixaram de fazer negócios com a empresa em um determinado período de tempo.
Cohort:
É a análise do comportamento de um grupo de pessoas através do tempo, tendo como base uma métrica (sessão, ARPU*, cadastro, etc). Muito utilizada em estudos de retenção e de engajamento ao longo dos dias. Em análises mais complexas, é possível ter insights sobre tempo que um visitante leva para fazer uma compra ou o Life Time Value* esperado de uma campanha.
— Por Jéssica Blando — Cards de Produto
Framework:
No contexto de produto, é um conjunto de conceitos usado para resolver um problema de um domínio específico.
— Por Wikipedia
Em tecnologia, Framework:
"… é uma estrutura que serve de base para a construção de aplicações web de finalidade específica cujo desenvolvimento pode ser muito custoso e/ou problemático.
Com um framework é possível construir sites, aplicativos e softwares a partir de um esqueleto pré-definido, alterando apenas demais particularidades." Kenzie
No viés da tecnologia, vou usar a dica genial do mestre @mauriciobrizoti para explicar o que é um Framework.
O Peru da Sadia já vem com um tamanho padrão, depenado, limpo, temperado, congelado e com um Timer para indicar quando está pronto e no ponto para servir.
Mas será que o tempero atende todos os gostos? Será que eles usam hormônios para fazer o peru crescer rápido? É saudavel?
Enfim, um FrameWork pode ser útil para: .
- Times que estão aprendendo uma nova tecnologia
- Precisam validar uma hipótese
- Time-to-market
- Redução de custos
- Padronização, …
Mas… .
- Não vai atender todos os contextos do produto.
- É difícil de customizar.
- A performance pode deixar a desejar.
- Pode virar uma muleta.
- Não fazem milagres
- Pode não escalar
- Depende de terceiros e pode ser descontinuado do dia para a noite…
Usem um Framework com cuidado e moderação.
LTV (Lifetime Value):
Determina o valor de um cliente para uma empresa, ou seja quanto em média seus clientes geram de receita durante a experiência com sua marca. Cálculo simplificado: ticket médio X número de vezes que a receita é gerada. Se um cliente em média gasta R$80 por mês com a sua empresa e fica em média 3 anos o LTV é R$80x12x3=R$2880.
— Por Isabella Maringoni — Cards de Produto
OKR (Objectives and Key Results ou Objetivos e Resultados-Chave):
OKR é uma metodologia, responsável por trazer engajamento trimestral, dando visibilidade para onde você deseja ir e como você saberá que chegou ou não lá.
— Por Bernard De Luna — Cards de Produto
Pivotar:
É uma mudança importante no modelo de negócio ou produto com o objetivo de aproximar o produto às necessidades dos usuários ou ao mercado de atuação. Isso ajuda a empresa a conhecer novas formas de melhorar seus produtos e/ou serviços.
— Por Alexandre Marones — Cards de Produto
Proxy:
Em redes de computadores, um proxy é um servidor que age como um intermediário para requisições de clientes solicitando recursos de outros servidores.
— Por Wikipedia
Mas no contexto de gerenciamento de produto, um Product Manager Proxy é aquele que atua de forma limitada, mais como um tirador de pedidos, um leva e traz. Não toma decisões de produto.
Stakeholder:
Em um contexto de gerenciamento de produto, stakeholder pode ser qualquer pessoa ou grupo de pessoas que:
- Tenham interesse no produto e em seu sucesso
- Pode influenciar as decisões do produto.
- São impactados (direta ou indiretamente) pelo produto
— Por ProductPlan
Tradeoff :
Uma decisão que consiste na escolha de uma opção em detrimento de outra.
Trial:
É o teste de um produto ou serviço por um tempo determinado.
—
Chegou até aqui? Se conseguiu ler esse testamento inteiro, não deixe de dar sua opinião… :)
