16 mapas mentais para gerenciamento de produto.

Mapas mentais para gerenciamento de produto são expressões simples de processos ou relacionamentos complexos. Esses modelos são acumulados ao longo do tempo por um indivíduo e usados ​​para tomar decisões mais rápidas e melhores.

Por exemplo: o Princípio de Pareto afirma que aproximadamente 80% de todos os resultados são provenientes de 20% do esforço.

No contexto do gerenciamento de produtos, o modelo sugere que, em vez de tentar criar 100% da oportunidade do cliente, convém procurar como que com 20% de esforço conseguir alcançar 80% das oportunidades. As equipes de produtos fazem essa troca o tempo todo, e os resultados geralmente são lançamentos de features, onde 20% dos clientes com casos de uso mais complicados não são contemplados.

Os modelos mentais são poderosos, mas sua utilidade é limitada aos contextos dos quais foram extrapolados. Para combater isso, você não deve confiar em um ou mesmo em alguns modelos mentais. Em vez disso, deve construir continuamente uma treliça de modelos mentais que você pode usar para tomar melhores decisões.

Esse conceito foi popularizado por Charlie Munger, o famoso vice-presidente da Berkshire Hathaway, em um discurso em que refletiu sobre como obter sabedoria:

Qual a sabedoria popular? Bem, a primeira regra é que você realmente não pode saber de nada se apenas se lembrar de fatos isolados e tentar revidá-los. Se os fatos não se encaixam em uma treliça de teoria, você não os tem de forma utilizável.

Você precisa ter modelos em sua cabeça. E você precisa organizar sua experiência – indireta e direta – nessa treliça de modelos. Você deve ter notado alunos que apenas tentam se lembrar e reprimir o que é lembrado. Bem, eles falham na escola e na vida. Você precisa ter experiência em uma treliça de modelos em sua cabeça.

Quais são os modelos? Bem, a primeira regra é que você precisa ter vários modelos – porque se você tem apenas um ou dois que está usando, a natureza da psicologia humana é tal que você tortura a realidade para que ela se ajuste aos seus modelos, ou pelo menos você pensará que sim. Você se torna o equivalente a um quiroprático que, é claro, é o grande boob na medicina.

Charlie Munger

É como o velho ditado, “Para o homem com apenas um martelo, todo problema parece um prego”. Mas essa é uma maneira perfeitamente desastrosa de pensar e de se operar

Este não é um post apenas para gerentes de produto, mas sim, para todos que trabalham com produtos. Pensar com foco em produto não é sagrado para o papel de um PM, na verdade, é ainda mais útil nas mãos dos construtores do que os MPs. (Inclusive, segue um artigo sobre principios do gerenciamento de projeto que podem ser aplicados por gerentes de produto).

Os modelos mentais que abordarei estão estruturados nas seguintes categorias:

• Descobrir onde investir.
• Design e Escop.
• Lançando e Iteração.

• Descobrir onde investir

O primeiro conjunto de modelos mentais é útil para decidir a proxima feature que sua equipe deve construir, ou “investir”.

1. Retorno do investimento

Um conceito do mundo das finanças: para cada dólar investido, quanto você está recebendo de volta? No produto, pense nos recursos que você tem (tempo, dinheiro, pessoas) como o que está “investindo” e o retorno como impacto nos clientes.

Como é útil: Nesse mapa mental para gerenciamento de produto, os recursos disponíveis para uma equipe de produto são tempo, dinheiro e [o número e a habilidade das] pessoas. Ao comparar possíveis projetos que você poderia assumir, sempre escolha o que maximiza o impacto nos clientes para cada unidade de recursos que você possui.

2. Valor / Tempo de lançamento

O produto que foi lançado mais rapidamente vale mais para os clientes do que o produto lançado posteriormente.

Como é útil: Ao decidir entre problemas / oportunidades para investir, você não pode apenas comparar os benefícios de diferentes features que poderia criar (se o fizesse, sempre escolheria a maior/melhor).

Em vez disso, para tomar boas decisões de investimento, você também deve considerar a rapidez com que essas features serão lançadas e colocar mais valor nas que serão lançadas mais rapidamente.

3. Horizonte do Tempo

Em relação ao valor/tempo de lançamento, a decisão de investimento correta muda com base no período para o qual você está otimizando. Dado um horizonte de tempo suficientemente longo, o custo de desenvolvimento de 3 meses versus 9 meses é insignificante.

Como é útil: Optar por perguntar “Como podemos criar o maior impacto nos próximos 3 meses?” Ou “Como podemos criar o maior impacto nos próximos 3 anos?” Resultará em decisões dramaticamente diferentes para sua equipe.

Segue-se, então, que o alinhamento com sua equipe e as partes interessadas sobre o horizonte de tempo a ser otimizado geralmente é a primeira discussão a ter. Dica: como apresentar seu roadmap para os stakeholders do projeto.

4. Valor Esperado

Prever o futuro é imperfeito. Em vez disso, todas as decisões criam probabilidades de múltiplos resultados futuros. A soma ponderada pela probabilidade desses resultados é o valor esperado de uma decisão.

Como é útil: Ao considerar o impacto de um projeto, mapeie todos os resultados possíveis e atribua probabilidades. A variabilidade dos resultados geralmente inclui a probabilidade de levar mais tempo do que o esperado e a probabilidade de falha na solução do problema do cliente.

Depois de definir todos os resultados, faça uma soma ponderada em probabilidade do valor dos resultados e você terá uma imagem melhor do retorno que obterá no investimento. O objetivo desse mapa mental para gerenciamento de produto é mostrar o retorno esperado pela feature que esta sendo desenvolvida.

Bonus: conheça o framework de priorização de features: pontuação ponderada.

• Design e escopo

O próximo conjunto de mapa mental para gerenciamento de produto é útil para definir o escopo e o design de um produto após você ter escolhido onde investir.

5. Trabalhando de “trás para frente” (inversão)

Em vez de começar com um problema e depois explorar uma solução, comece com uma solução perfeita e trabalhe de “tras para frente” para descobrir por onde começar.

OBS: trabalhar de “trás para frente” não é universalmente melhor, apenas cria uma perspectiva diferente.

Como é útil: A maioria das equipes tende a trabalhar de forma sequencial, o que otimiza o que é prático, ao custo daquilo que é impactante.

Trabalhar inversamente (de “tras para frente”) ajuda a garantir que você se concentre no trabalho mais impactante e de longo prazo para o cliente, porque você sempre esta fazendo engenharia reversa a partir de uma solução perfeita para eles.

6. Confiança determina velocidade vs qualidade

A confiança que você tem em i) a importância do problema que está resolvendo e ii) a exatidão da solução que você está construindo deve determinar o quanto você está disposto a trocar velocidade e qualidade na criação de um produto.

Como é útil: Esse modelo mental ajuda você a construir um barômetro para trocar de forma inteligente velocidade e qualidade. É mais fácil explicar isso, observando os extremos do espectro abaixo.

No lado direito: você tem confiança (validada por meio de clientes) de que o problema em que está focado é realmente importante para os clientes e sabe exatamente o que criar para resolvê-lo. Nesse caso, você não deve usar atalhos, pois sabe que os clientes precisarão desse feature importante para sempre, portanto é melhor ter uma qualidade realmente alta (por exemplo, escalável, agradável).

Agora, vamos olhar para o lado esquerdo: você ainda não confirmou que o problema é importante para os clientes. Nesse cenário, quanto mais você investe na construção, maior o risco de criar algo para um problema que nem existe. Portanto, você deve errar ao iniciar algo rápido e obter a validação do cliente que vale a pena construir bem. Por exemplo, esses são os tipos de situações em que você pode criar uma página de destino (Landing page) para um recurso que nem existe para validar o interesse do cliente.

Bonus: O framework de priorização: RICE, tem como objetivos analisar 4 métricas para priorizar alguma feature ou iniciativa: Reach (alcance), Impact (impacto), Confidence (confiança), Effort (esforço).

7. Solucionando toda a experiência do cliente

As experiências do cliente não terminam na interface. O que acontece antes e depois de usar o produto é igualmente importante para o design.

Como é útil: ao projetar um produto, tendemos a focar demais na experiência do produto (por exemplo, na interface do usuário, no software).

É igualmente importante projetar a experiência de marketing (como você adquire clientes e define suas expectativas para o produto antes de usá-lo) e a experiência de suporte / angústia (como sua empresa lida com a falha do produto).

Criar grandes experiências de estresse, em particular, são oportunidades incríveis para ganhar a confiança do cliente a longo prazo. Por exemplo, a Amazon ganha mais sua confiança de você como cliente quando você precisa devolver algo. (Ela cria uma experiencia incrivel para ajuda-lo nesse processo).

8. Experimento, Feature, Plataforma

Existem três tipos de desenvolvimento de produtos: experimentos, features e plataformas. Cada um tem seu próprio objetivo e a maneira ideal de compensar velocidade e qualidade.

Como é útil: Ao reconhecer o tipo de desenvolvimento de produto que seu projeto é, você definirá metas mais apropriadas para cada tipo e dimensionará corretamente a velocidade e a qualidade da troca que realizar.

Os experimentos destinam-se a gerar aprendizado, para que você possa investir em novss features ou plataformas com a validação do cliente. Se você otimizar para aprender, considere fazer coisas que de outra forma não seriam palatáveis: por exemplo, usar código prontos que você pretende jogar fora e fingir software sofisticado quando você tem pessoas fazendo a ação nos bastidores.

Ao contrário dos experimentos, as plataformas são eternas. Outras pessoas criarão features sobre elas e, como tal, fazer alterações na plataforma depois que ela for ao vivo é extremamente perturbador.

Portanto, os projetos de plataforma precisam ter uma qualidade muito alta (estabilidade, desempenho, escalabilidade etc.) e precisam realmente permitir a criação de features úteis. Uma boa regra ao criar uma plataforma é construí-la com seu primeiro consumidor, ou seja, ter outra equipe criando simultaneamente uma feature em sua plataforma enquanto você o desenvolve – dessa forma, você garante que a plataforma realmente ative recursos úteis.

9. Loops Recursivos (Feedback loop)

Causa e efeito nos produtos são o resultado de sistemas conectados por loops recursivos positivos e negativos.

Como é útil: os loops recursivos nos lembram que alguns dos maiores fatores de crescimento ou declínio de um produto podem ser de outras partes do sistema.

Por exemplo, supondo que você faz parte da equipe de pagamentos e seu KPI é aumentar o total de pagamentos processados com cartão de crédito. Você tem um ciclo de feedback positivo com a equipe de aquisição de usuários, pois à medida que crescem, você tem mais usuários em potencial que pagarão com cartão de crédito. No entanto, você tem um ciclo de feedback negativo com a equipe de pagamentos em dinheiro, que está tentando ajudar os usuários a realizar transações com dinheiro mais facilmente.

O conhecimento desses loops recursivos pode ajudá-lo a mudar de estratégia (por exemplo, você pode optar por trabalhar na aquisição geral de usuários como a melhor maneira de aumentar o volume de pagamentos) ou entender as alterações negativas em suas métricas (por exemplo, o volume de pagamentos com cartão de crédito está baixo, mas é porque o a equipe de pagamentos em dinheiro está indo muito bem, não porque os produtos de cartão de crédito sejam ruins).

10. FLywheel (loop de feedback recursivo)

Um estado em que um loop recursivo positivo ou negativo está se alimentando e acelerando a partir de seu próprio momentum.

Como é útil: os volantes são um conceito relacionado aos loops recursivos, mas são importantes para gerenciar plataformas e mercados. Por exemplo, imagine que você gerencia a plataforma de aplicativos iOS da Apple. Você tem dois usuários: desenvolvedores de aplicativos e usuários de aplicativos.

O volante é o fenômeno em que mais usuários de aplicativos atraem mais desenvolvedores de aplicativos (porque há mais oportunidades de venda), que por sua vez atraem mais usuários de aplicativos (porque há mais aplicativos a serem comprados), que por sua vez atraem mais desenvolvedores de aplicativos e, portanto, em. Enquanto você alimentar o volante, você não apenas crescerá, mas irá crescer a um ritmo acelerado.

Se você está gerenciando um volante, precisa fazer tudo o que puder para mantê-lo girando na direção positiva, porque é tão poderoso quanto o contrário. Por exemplo, se existem tantos aplicativos na plataforma que novos aplicativos não podem mais ser descobertos, o crescimento do desenvolvedor de aplicativos diminui e quebra o volante – você precisa resolver isso.

• Lançamento e iteração

O próximo conjunto de mapas mentais para gerenciamento de produto é útil para quando você estiver construindo, operando e iterando um produto existente. Saber o que trabalhar é tão importante quando o trabalho em si, conheça 5 fontes de idéias para seu roadmap

11. Retornos decrescentes

Quando você se concentra em melhorar a mesma área de produto, a quantidade de valor do cliente criada ao longo do tempo diminui para cada unidade de esforço.

Como é útil: Supondo que você esteja efetivamente interagindo com o produto com base no feedback e na pesquisa do cliente, você chegará a um ponto em que não há muito o que fazer para torná-lo melhor. Chegou a hora de sua equipe seguir em frente e investir em algo novo.

12. Maxima local

Relacionado a retornos decrescentes, o máximo local é o ponto em que melhorias incrementais não criam valor para o cliente, forçando-o a fazer uma mudança radical nos recursos do produto.

Como é útil: Esse modelo mental está intimamente relacionado a retornos decrescentes, com a adição de atingir um limite em que literalmente não faz diferença material continuar melhorando alguma coisa. A iteração agora não serve para nada, e a única maneira de progredir é inovar.

Esse conceito foi popularizado recentemente pelo post viral Invisible Asymptotes de Eugene Wei, que cobre um exemplo como este que a Amazon previu que os levou a criar o Amazon Prime.

13. A versão dois é uma mentira

Ao criar um produto, não fique dependente de uma segunda versão para lançamento. Verifique se a primeira versão é um produto completo.Quando o software era vendido nas prateleiras, as equipes tinham que viver com a versão 1 para sempre.

Como é útil: Ao definir a primeira versão do seu produto, você acumulará todos os tipos de recursos incríveis que sonha em adicionar posteriormente nas versões futuras. Reconheça que isso pode nunca ser lançado, porque você nunca sabe o que pode acontecer: a estratégia da empresa muda, seu engenheiro-chefe sai ou a equipe inteira é realocada para outros projetos.

Para proteger esses cenários, verifique se o que você envia é um “produto completo” que, se nunca fosse melhorado novamente, ainda seria útil para os clientes no futuro próximo. Não distribua uma feature que dependa de melhorias futuras para realmente resolver o problema de seu usuario.

14. Freeroll (Jogar os dados)

Uma situação em que há pouco a perder e muito ganho lançando algo rapidamente.

Como é útil: Os freerolls geralmente surgem no produto quando a experiência atual do usuário é tão ruim que, ao fazer qualquer alteração razoável com base na intuição, é provável que seja muito melhor. Eles são diferentes de corrigir bugs, porque se referem a algo que não está funcionando como projetado.

Se você estiver em uma situação em que sua equipe está pensando: “Vamos fazer algo … não podemos piorar”, você provavelmente terá um freeroll à sua frente.

15. A maioria dos valores é criada após a versão um

Você aprenderá o máximo sobre o cliente após o lançamento do produto, não perca a oportunidade de aproveitar esses aprendizados.

Como é útil: Tudo é uma hipótese até que os clientes estejam usando o produto em escala. Enquanto o que sua equipe investe no “aprendizado de pré-lançamento” – entrevistas com clientes, testes de protótipos, análises quantitativas, testes beta, etc. – pode fornecer uma grande vantagem sobre a probabilidade de estar certo, sempre existem comportamentos e casos extremos que surgem quando você envia a feature para 100% dos clientes.

Quando uma grande porcentagem de usuarios utiliza, você obterá a maior parte do aprendizado após o lançamento. Não investir apropriadamente iterando o produto (às vezes drasticamente), não faz sentido com isso em mente.

16. Indicador de falha chave (KFI)

Emparelhar seus principais indicadores de desempenho (KPIs) com métricas que você não deseja ver em uma determinada direção, para garantir que você esteja focado no crescimento saudável.

Como é útil: As equipes geralmente escolhem KPIs que refletem diretamente os resultados positivos que estão procurando, sem considerar as maneiras negativas como esses resultados poderiam ser alcançados. Uma vez que eles começam a otimizar esses KPIs, eles realmente criam uma saída ruim para a empresa.

Um exemplo clássico é uma equipe que acredita ter sucesso ao duplicar a conversão de inscrição na landing page, apenas para perceber (tarde demais) que o número total de clientes não está crescendo porque a taxa de conversão caiu 60% devido a a mesma mudança.

Os KFIs mantêm o desempenho da sua equipe sob controle e certificam-se de criar apenas resultados saudáveis para a empresa.

Exemplos de emparelhamentos KPI <> KFI populares são:

• Aumentar a receita e mater a margem bruta.
• Aumentar a adoção do recurso A sem remover a adoção do recurso B.
• Aumentar a adoção do recurso A sem aumentar a carga de suporte.

Pode ser insatisfatório para muitos de vocês, mas até onde posso dizer, NÃO existe uma metodologia para usar esses mapas mentais para gerenciamento de produto. Se você tentar usá-los como uma check-list – examinando cada um deles e ver se eles os aplicam -, você terminará fazendo ginástica mental que confundirá e frustrará você e as pessoas ao seu redor.

Em vez disso, eles simplesmente se tornam parte de sua treliça, ajudando você a tomar melhores decisões sobre o produto e dando a você a capacidade para comunicar o “porque” das decisões tomadas à sua equipe.

À medida que você acumula mais modelos, idealmente através da experiência, melhor será o seu desempenho. Você pode tentar aplicar esses modelos de forma combinatoria entre eles e com outros frameworks de priorização de feature. Como você vai fazer não é tão importante, mas sim, que você tome uma decisão alinhadas aos objetivos da empresa e o que gera valor para o seu cliente.