24 frameworks para priorizar features do seu produto

Priorizar features é uma das principais preocupações da maioria dos gerentes de produto. É de longe um dos tópicos mais populares em blogs de PM, sites de perguntas e respostas e outras comunidades online.

A necessidade de priorizar features vem de um fato muito simples: nós simplesmente não temos recursos suficientes para trabalhar em tudo o que queremos e podemos criar.

Portanto, precisamos de um processo para determinar os conjuntos (e a sequência) de coisas que devem ser feitas no produto para oferecer o maior valor a cada momento, dadas as nossas restrições.

Se quebrarmos essa declaração, um grupo de perguntas precisará ser respondido:

• Como podemos saber o que é valioso? Quão valioso é isso? Valioso para quem?
• Como podemos definir o conjunto de coisas que devem ser combinadas em um release do produto? Como devemos sequenciar esses lançamentos?
• Como podemos obter a adesão necessária para acompanhar e levar essas coisas ao mercado?
• Como podemos saber se nossas suposições estão corretas? Estamos no caminho certo? Estamos realmente entregando valor? Poderíamos melhorar?

Se você pesquisar, encontrará inúmeros artigos com recomendações, técnicas e abordagens para esse problema. No entanto, a utilidade de cada método dependerá do produto ou projeto específico em que é aplicado. Suas necessidades de priorização podem variar bastante.

Nesse guia, vou detalhar os principais frameworks de priorização de features.

Quando comecei a trabalhar neste guia, senti imediatamente a necessidade de organizar visualmente todas essas técnicas de uma maneira que fizesse sentido e mostrasse o contexto em que cada uma delas é valiosa.

Nesse sentido, encontrei duas dimensões que atendiam a esses requisitos e o resultado foi o tipo de Tabela Periódica que você vê abaixo:

O eixo horizontal – Interno vs Externo

O eixo horizontal rastreia a orientação de um framework para obter informações do mundo interno ou externo. Em outras palavras, quanto depende de dados e opiniões de pessoas externas à equipe principal de desenvolvimento de produtos.

Essa dimensão reflete o fato de que às vezes você precisa de envolvimento externo (por exemplo, clientes finais ou stakeholders) para ajudá-lo a priorizar. No entanto, em outros casos, convém seguir um processo mais simples com a equipe de desenvolvimento ou sozinho.

O eixo vertical – Quantitatio vs Qualitativo

O eixo vertical mostra quão quantitativo é o método prescrito por cada framework. Ou seja, quanto disso é baseado em opiniões de especialistas (pessoais) em vez de algum tipo de métrica, classificação ou votação.

Algumas pessoas sentem-se mais à vontade com abordagens quantitativas e sendo apoiadas por números (para si ou para niveis hierarquicos mais altos). Em outros casos, você precisa trabalhar no lado qualitativo se o que você está tentando alcançar não é quantificável ou se não fizer sentido no seu contexto.

Todas as técnicas foram colocadas na tabela, levando em consideração quais são as posições relativas dessas duas dimensões. Locais individuais podem ser discutíveis, mas acho que este é um bom ponto de partida.

Técnicas Externas e Quantitativas

1. Modelo Kano

Noriaki Kano, pesquisador e consultor japonês, publicou um artigo em 1984 com um conjunto de idéias e técnicas que nos ajudam a determinar a satisfação de nossos clientes (e possíveis clientes) com os recursos do produto. Como o autor Dave Verduyn explica, o Dr. Noriaki desenvolveu essa estrutura enquanto pesquisava os fatores que contribuíam para a satisfação e a lealdade do cliente.

Essas idéias são comumente chamadas de Modelo Kano (pronuncia-se “kah-no”)  e são baseadas nas seguintes premissas:

• A satisfação dos clientes com as features de nossos produtos depende do nível de funcionalidade fornecido (quanto ou quão bem eles são implementados);
• Os recursos podem ser classificados em quatro categorias;
• Você pode determinar como os clientes se sentem sobre uma feature por meio de um questionário. (dica: utilize a escala likert para isso)

Satisfação x funcionalidade: O Kano propõe duas dimensões para representar como os clientes se sentem em relação aos nossos produtos:

1. Um que vai da satisfação total (também chamadas de excitantes) à insatisfação total (ou Frustração);
2. Um outro chamado Investimento, Sofisticação ou Implementação, que representa quanto de um determinado feature o cliente obtém, quão bem o implementamos ou quanto investimos em seu desenvolvimento.

As quatro categorias de features: Features podem ser divididas em quatro categorias, dependendo de como os clientes reagem ao nível de funcionalidade fornecido.

• Features de performance: features do produto se comportam como o que pensamos intuitivamente que a satisfação funciona: quanto mais fornecemos, mais satisfeitos nossos clientes ficam.
• Features essenciais (básicas): São features do produto que simplesmente são esperados pelos clientes. Se o produto não as possuir, será considerado incompleto ou simplesmente ruim.
• Features empolgantes (excitantes): São features inesperados que, quando apresentados, causam uma reação positiva. Estes são geralmente chamados de atraentes, excitantes (Delighters).
• Features indiferentes: São features pelas quais nos sentimos indiferentes. Aqueles cuja presença (ou ausência) não faz uma diferença real em nossa reação ao produto.

Determinando como os clientes se sentem através de um questionário. Para descobrir as percepções de nossos clientes em relação aos atributos do produto, precisamos usar o questionário Kano. Consiste em um par de perguntas para cada features que queremos avaliar:

• Um pergunta aos nossos clientes como eles se sentem se eles têm a feature;
• A outro pergunta como eles se sentem se NÃO tiverem a feature.

A primeira e a segunda questões são chamadas respectivamente de formas funcionais e disfuncionais. Para cada “como você se sente se tivesse / não tinha esse recurso”, as respostas possíveis são:

• Eu gosto disso;
• Eu espero isso;
• Eu sou neutro;
• Eu posso tolerar isso;
• Eu não gosto disso;

Dica de leitura: como citado anteriormente, você pode utilizar a Escala Likert para criar esse questionário.

Para cada par de respostas, usamos a tabela abaixo para determinar a categoria em que os entrevistados se enquadram, informando como ele se sente sobre a feature.

Nas respostas individuais e nas categorias resultantes, você pode entrar em dois níveis de análise:

• Discreto: cada par de respostas é classificado usando a tabela acima e a categoria da feature será a mais frequente em todos os entrevistados;
• Contínuo: cada resposta funcional e disfuncional obtém uma pontuação numérica, que pode ser calculada em média sobre todos os entrevistados e plotada em um gráfico 2D.

Como regra geral, as features devem ser priorizados de forma que esta ordem seja seguida: Essenciais → Perfomance → Empolgantes → Indiferentes.

Vale muito a pena explorar muito mais detalhes sobre esse método. Escrevi um guia abrangente e detalhado do modelo Kano que explica todo o processo e fornece um guia passo a passo sobre como usá-lo.

2. Desdobramento da Função Qualidade (QFD)

O Quality Function Deployment (QFD) ou Desdobramento da Função Qualidade é outro método originário do Japão e originalmente descrito por Yoji Akao em 1966 para a indústria de transformação.

A coisa mais valiosa que o QFD traz para a mesa é uma maneira de nos ajudar a focar nas features do produto vistos de diferentes ângulos, em particular o cliente e a empresa. Existem muitas dimensões de análise e esse método produz uma matriz de decisão em forma de casa, motivo pelo qual também é chamada de “casa da qualidade”.

Este excelente artigo de Jeff Sauro descreve como usar o QFD para produtos digitais. Aqui está a essência do processo:

1. Identifique os desejos e necessidades dos clientes (o “O que é”). Produza uma lista de itens potencialmente valiosos para seus usuários e clientes. Faça um brainstorming interno, entreviste clientes atuais e passados, pesquise a concorrência e qualquer outra maneira de obter novas idéias de tarefas e requisitos que você tiver. Estes são chamados de “O que é”. (Dica: conheça as principais fontes de idéias para seu produto)
2. Identifique a “voz do cliente” Agora é hora de saber o que é mais importante para os clientes, dentre todas as outras opções. Lembre-se de que simplesmente pedir às pessoas que lhe digam o que elas consideram mais importante geralmente produz algum tipo de resposta “tudo”. Para evitar isso, você pode solicitar que eles selecionem os cinco principais dentre um conjunto maior de opções. Use a porcentagem de entrevistados que escolheram cada tarefa como o fator de peso importante para a Voz do Cliente. (Você pode utilizar outro framework de priorização como o compre uma feature)
3. Identifique o “Como” – “a voz da empresa” Crie uma lista de features, correções e aprimoramentos concretos relacionados às tarefas que os clientes desejam. Os itens podem vir do backlog do produto ou podem ser novas idéias resultantes do feedback dos clientes. Estes são chamados de “Como”.
4. Relacionamento entre “voz do cliente” e “voz da empresa” Estabeleça uma relação de impacto entre o que os clientes desejam e como a empresa propõe corrigi-lo. Essa relação deve ser pontuada em uma escala não linear, para que as diferenças de impacto sejam mais acentuadas. Estes são valores comuns que devem ser definidos para cada combinação Quer + Como:
   • 9 → Relacionamento direto e forte
   • 3 → Relacionamento moderado
   • 1 → Relacionamento fraco / indireto
   • Em branco → Sem relacionamento
5. Gere prioridades As prioridades são provenientes das features de maior impacto, em todos os requisitos do cliente. Isso é obtido multiplicando a importância de cada requisito pelo impacto de cada feature. A pontuação de uma feature é a soma desses valores. Os itens de maior prioridade serão aqueles com as pontuações mais altas.
6. Examine as prioridades Usando esse método, deve haver diferenças suficientes entre as features para determinar quais são os mais importantes. Também mostrará se algum cliente deseja não está sendo resolvido de uma maneira; isso é perfeitamente bom, desde que o desejo não seja importante.

3. Pontuação de Oportunidade

O framework “pontuação de oportunidade” vem da estrutura de inovação orientada a resultados (ODI) de Anthony Ulwick.

A estrutura se baseia no preceito básico de que as pessoas compram produtos e serviços para realizar algum trabalho. Ou seja, é o resultado esperado que importa. O conceito de trabalho a ser realizado de Clayton Christensen compartilha essa linha de pensamento e tem sido um tópico muito popular que tem chamado muita atenção ultimamente4.

Uma das principais conclusões é que os clientes não são boas fontes de soluções, porque não são especialistas no assunto. No entanto, sua contribuição é extremamente valiosa na compreensão dos resultados que eles desejam do produto.

Através da pesquisa de usuários e outros métodos, podemos criar uma lista dos resultados desejados para o produto. Em seguida, precisamos pedir aos clientes que classifiquem cada resultado em quão importante é para eles e em que grau eles são satisfeitos em uma escala de 1 a 10 de acordo com duas perguntas:

• Qual a importância dessa feature ou resultado para você?
• Você está satisfeito com o desempenho do produto hoje?

Enquanto a análise de lacunas padrão trata os níveis de importância e satisfação dos clientes da mesma forma, com o algoritmo de pontuação de oportunidades de Ulwick, você dará o dobro de peso às pontuações de importância de recursos de seus clientes do que às de satisfação. (Você está tentando avaliar os resultados que eles mais valorizam.)

Dado isso, Ulwick propõe um Índice de oportunidade que é dado por esta equação ponderada:

Importância + max (importância – satisfação, 0) = oportunidade.

Em seguida, você conectará seus números à seguinte equação:

importância + (importância – satisfação) = oportunidade.

O que resulta disso são as oportunidades mais interessantes de inovação, em áreas específicas com alta importância e baixa satisfação. Também pode ser usado para identificar áreas em que os custos podem ser reduzidos (ou seja, os clientes estão altamente satisfeitos, mas não os classificam como importantes, o que pode significar desperdício de recursos).

Esses resultados podem ser plotados em um gráfico, fornecendo uma ajuda visual para entender melhor onde residem as oportunidades.

4. Compre uma Feature (Buy a Feature)

O “compre uma feature” (Buy a Feature) é um jogo divertido de inovação que pode ser jogado de forma colaborativa ou individual. Como o nome sugere, o mecanismo para determinar as características favoritas dos clientes é dar a cada um deles uma quantia fixa de dinheiro virtual para o exercício (fichas de pôquer, jujubas, dinheiro de banco imobiliario, moeda virtual etc.) e permitir que gastem esse dinheiro em uma lista de produtos/features propostas – cada um com seu próprio preço com base em seus custos estimados de desenvolvimento.

Veja como funciona:

1. Um conjunto de features que precisam ser priorizados é apresentado a um grupo de compradores (nossos clientes);
2. Cada comprador recebe um orçamento de dinheiro virtual para gastar nas features;
3. Cada feature é precificado de acordo com alguma medida de custo (complexidade, esforço, custo real de desenvolvimento etc.) – desde que seja o mesmo critério para todos os recursos, você pode usar qualquer um que preferir;
4. O orçamento de cada jogador deve estar entre um terço e metade do custo total de todos as features;
5. É possível jogar o jogo de duas maneiras:
   • Individualmente – Os jogadores são instruídos a usar seu orçamento para comprar as features que são mais importantes para eles;
   • Colaborativa – Usando uma escala de preços que torna alguns features muito caros para compra de compradores individuais. Isso força a colaboração e a negociação entre os jogadores para comprar recursos que são valorizados por vários jogadores.

1. À medida que os jogadores compram features, colete o dinheiro e peça que expliquem por que o estão comprando;
2. O jogo termina quando o dinheiro acaba ou quando os jogadores compram todos as features em que estão interessados (explique-lhes com antecedência que não há problema em sobras de dinheiro.)

Isso produzirá um conjunto valioso de informações sobre as features mais importantes para os clientes, pois podemos analisar quais delas foram mais comprados, os motivos de sua compra e quais lances colaborativos foram feitos em itens caros.

Para obter mais dados, várias instâncias do jogo podem ser jogadas (em grupos de 8 pessoas, no máximo). Além disso, para grandes conjuntos de features, você pode montar um campeonato em que as mais populares são aprimorados em várias fases dos jogos.

O framework “Compre uma feature” é melhor reproduzida pessoalmente devido ao seu caráter colaborativo, mas existem soluções on-line, se é isso que você precisa.

Dica: Esse método também é muito útil para projetos internos ou de consultoria que não estão expostos ao mercado, envolvendo os envolvidos como compradores no jogo. É uma ótima maneira de criar estratégia para o projeto, consenso sobre o que é mais importante e comunicar às partes interessadas a noção de que os recursos têm diferentes custos de desenvolvimento.

Técnicas Externas e Qualitativas

1. Mapeamento de Histórias

O “Mapeamento de Historias” foi introduzido pela primeira vez por Jeff Patton neste artigo de 2005 e seguidos por outro que escreveu sua experiência mais recente, e ele literalmente escreveu o livro (User Story Mapping)

A principal idéia por trás do “Mapeamento de Histórias” é que os registros de produtos em lista única são uma maneira incrivel de organizar e priorizar o trabalho que precisa ser feito. O objetivo do mapeamento de histórias é descobrir os detalhes que realmente são necessários para agregar valor ao cliente e evitar sessões de preparação que não envolvam totalmente o público e que acabam considerando cada item fora de contexto.

O mapeamento de histórias geralmente é feito em uma parede (ou quadro) usando post-it. Geralmente, toda a equipe participa da identificação etapas fundamentais da jornada do usuário e, em seguida, atribui as histórias do usuário abaixo delas. Cada história é discutida, para que não haja dúvidas sobre o que realmente é, seu objetivo e como ela se encaixa no esquema geral das coisas.

Um Mapa de História é organizado assim:

• Há um eixo horizontal que representa a sequência de uso;
  • Histórias de usuário (ou “tarefas”) são colocadas ao longo deste eixo, na sequência em que são executadas pelo usuário;
• O eixo vertical significa criticidade;
  • As histórias de usuários (ou “tarefas”) são organizadas verticalmente sobre a importância delas (de cima para baixo);
  • Histórias igualmente importantes podem ser mantidas na mesma altura, mas lembre-se de que, em geral, é importante diferenciar a importância relativa das histórias para poder criar melhores planos de liberação.
• Grupos de histórias de usuário relacionadas podem ser agrupados como Atividades:
  • Crie uma linha vertical para separar grupos de histórias de outras pessoas;
  • Por exemplo, uma atividade pode ser “gerenciar email”, com “enviar um email para um ou mais endereços” sendo uma tarefa do usuário;
  • As atividades ficam acima do eixo vertical e não têm nenhuma sequência de uso, elas “simplesmente são” – essas atividades compõem os principais atributos do produto e não podem ser priorizadas (pense em “você não pode priorizar o motor de um carro sobre as rodas”)

Há muitas vantagens para esse tipo de organização de backlog, mas as mais relevantes para priorização e execução são:

• É uma ferramenta visual que permite que clientes, stakeholders e membros da equipe de desenvolvimento compartilhem um entendimento comum do que o sistema faz;
• Ele define muito claramente como liberar iterações de produtos de forma incremental que oferecem versões completas de trabalho com crescente sofisticação – este é o conceito de Alistair Cockburn do esqueleto ambulante.
  • Para definir lançamentos, crie linhas horizontais ao longo do mapa, selecionando matérias com níveis equivalentes de criticidade;
  • Isso leva a versões completas de ponta a ponta do produto e, consequentemente, a uma entrega mais rápida e validação do mercado (crucial no estágio MVP).

A principal desvantagem dessa estrutura (e o investimento necessário em tempo para criá-la e prepará-la) é que ela é muito pesada para projetos ou produtos em contextos altamente dinâmicos. Ou seja, quando a visibilidade da forma futura do produto não é ótima (por exemplo, de 3 a 6 meses).

2. MoSCoW

O método MoSCoW é uma técnica de priorização usada em vários campos de gerenciamento para chegar a um consenso sobre o que é mais importante para os stakeholders e os clientes.

Durante seu mandato na Oracle, o especialista em desenvolvimento de software, Dai Clegg,criou o método MoSCoW. A técnica foi posteriormente doada para o Dynamic Systems Development Method (DDSM). Clegg inicialmente projetou o MoSCoW como um frameworkl de priorização para projetos com prazo determinado. Especificamente, para iniciativas em releases.

O termo é um acrônimo com cada letra representando uma das possíveis categorias de priorização. Os requisitos são classificados como:

• Must have (Devem existir) – estes são críticos e devem ser incluídos no produto. Se nem um deles estiver incluído, o lançamento será considerado uma falha. Eles podem ser rebaixados se houver acordo entre os stakeholders.
• Should have (Deveriam existir) – esses requisitos são importantes, mas não cruciais para o lançamento. Eles são o primeiro nível de “Bom ter” e geralmente compartilham a importância dos requisitos da MUST, sem serem tão sensíveis ao tempo.
• Could have (Poderia existir) – esses requisitos são desejáveis, mas não necessários para o lançamento. Eles geralmente são aprimoramentos de baixo custo para o produto. Devido à sua menor importância, eles são o segundo nível de recursos “É bom ter”.
• Won’t have (Não haverá) – estes são considerados os menos críticos ou até não alinhados com a estratégia do produto. Eles devem ser definitivamente descartados ou reconsiderados para lançamentos futuros.

Este método oferece uma solução de priorização rápida e simples. O problema vem com a falta de classificação nas categorias. Por exemplo, como podemos saber quais requisitos DEVEM ou DEVERIAM ser mais importantes que outros?

Devido a essa limitação, o método MoSCoW provavelmente é mais adequado para projetos internos, em vez de produtos com muitos clientes – conversar com várias partes interessadas sobre sutilezas de priorização sempre será mais fácil do que um contato em larga escala com os clientes finais.

3. Podar a Árvore do Produto (Prune the Product Tree)

Outro jogo de inovação de Luke Hohmann. Podar a Árvore do Produto (Prune the Product Tree) é moldar a direção do produto em relação às necessidades do mercado, mas também entender se algumas áreas do produto estão sendo deixadas para trás.

A analogia no jogo é que o produto é uma árvore que será podada ao nosso gosto. Embora os jardineiros façam isso cortando partes da árvore, o objetivo é moldar – não se trata de cortar.

Veja como funciona::

1. Desenhe uma árvore grande em um quadro branco ou em uma folha de papel;
2. Membros grossos representam áreas principais do produto e seus ramos mais externos representam as features atualmente disponíveis;
3. Escreva novas features em potencial em algumas notas do Post-It;
4. Peça aos clientes e partes interessadas que coloquem os recursos desejados na árvore, definindo assim sua próxima fase de crescimento.

A partir daqui, você pode extrair pontos de dados valiosos:

• A árvore está crescendo de maneira equilibrada?
• As áreas específicas estão crescendo desproporcionalmente maiores?
• As áreas anteriormente subdesenvolvidas estão crescendo agora?

Ter uma visão compartilhada de toda a extensão do produto com os clientes pode ser muito esclarecedor ao planejar novos lançamentos. Nesse equilíbrio visual, você obtém valor relativo entre as features, entende quais mudanças estratégicas podem ser necessárias e quais áreas do produto são boas candidatas a serem descartadas no futuro.

4. Speed boat

Acho este jogo criado pelo Luke Hohmann. particularmente interessante porque se concentra em um tipo diferente de priorização: identificar quais são os recursos menos apreciados no produto.

Se você pedir que as pessoas lhe digam suas queixas sobre o seu produto, você vai sentir uma certa frustração. Criar um tipo de sessão “de reclamação” para os clientes pode gerar uma grande quantidade de feedback com muito barulho.

Se, em vez disso, você perguntar a mesma coisa de uma forma controlada e positivo, poderá receber as queixas dos clientes realmente importantes. E essa é a premissa para este jogo. Veja como funciona:

1. Desenhe um barco em um quadro branco ou em um pedaço grande de papel;
2. Este é um barco de alta velocidade (speed boat – por isso o nome) e deve ser muito, muito rápido;
3. Infelizmente, ele está sendo retido por algumas âncoras;
4. O barco é o produto e as âncoras são as features com os quais os clientes se sentem frustrados;
5. Peça aos clientes que escrevam no Post-it as featrures com os quais não estão satisfeitos e com que velocidade estimam que o barco poderia se mover sem essas âncoras;
6. Cada estimativa de âncora e velocidade fornecerá uma medida de “dor”, que você poderá priorizar posteriormente para melhoria.

A visão de Hohmann é que, embora os clientes possam ter reclamações, eles quase nunca se opõem ao produto. Na maioria das vezes, eles querem ter sucesso, apesar da frustração. É por isso que criar esse canal gamificado é mais eficaz – evita o pensamento do grupo que pode surgir em uma sessão de “compartilhe suas reclamações” e libera as pessoas para expressar sua opinião com menos viés.

Técnicas Internas e Quantitativas

1. Analise Financeira

As iniciativas e projetos dos produtos geralmente são realizados com um objetivo específico de aumentar as receitas ou reduzir custos. Além disso, muitas empresas exigem plano de negócios para novas features do produto. Para essas e outras situações semelhantes, é necessário fazer uma análise financeira dos temas de desenvolvimento – aqueles com os melhores resultados financeiros são então priorizados.

Exploraremos métricas comuns para avaliar retornos financeiros, mas sugiro que você leia mais sobre o assunto se você estiver interessado nesse tipo de análise e priorização, pois ele fica complexo rapidamente. O excelente livro de Mike Cohn, Agile Estimating and Planning, dedica um capítulo inteiro a esse tópico.

Existem quatro tipos de objetivos financeiros que podemos esperar como conseqüência da melhoria do produto de alguma forma:

• Nova receita: nova receita projetada para ser gerada;
• Receita Incremental: receita adicional de clientes existentes, agora podendo cobrar por uma atualização ou serviços adicionais;
• Receita retida: receita que não é perdida porque a rotatividade de clientes é reduzida;
• Redução de custos: qualquer tipo de eficiência operacional obtida dentro da empresa.

Essas metas podem ser estimadas em um determinado período de tempo para cada tema que estamos tentando priorizar, fornecendo a receita total projetada que eles gerarão.

O problema é que um real hoje vale mais que um real amanhã. Uma iniciativa que retorna $ 10 mil, $ 20 mil e $ 30 mil em três trimestres é menos valiosa do que uma com os mesmos retornos na ordem inversa. São necessários métodos de comparação mais sofisticados. Iremos passar por três medidas que nos permitem responder a estas perguntas:

• “Quanto do ‘dinheiro de hoje’ teremos após X tempo, se investirmos nesse projeto?
• “Qual é o retorno deste projeto em termos percentuais?”
• “Quanto tempo levará para recuperar esse investimento?”

Ao analisar essas métricas em conjunto, as equipes podem tomar decisões de investimento para o futuro do produto com base nas prioridades financeiras da empresa e nos resultados desejados. Ainda assim, tome esses métodos quantitativos com uma consideração cuidadosa – todos eles são baseados em estimativas de receita e custo, e todos sabemos com que facilidade eles podem estar errados (voluntariamente ou não).

Net Present Value (NPV)

O Net Present Value (NPV) ou Valor Presente Líquido, é quanto dinheiro seria necessário colocar no banco para que, no final de um ano, tivéssemos $ 10? Isso é chamado de valor presente de alguma quantia e depende da taxa de juros que o banco está pagando, assim:

Para uma taxa de juros de 5%, precisamos colocar $ 9,52 no banco hoje para ter $ 10 em um ano. Mover valores futuros para seu valor presente é chamado de desconto.

Ao avaliar projetos alternativos nos quais investir, as empresas consideram um “Custo de oportunidade” no lugar de uma taxa de juros. Representa o que não é ganho como consequência do investimento em outra coisa. Se uma empresa geralmente obtém um retorno de 15% em seus projetos, esse é o custo de oportunidade com o qual um projeto alternativo deve ser comparado.

Uma iniciativa de produto produzirá uma sequência de fluxos de caixa ao longo de períodos de tempo (por exemplo, meses ou trimestres). Cada um deles deve ser descontado ao seu “valor presente” (PV). O Valor Presente Líquido é a soma desses itens em um período determinado e é fornecido por esta fórmula:

Esse método permite que uma empresa priorize os projetos, fornecendo uma resposta para esta pergunta: “Quanto do dinheiro de hoje teremos após X tempo, se investirmos no projeto A ou no projeto B?”

Internal Rate of Return (IRR)

Taxa Interna de Retorno (Internal Rate of Return (IRR)) é uma medida que expressa o retorno de um projeto em termos percentuais. Em outras palavras, mostra a rapidez com que um investimento aumentará em valor.

TIR é definida como a taxa de juros na qual o VPL é igual a zero. É difícil calcular manualmente, mas os aplicativos de planilha vêm com essa fórmula, tornando-o trivial – basta inserir os investimentos e fluxos de caixa necessários ao longo do tempo.

A partir desse valor, você obtém o retorno de um projeto e pode compará-lo com outros. No entanto, isso não deve ser tomado isoladamente para a tomada de decisões, pois o VPL geral ou o tempo de investimento necessário podem ser fatores importantes de decisão.

Discounted Payback Period

O Discounted Payback Period ou Período de Reembolso Descontado é fator final a ser levado em consideração é quanto tempo levará para recuperar o investimento. Para isso, analisamos o total corrente da soma dos fluxos de caixa descontados. Quando se torna positivo, significa que o investimento foi recuperado.

O que esse número não nos diz é quanto dinheiro será ganho. No entanto, é útil medir o nível de risco associado a um projeto. Quanto mais tempo leva para recuperar o dinheiro, mais arriscado. Dependendo das condições financeiras da empresa e da tolerância a riscos, isso pode ser um fator crítico.

2. Framework de Ian McAllister

Não acho que essa estrutura tenha um nome oficial, mas alguns pares do mercado chamam de Framework do Ian McAllister, dada a experiência do autor e a enorme popularidade que tem no Quora, vale a pena incluir nesta visão geral.

Veja como funciona:

1. Defina os temas importantes para o produto ou empresa. Crie uma lista dos temas mais importantes (por exemplo, aquisição de clientes, engajamento, ativação, ARPU) e selecione os três principais.
2. Priorize e aloque recurso aos temas. Defina a prioridade relativa de cada tema e quantos recursos você deseja investir em cada um (membros da equipe, marketing, etc.)
3. Gere idéias de projetos. Use as idéias de projetos que você já possui para cada tema e crie novas. Lembre-se do princípio de Pareto e concentre-se nos 20% do projeto que levarão a 80% do resultado desejado.
4. Estime o impacto potencial de cada projeto.Trabalhe o impacto que você espera de cada projeto, em termos muito amplos (pense em ordem de magnitude semelhante).
5. Estimar os custos de cada projeto. Com a ajuda de sua equipe (e dos stakeholders), faça uma estimativa dos custos de cada projeto.
6. Priorize o projeto dentro de cada tema. Defina as prioridades considerando os projetos com as melhores taxas de impacto / custo.

Você deve verificar a resposta original de Ian para obter mais detalhes e ler sobre os múltiplos benefícios que ele encontra nesta estrutura. Desses, o que me parece mais útil é o recurso de temas de forma independente. Ou seja: escolha os temas importantes e designe os membros da equipe e outros recursos com antecedência. Isso o libera de lutar constantemente para priorizar temas muito diferentes que você pode estar desenvolvendo em paralelo.

3. Impacto na Meta de Negócios

Outra maneira de considerar a priorização é alinhá-la às metas de negócios e às melhores práticas Lean. Uma pedra angular do movimento Lean Startup é o conceito de Aprendizado Validado. Como Eric Ries coloca:

Tratar tudo o que fazemos como empreendedores como um experimento – como um experimento científico projetado para ajudar a descobrir se estamos realmente no caminho de um negócio sustentável”

Eric Ries

Seguindo essa linha de pensamento, Dave McClure introduziu as métricas do AARRR (métricas piratas) para startups. Eles estão centrados em cinco estágios no ciclo de vida do cliente:

• Aquisição: os usuários acessam o site / produto;
• Ativação: os usuários desfrutam da 1ª visita, inscrição;
• Retenção: os usuários voltam várias vezes;
• Receita: a atividade dos usuários gera receita para o produto;
• Referência: os usuários gostam do produto o suficiente para recomendar a outras pessoas.

Esses estágios são um funil através do qual os clientes (potenciais) avançam. O objetivo é ampliar o funil o máximo possível entre as etapas.

Ao definir features para o produto, associe um objetivo de negócios a partir de um desses estágios. É possível que haja features ou aprimoramentos para melhorar a Ativação ou Receita, por exemplo. A priorização passa a ser uma questão de responder a estas perguntas:

• qual objetivo de negócios estamos tentando melhorar neste momento?
• quais features devem ter o maior impacto nesse objetivo?

Dependendo do tipo de métrica ou objetivo que você está segmentando, provavelmente é melhor se concentrar em testar e otimizar apenas um de cada vez. Isso torna mais fácil medir os resultados do que foi feito e usá-lo para decidir o que fazer em seguida: passar para outra métrica ou continuar melhorando a mesma.

Especialmente para produtos em estágio inicial, esse tipo de estrutura traz um foco único, quantitativo e alinhado aos negócios à priorização, o que pode ser muito útil.

Dica de leitura: conheça o Product-Led Growth e como ele esta mudando a forma como as empresas SaaS pensam sobre seus produtos e métricas.

4. Valor vs. Risco

Uma maneira clássica de priorizar é comparar o Valor do que deve ser feito com alguma outra medida de troca. Geralmente, essa medida é Custo/Complexidade (e discutiremos isso na próxima seção). No entanto, Mike Cohn (um dos fundadores do Scrum Alliance) também fala sobre considerar o risco como um fator de priorização em seu livro.

As features são pontuados em duas dimensões: Valor e Risco. Não há maneiras prescritas de estimar valor e, para isso, você pode usar uma das outras técnicas apresentadas aqui. Quanto ao risco, existem vários tipos, mas geralmente estamos preocupados com:

• Risco de agendamento. Exemplo, “isso pode não ser feito no momento em que precisamos”;
• Risco de custo. Exemplo, “isso pode custar mais do que o plano de negócios permite”;
• Risco de funcionalidade. Exemplo, “talvez não possamos fazer isso”.

Há uma luta constante entre alto risco e alto valor. O que deve ser feito primeiro? Por um lado, se você evitar itens de risco e buscar um valor alto primeiro, poderá desenvolver uma grande parte do produto antes de enfrentar um grande obstáculo. Por outro lado, se você se concentrar em trabalhar primeiro em itens de alto risco, poderá acabar fazendo um trabalho desnecessário em recursos que se revelaram menos valiosos.

O objetivo é procurar uma abordagem equilibrada, indo primeiro para alto risco / alto valor, segundo baixo risco / alto valor e, finalmente, baixo risco / baixo valor. Itens de alto risco / baixo valor são evitados. Como na imagem abaixo.

5. Valor vs Complexidade

O framework de priorização “Valor vs Complexidade” é muito comum, com a vantagem de também ser muito simples. As features são pontuados em seu valor e custo de implementação. Aqueles com as melhores proporções terão maior prioridade.

Lembre-se de que “Custo” não precisa significar unidades monetárias reais (ou seja, “dinheiro”). Existem muitas funções de custo que podem estar muito mais prontamente disponíveis ou mais fáceis de calcular. Uma função extremamente comum é a noção de esforço ou complexidade de engenharia, motivo pelo qual esse método também é chamado de “Valor vs esforço”.

Também chamada Bang for the buck, a análise do tipo ROI inerente a esse método parece intuitiva e também é incorporada a outras técnicas de priorização.

O principal objetivo desse método é tentar maximizar a entrega de valor ao longo do tempo. Ou seja, para um determinado período de lançamento, trabalhamos nos itens mais valiosos que podemos ajustar no período.

Uma maneira de visualizar essa técnica é através de um gráfico. O Scatter plotará todos os recursos considerados, com relação à pontuação em cada dimensão. Em seguida, as classificações de priorização serão visíveis como as inclinações das linhas que vão da origem a cada features. Quanto maior a inclinação, maior a prioridade.

Outra maneira de visualizar isso é usando uma matriz analógica para o método Value vs. Risco:

A lógica aqui é semelhante ao gráfico de dispersão. Comece com itens de alto valor e baixo custo e depois passe para itens de alto valor e alto custo. Itens de baixo valor e baixo custo devem ser equilibrados ao longo dos ciclos de desenvolvimento, pois eles podem representar melhorias menores e itens interessantes. A razão pela qual esses itens do quadrante inferior esquerdo precisam ser cuidadosamente “equilibrados” deve-se à tendência de priorizar itens de baixo custo e baixo valor (que possuem boas relações Valor / Custo). Como Teresa Torres escreve:

Se você usar o tempo de construção para priorizar o que construir a seguir, terá um produto cheio de soluções fáceis

Teresa Torres

Como de costume, considere cuidadosamente o que sai dos métodos de priorização e use-os como diretrizes e não como respostas definitivas.

6. Pontuação Ponderada

Com a pontuação ponderada, você pode usar o modelo matriz de Valor x Complexidade, mas aplicar camadas na pontuação para chegar a um resultado mais objetivo. Você pode adicionar os pesos dos benefícios de acordo com o que você e sua equipe acreditam ser o mais importante para o momento da sua empresa.

Usando um método de pontuação para classificar suas iniciativas estratégicas e as principais feature, os gerentes de produto podem facilitar uma discussão mais produtiva sobre o que incluir no roadmap do produto. Embora existam muitas entradas que acabam em uma decisão de produto, um modelo de pontuação pode ajudar toda equipe a ter uma conversa objetiva e priorizar features para seu produto alinhada com o negocio..

Um modelo de pontuação objetivo e claro pode informar as iniciativas que você decide incluir no seu roadmap e dar credibilidade à sua estratégia de produto. 

DICA: Coloque nas colunas de benefícios e custos, o que considera o mais importante para ser avaliando naquele momento da sua empresa. No exemplo abaixo eu listei uma tabela, onde os benefícios a serem avaliados são: aumento de receita, valor para usuário, valor para estratégia.

7. Scorecard

O Scorecard é outra técnica popular. O objetivo é priorizar as features ao longo de um conjunto de critérios que foram negociados com os stakeholders.

Veja como funciona, segundo Daniel Elizalde sobre o assunto:

1. Comece com uma estratégia clara que foi validada pelos usuários;
2. Selecione as features mais relacionados à estratégia geral para a próxima versão;
3. Definir um critério e pesos para pontuação;
4. Reunir-se com os stakeholders e ajuste os critérios e pesos;
5. Analise todos as features / temas candidatos e atribua uma pontuação (por exemplo, de 1 a 100) ao seu respectivo impacto para cada critério.

Outra maneira de permitir o uso completo do Scorecard é identificar um features / tema considerado no meio dele para cada critério. Em seguida, marque todos as outras features em comparação com aquele; uma escala mais curta (de 1 a 5) funcionará melhor nessa abordagem.

O scorecard pode ser um exercício útil para as empresas avaliarem o que acreditam ser o impacto relativo nos objetivos estratégicos para um grupo de possíveis novos recursos.

No entanto, existem críticas muito válidas para este framework:

• Está pontuando as coisas certas? (ou seja, as categorias de pontuação estão realmente alinhadas com a estratégia do produto?)
• Os pesos e as pontuações são “preparados” para priorizar features já favorecidos pela opinião e pela política, enquanto ao mesmo tempo dão a aparência de uma análise objetiva?
• Isso pode levar a produtos fragmentados, fora de foco de sua proposta de valor exclusiva.

8. Seleção de Temas

A Triagem de Temas está relacionada aos Scorecards, mas seu foco está na avaliação de temas e features em termos relativos. O fluxo de trabalho é semelhante:

1. Definir os critérios sob os quais avaliar recursos e temas;
2. Para cada critério, escolha uma feature / tema de “linha de base”. Um bom tema de linha de base é aquele que provavelmente (mas não garantido) será escolhido para o próximo lançamento;
3. Para cada feature / tema, classifique-o em comparação com a linha de base: um “+” se tiver um impacto maior que a linha de base, um “0” se for neutro e um “-” se tiver um impacto menor;
4. Para cada feature / tema e critério de pontuação, calcule sua pontuação líquida e classifique as features por esse valor.

Talvez por ter um pouco menos viés de confirmação (na forma de pesos de critério e escalas de pontuação), esse método possa contornar algumas das desvantagens dos scorecards. Além disso, se considerar uma categoria única para classificação, essa pode ser a ferramenta de pontuação para outros métodos de priorização que se concentram no impacto das features em uma determinada métrica comercial ou na proposta de valor exclusiva do produto.

9. RICE

O framework RICE é um acrônimo para os quatro fatores que usamos para avaliar cada ideia de projeto: alcance, impacto, confiança e esforço. As 4 categoria de avaliação são:

• Reach (Alcance): O alcance é medido em número de pessoas / eventos por período. Isso pode ser “clientes por trimestre” ou “transações por mês”. Na medida do possível, use medições reais das métricas do produto em vez de tirar números de um chapéu.
• Impact (Impacto): Para se concentrar em projetos que movem a agulha para sua meta, estime o impacto em uma pessoa. O impacto é difícil de medir com precisão. Portanto, escolho entre uma escala de múltipla escolha: 3 para “impacto maciço”, 2 para “alto”, 1 para “médio”, 0,5 para “baixo” e, finalmente, 0,25 para “mínimo”. Esses números são multiplicados na pontuação final para aumentar ou diminuir a escala.
• Confidence (Confiança): Para reduzir o entusiasmo por idéias emocionantes, mas mal definidas, considere seu nível de confiança em suas estimativas. Se você acha que um projeto pode ter um grande impacto, mas não possui dados para fazer backup, a confiança permite controlar isso.A confiança é uma porcentagem, e eu uso outra escala de múltipla escolha para ajudar a evitar a paralisia da decisão. 100% é “alta confiança”, 80% é “médio”, 50% é “baixo”.
• Effort (Esforço): Para agir rapidamente e causar impacto com o mínimo de esforço, estime a quantidade total de tempo que um projeto exigirá de todos os membros da sua equipe: produto, design e engenharia. O esforço é estimado como um número de “pessoas-mês” – o trabalho que um membro da equipe pode realizar em um mês. 

Portanto, para resumir rapidamente nossos quatro fatores:

• Alcance: quantas pessoas isso impactará? (Estime dentro de um período de tempo definido.)
• Impacto: quanto isso impactará cada pessoa? (Maciço = 3x, Alto = 2x, Médio = 1x, Baixo = 0,5x, Mínimo = 0,25x.)
• Confiança: quão confiante você está em suas estimativas? (Alto = 100%, Médio = 80%, Baixo = 50%.)
• Esforço: quantas “pessoas-mês” isso levará? (Use números inteiros e no mínimo meio mês – não se preocupe com a estimativa.)

Depois de estimar esses fatores, combine-os em uma única pontuação para comparar rapidamente os projetos. Aqui está a fórmula simples:

A pontuação resultante mede o “impacto total por tempo trabalhado” – exatamente o que gostaríamos de maximizar. Configurei uma planilha para calcular automaticamente a pontuação para mim ao estimar cada fator.

Depois que a pontuação inicial for concluída, classifique sua lista e reavalie. Existem projetos em que a pontuação parece muito alta ou muito baixa? Nesse caso, reconsidere suas estimativas e faça alterações ou aceite que seu instinto pode estar errado.

Técnicas Internas e Qualitativas

1. Agrupamento por Afinidade

O framework “agrupamento por afinidade” é uma atividade de priorização colaborativa. Ele funciona da seguinte forma:seu grupo de participantes faz um brainstorm de idéias e oportunidades as colocando em post-It. A equipe trabalha para colocar os post-it em grupos de itens semelhantes. Depois que os grupos são criados, a equipe vota nos grupos para classificá-los.

O agrupamento por afinidades não precisa ser uma atividade formal ou complicada. Veja como funciona

1. Reúna um grupo de participantes. Idealmente, convoque participantes de várias partes da empresa para participar e obter uma ampla variedade de idéias e perspectivas.
2. Em grupo, anote o máximo de idéias possível. Você pode usar post-it, cartões de anotações, um quadro branco ou até mesmo um pedaço de papel.
3. Trabalhe com os participantes para classificar suas idéias e agrupar idéias semelhantes em “grupos de afinidade”. Isso ajuda a manter as idéias organizadas por temas.
4. Em grupo, vote em diferentes temas. Você pode tratar isso como uma sessão de priorização de “compra uma feature” ou simplesmente fazer com que todos trabalhem em grupo para classificar os temas por importância.

2. Ranking de Classificação

Esse tipo de classificação é uma das mais simples (e ingênuas) que podemos utilizar. No entanto, é útil para projetos muito pequenos e internos.

O processo é simples: cada features é classificado em alguma categoria e, em seguida, é produzida uma classificação. As categorias devem ser classificadas de alguma forma, por exemplo 1-2-3-4-5, Alto-Médio-Baixo.

Está relacionado ao MoSCoW, mas como normalmente é baseado em opiniões pessoais (“especializadas”), eu o classifiquei no lado interno dos métodos. Você pode usá-lo com outros stakeholders, mas a ambiguidade da categorização quase certamente levará a problemas. Melhor guardar para si mesmo (isso se você ainda usa-lo).

3. Modelo Sistemico

O modelo sistemico visa fornecer uma estrutura para priorizar inteiramente em termos de valor para o cliente e visualizar esse processo como algo sistêmico e holístico (daí o nome).

Os requisitos do produto são visíveis em termos de “como eles abordam as metas do usuário” e os “níveis de engajamento”.

A equipe por trás desse modelo descobriu que é de particular utilidade ao trabalhar em novos produtos e domínios que precisam ser centrados no cliente e / ou no usuário, especialmente quando há pouco ou desconhecido aprendizado validado.

Esse modelo está relacionado ao mapeamento de histórias, pois também cria uma grade bidimensional que facilita a visualização do escopo do produto e dos diferentes níveis de prioridade.

• Objetivos do usuário – A primeira dimensão é “objetivos do usuário”. O produto é definido não em termos de o que faz, mas em termos de por que algumas funcionalidades são necessárias.
• Engajamento do usuário – A segunda dimensão usa o engajamento do usuário como uma medida do nível de interação entre o usuário e o produto. Existem quatro graus (em diminuição da urgência):
  • Essenciais: features para satisfazer as necessidades básicas dos usuários. Essas são expectativas de linha de base para os usuários neste espaço de produto;
  • Uso: features novas e aprimoradas para aumentar a usabilidade do produto. Sem eles, o produto tem um apelo mínimo ao usuário;
  • Engajamento: features que leva o usuário a ter mais interação com o produto e a incentiva a voltar no futuro;
  • Exploratórias: features que constroem uma conexão mais forte entre o usuário e o produto à medida que promovem ir além de simples interações.

As histórias de usuário são colocadas nos níveis correspondentes de objetivos e engajamento do usuário. Como as próprias histórias de usuário podem ter atributos adicionais de valor e custo, esse modelo se transforma em um sistema multidimensional fácil de explorar.

Assim como no mapeamento de histórias, é possível criar um plano de lançamento que crie valor crescente para o cliente e, ao mesmo tempo, reunir feedback antes de investir pesadamente em um determinado conjunto de features.

4. Maior Impacto na Base

O tipo de mapas de valor que o modelo sistemático e o mapeamento de histórias criam são incrivelmente úteis. Eles permitem visualizar diferentes níveis de impacto que os recursos podem ter em algum objetivo ou atividade do usuário, facilitando o planejamento da liberação.

Se essas abordagens mostrarem impacto nas áreas de produto, a equipe da Intercom propõe um esquema de priorização baseado no impacto na base de usuários. Ou seja, se concentrar no que é mais utilizado pela maioria da base de usuários do produto.

Veja como funciona:

Para garantir que as novas features valham a pena, observe quantos de seus clientes usarão a feature e com que frequência. Isso lhe dá uma sensação de onde você gera mais valor. Vamos começar com o diagrama a seguir.

Em seguida, traçamos as features em discussão:

É claro que algumas features são mais importantes que outros. Abaixo, separo por cores determinadas áreas para destacar isso.

Obs: Normalmente, excluo features administrativos, como login, redefinição de senha, perfil de edição etc., e me concentro apenas nas atividades que o usuário realmente deseja executar.

Concentre seus esforços no canto superior direito. Melhorar essas features acrescenta muito mais valor do que melhorar features que as pessoas não usam.

As seções em laranja você precisa prestar atenção Se você estiver criando features dos quais apenas uma pequena parte da sua base de clientes depende muito, seu produto está fazendo mais do que deveria. Esses clientes não ficarão felizes se você remover essas features, mas valerão muito pouco para você.

5. Classificação empilhada

O backlog típico é uma lista simples de itens. Este guia aborda muitas técnicas sobre como organizá-lo de maneira diferente e como priorizá-lo. A maioria deles produzirá uma lista empilhada de temas ou features a serem desenvolvidos.

No entanto, em muitos casos (provavelmente a maioria), essa classificação empilhada é baseada na opinião de “especialista” de um gerente de produto. Em outros casos, essa lista é baseada em conversas internas e com stakeholders.

Esse tipo de priorização não é inerentemente errado; simplesmente não é o ideal para a criação de valor focada no usuário. Devido ao seu amplo uso, ele merece uma menção neste guia, mas sua posição na tabela visa refletir que isso é baseado em opiniões e focado internamente.

6. Feature Buckets

O framework Feature Buckets de Adam Nash também é muito popular nos sites e blogs especializados.

Adam acredita que a priorização de features varia muito entre diferentes tipos e setores de produtos, e é por isso que enfatiza que essa técnica foi pensada especificamente para produtos de Internet para consumidores.

Os conceitos de features devem ser colocados em um dos quatro baldes:

• Movimentadores de métricas – Features que moverão significativamente as métricas de negócios e produtos. Deveria haver metas e estratégias específicas por trás da decisão de investir em um produto ou features (Dica: métricas da AARRR são úteis aqui);
• Solicitações de clientes – Esses são as features que foram solicitados diretamente pelos clientes. Geralmente, são aprimoramentos incrementais, mas é importante considerá-los ou arriscar alienar os usuários ou perder comentários importantes provenientes do uso do produto;
• Encantam – Features inovadoras geradas internamente com base em informações de design ou tecnologia. Trabalhar em features que emocionam e impressionam é importante para encantar os clientes e criar uma posição diferenciada no mercado (Leia sobre o modelo Kano para mais informações);
• Estratégicas – features incluídos por razões estratégicas relacionadas a aprendizado ou objetivos futuros (por exemplo, experimentação e coleta de dados).

Uma roadmap bem equilibrada do produto normalmente deve incluir features de todos esses baldes. A estrutura não é explícita quanto às distribuições apropriadas entre esses buckets e como priorizar internamente dentro de cada um. Esses detalhes de implementação são deixados para o gerente de produto definir.

7. Método KJ

O método KJ é uma técnica desenvolvida por Jiro Kawakita como um framework de grupo para estabelecer prioridades. O framework produz rapidamente “consenso em grupo de forma objetiva a partir de uma coleção de dados subjetivos e opinativos”. Está no lado interno das técnicas, pois a maneira como seu uso é descrito é principalmente direcionada aos stakeholders da propria empresa.

O UIE descreve um processo de oito etapas para qualquer tamanho de grupo em menos de uma hora executar o exercicio. Primeiro, verifique se você tem as seguintes pré-condições:

• Post-its em duas cores;
• Sala com muito espaço na parede;
• Uma pessoa para ser o facilitador (movendo o grupo de um passo para o próximo);
• Quadro branco ou flip-chart para a etapa final de classificação.

Com todas as opções acima, o facilitador segue este processo:

1. Determinar uma pergunta foco. A pergunta foco conduz os resultados. Cada sessão terá sua própria pergunta de foco (por exemplo, “Quem são nossos usuários?”, “Quais objetivos os usuários têm quando acessam nosso site?”, Etc.)
2. Organizar o grupo. As pessoas do grupo devem ser de diferentes partes da empresa, para obter perspectivas mais diversas.
3. Colocar opiniões (ou Dados) em post-its. Ao colocar um item em cada post-it, é solicitado a cada participante do grupo que faça um brainstorming sobre o máximo de itens possível.
4. Colocar post-its na parede. Cada participante coloca os post-its na parede em ordem aleatória. Eles também leem as contribuições de outras pessoas. Se as pessoas pensarem em outra coisa que deve ser colocada na parede, eles podem, a qualquer momento, simplesmente adicioná-lo à coleção.
5. Agrupe itens semelhantes. Uma vez que todos adicionem suas contribuições à parede, o facilitador instrui o grupo a começar a agrupar itens semelhantes em outra parte da sala.
6. Nomeando cada grupo.Cada participante é solicitado a atribuir um nome a cada grupo, usando a segunda cor de post-its
7. Votação para os grupos mais importantes. Solicite aos participantes que usem individualmente seu próprio ponto de vista para escolher quais grupos ele ou ela acredita serem mais importantes para responder à pergunta de foco.
8. Classificação dos grupos mais importantes. Este é o passo final e mais importante. Todos os post-it são colocadas no quadro branco e ordenadas por número de votos. Os participantes podem combinar grupos semelhantes, que somam seus votos e os elevam no ranking. Quando três a quatro grupos têm uma classificação muito mais alta que os demais, o facilitador pode interromper o exercício.

Devido à combinação de opinião individual por meio de votação e o consenso unânime imposto na etapa final, esse método pode convergir rapidamente para um grupo de prioridades. Isso ajuda todas as equipes que dependem da participação e do acordo dos stakeholders na estratégia e nas prioridades do produto.

Depois de passar por todas esses frameworks, você provavelmente notou que cada uma delas tem contextos nos quais faz sentido ser usada e outras quando não. Infezlimente não existe uma bala de prata e temos que escolher o que for mais apropriado para nosso produto, equipe, setor etc. Ao mesmo tempo, existem pontos em comum importantes entre esses métodos que merecem destaque.

Vamos examinar as principais conclusões dessa atividade incrível que chamamos de priorização.

1. Priorize em alto nível

Essencialmente, todos os métodos de priorização trabalham com features de alto nível (temas) e objetivos do usuário. Isso é importante por alguns motivos:

• O foco está em fornecer valor ao usuário e não as minúcias (pelo menos a princípio);
• Você não perde tanto tempo se / quando a estratégia mudar;
• Após elaborar a estratégia e as prioridades de alto nível, a equipe deve cuidar de encontrar as melhores táticas para chegar lá.

2. Estabeleça metas, meça e ajuste

Outra característica comum entre muitas técnicas é o foco na eficácia. Eles têm uma noção subjacente de que nossa motivação para priorizar é que perseguimos alguma meta com um efeito mensurável (impacto, ROI, uso, métrica de negócios aprimorada etc.)

O objetivo não é definir prioridades e lença-las. O objetivo é estar constantemente ciente de que o que estamos fazendo realmente está agregando valor e funcionando conforme o esperado; quando não estiver, teremos pelo menos algumas pistas sobre o que precisa ser ajustado.

3. Não faça isso sozinho

A priorização não deve ser um esforço individual. Com exceção de métodos muito simples, quase todos eles envolvem outra pessoa no processo. Sejam clientes, stakeholders ou membros da equipe, é muito raro que apenas o gerente de produto defina as prioridades gerais. Somos apenas responsáveis ​​por um processo e o produto pertence à equipe.

Conseguir o maximo de input externo possivel, garante a confiança de que o que é priorizado é efetivamente valioso. E mesmo assim, só temos certeza depois de medir os resultados reais.

Dica complementar: não é só o gerente de produto que cria roadmaps, mas o time inteiro.

4. Quantitativo vs. Qualitativo

Quantitativo não significa melhor que qualitativo (e vice-versa.). Por exemplo, uma armadilha comum ao usar métodos quantitativos de priorização é que as pessoas associam números com precisão e confiança. Ver fórmulas, proporções e classificações geralmente nos faz sentir mais seguros quanto à robustez e objetividade de algum tipo de análise, mas elas podem ser utilizadas.

Saiba o que você está obtendo do método e quando usá-lo. Essas coisas são ferramentas, não oráculos.

Você deve ter isso em mente, tanto para você quanto para apresentar resultados a outras pessoas – essas são diretrizes e não resultados infalíveis.

5. Externo vs. Interno

A distinção Externa e Interna que me digo neste guia refere-se à quantidade de envolvimento externo existente no processo de priorização. A escala é mais ou menos assim:

Você < Equipe < Stakeholder < Clientes.

Novamente, tudo depende dos resultados que você está tentando obter. Pessoalmente, achei útil pensar sobre isso nestes termos:

• Os frameworks externos são melhores para priorizar resultados abstratos;
• Os frameworks internos são melhores para priorizar soluções concretas.

O valor das técnicas externas

Em termos gerais, as técnicas externas são mais úteis quando você está tentando navegar por um amplo conjunto de possiveis features, procurando:

• Identifique os mais valiosos para seus clientes – conhecendo suas expectativas de linha de base e desempenho e também o que os agrada;
• Obter adesão e consenso de um grupo de stakeholders em empresas maiores;
• Medir quais features não agregam valor ou desagradar ativamente os clientes, para que você possa decidir se deseja melhorá-los ou descartá-los;
• Conseguir que os clientes em projetos de consultoria participem e assinem a estratégia de desenvolvimento e o plano de lançamento.

Como você lida principalmente com o “mundo exterior”, é natural que discussões e prioridades aqui ocorram em um nível mais abstrato de resultados, metas e features de alto nível do usuário.

O valor das técnicas internas

Como você envolve pessoas mais próximas do produto e da tecnologia, essas técnicas são melhores para priorizar problemas de forma mais concreta. Ou seja, eles são menos exploradores, pois os usuários finais estão menos envolvidos (se é que existem). Portanto, eles funcionam melhor sempre que você precisa:

• Refinar ainda mais os resultados obtidos de um dos frameworks orientadas para o exterior;
• Priorize um conjunto de features e idéias que você confia que estejam alinhados com a estratégia do produto e as expectativas dos clientes;
• Trabalhar em projetos internos sem muito (ou nenhum) contato com o mercado;
• Priorizar rapidamente features e requisitos de baixo nível.

Com todas essas técnicas e sugestões em mãos, agora é com você. Misture e combine-os. Faça mudanças. Mas, acima de tudo, saia e construa ótimos produtos.

Bonus: conheça o framework estrategico “Os 3 horiontes de Inovação“. Ele é ótimo para pensar na estrategia de longo prazo do seu produto (e o que precisa ser feito para chegar lá)

Suas boas habilidades de gerenciamento de produtos entrarão em jogo durante o processo. Tenho algumas sugestões, independentemente do método de priorização que você escolher para escolher a melhor feature:

1. Abordar a priorização como uma atividade de equipe; além de criar adesão à equipe, você tem perspectivas diferentes. (Também é muito mais divertido).
2. Limite o número de itens que você está priorizando – concentre-se nos itens maiores, e não nos detalhes.
3. Categorizar e agrupar iniciativas em temas estratégicos (por exemplo, “melhorar a satisfação” para uma determinada pessoa seria uma boa maneira de agrupar).
4. Antes de começar a priorizar, é útil entender o valor do cliente para cada iniciativa. O valor do cliente deve estar enraizado na evidência de que você coletou dos clientes e não das suas opiniões.
5. Antes de começar, faça uma estimativa aproximada do custo. Mesmo o tamanho da camiseta de “pequeno”, “médio” e “grande” será útil durante o processo.

O gerenciamento de produtos geralmente pode ser um ato de equilíbrio difícil, no qual você se encontra constantemente tentando satisfazer muitaos stakeholders: 

• Sua equipe de vendas deseja um novo conjunto de features.
• Seus executivos desejam que o produto esteja pronto para o mercado em uma determinada data. 
• O desenvolvimento deseja adiar alguns itens até o próximo lançamento. 
• Os investidores querem reduzir custos sempre que possível. 
• Você deve garantir que seu produto não fique atrás da concorrência. 
• E seus clientes querem tudo ao mesmo tempo!!

Como é difícil saber exatamente como priorizar features em meio a todo esse barulho, os gerentes de produtos podem facilmente cair em várias armadilhas – e priorizar as coisas erradas para seus produtos.

• Não priorize com base no que seus concorrentes estão fazendo. O desenvolvimento do seu produto deve se basear na pesquisa, no feedback do cliente e em idéias inovadoras que você e sua equipe compilam – e não no que outro produto está fazendo.
• Não priorize com base nas solicitações da sua equipe de vendas. Sua equipe de vendas sempre terá uma opinião de solicitação de features. Mas confiar na opinião deles é a maneira mais rápida de perder a direção do objetivo estratégico do produto.
• Não priorize o que é fácil – Mesmo que seus desenvolvedores digam que eles podem retirar muitos itens da lista rapidamente. Pode parecer uma opção viável, mas essa não é uma estratégia de produto. De fato, fazer isso é uma forte indicação de que você não está trabalhando em direção a um objetivo para o seu produto.
• Não priorize com base apenas no seu instinto. A condução de um produto para um lançamento de mercado bem-sucedido exige evidências concretas e uma estrutura de priorização para apoiar as decisões do gerente de produtos. Pense: pesquisa do setor, pesquisas com usuários, conversas com clientes, feedback das equipes de vendas ou suporte da empresa.

Priorizar features não é um trabalho fácil, até gerentes de produto experientes tem dificuldade ao longo de sua carreira. O principal motivo para essa dificuldade é equilibrar os desejos e opiniões de diversos stakeholders distintos, alinhar essas opioniões aos objetivos de negocio da empresa, e por fim, equilibrar com a capacidade produtiva do time.

Você, como um gerente de produto (ou aspirante a se tornar um), vai ter um grande desafios nas mãos, mas espero que com essa lista de frameworks, eu tenha conseguido ajuda-lo. Se precisar de uma forma mais prática de escolher o melhor para seu time, clique no link a seguir! Você não via se decepcionar!