6 formas de dar prioridade às funcionalidades de um produto (+ dicas & exemplos)

Se me perguntarem, duas das competências mais importantes na gestão de produto são conhecer as suas prioridades e dizer "Não."

Hoje, vamos aprofundar a primeira (uma vez que a segunda merece um guia próprio) e ajudá-lo a dar prioridade ao seu trabalho e a manter todos alinhados com as suas prioridades.

Uma nota importante sobre as estruturas de priorização de funcionalidades de produto

Antes de começarmos a explorar as formas de dar prioridade à sua lista de pendências, há uma dica importante que preciso de partilhar consigo.

As estruturas de priorização não devem ser interpretadas literalmente.

Não, não tem de as utilizar exatamente da forma como estão descritas no livro (ou neste guia). O produto que lidera pode ser completamente diferente daqueles que o autor liderava quando escreveu o livro. Produtos diferentes significam realidades e necessidades diferentes. Por isso, é perfeitamente aceitável adaptar a estrutura às suas próprias necessidades. Afinal, uma boa estrutura é aquela que funciona para si.

Estruturas de priorização de produtos para experimentar

Sabia que existe uma estrutura de priorização do Thanos? Basta eliminar aleatoriamente metade de todas as funcionalidades da sua lista de pendências!

Bem, fui eu que inventei isso. Mas percebeu o meu ponto de vista. Existem demasiadas estruturas por aí. Tantas que, sem dúvida, não conseguirei abordá-las todas neste guia. Para ser honesto, também não me parece que esteja aqui para memorizar um milhão de estruturas.

Por isso, em vez disso, vou analisar aquelas que utilizei pessoalmente no meu dia a dia de gestão de produtos e partilhar consigo algumas dicas práticas para cada uma delas. Também vale a pena considerar como poderá utilizar a IA na priorização de funcionalidades em conjunto com estas estruturas.

1. Modelo de Kano

Este método de priorização recebeu o nome do talentoso escritor e consultor de gestão japonês Noriaki Kano. A beleza da sua abordagem está na sua simplicidade.

Kano sugeriu categorizar as suas funcionalidades nos seguintes grupos:

• Obrigatórias: Estas são funcionalidades básicas do seu produto e a sua ausência criará uma má experiência para o cliente (uma má retenção e uma elevada rotatividade estão garantidas). Um bom exemplo disso é a funcionalidade de conversação do Intercom ou a pesquisa de opiniões dos clientes no G2.
• Desempenho: Estas funcionalidades criam valor para o utilizador com base na sua prevalência. Quanto mais existirem, maior será o valor. Veja-se, por exemplo, a capacidade/autonomia da bateria de um automóvel elétrico moderno. Uma maior autonomia (geralmente) cria mais valor para os condutores. Outro exemplo é o número de integrações do Zapier.
• Atraentes: Em vez de adicionarem valor direto e resolverem as dificuldades dos utilizadores, estas funcionalidades focam-se antes em melhorar a capacidade de os seus produtos serem apreciados. Entre elas encontram-se secções de visão do produto com um design magnífico numa ferramenta de gestão de projetos ou bancos de couro num automóvel.

Se visualizássemos a relação entre a prevalência destes tipos de funcionalidades e a satisfação dos clientes que proporcionam, seria mais ou menos assim.

Aqui, podemos ver que as funcionalidades de desempenho são lineares por natureza (daí que uma maior quantidade proporcione mais valor). As funcionalidades obrigatórias, por outro lado, não criam muito valor adicional. Em vez disso, destinam-se a eliminar a insatisfação dos seus utilizadores.

Por fim, a categoria das funcionalidades atraentes existe para lhe proporcionar um impulso adicional de satisfação. Mas não terá qualquer efeito se tiver cometido erros com alguma das suas funcionalidades "obrigatórias".

O modelo de Kano na vida real

Como aplicar o modelo de Kano na vida real? Com base na minha experiência, o Kano é raramente utilizado em reuniões de priorização ou de geração de ideias. A razão é que se trata de algo extremamente intuitivo, não sendo necessário desenhá-lo no quadro branco e pedir às pessoas que classifiquem as suas funcionalidades com base nestas três categorias.

Em vez disso, normalmente ensinaria as suas partes interessadas a pensar segundo o modelo de Kano. Graças a isso, antes de lhe apresentarem um novo pedido de funcionalidade, passarão a ideia por esta estrutura mentalmente e decidirão se é algo que vale a pena explorar ou não.

Desta forma, está a delegar parte do trabalho de priorização de funcionalidades nas suas partes interessadas e a poupar imenso tempo em longas sessões de geração de ideias.

2. Método MoSCoW

O método MoSCoW está entre os métodos mais populares para dar prioridade às funcionalidades. As duas razões por trás da sua popularidade são a simplicidade e a eficácia.

Para aplicar este método, só precisa de analisar cada funcionalidade da sua lista e atribuir-lhe uma destas quatro prioridades:

• Obrigatório
• Deveria ter
• Poderia ter
• Não terá

Normalmente, atribui estas prioridades com base numa combinação de fatores, incluindo o valor que cria para os utilizadores, o valor para o negócio, o alinhamento estratégico, a complexidade da implementação, entre outros.

Eis o aspeto de uma lista típica de funcionalidades para um serviço de transmissão de música se aplicar o MoSCoW.

• Aqui, atribuímos ao modo offline a prioridade de “obrigatório”, considerando que muitos dos nossos utilizadores irão ouvir música a bordo de um avião.
• As experiências de realidade virtual, por outro lado, receberam a prioridade de “não terá”, porque são bastante difíceis de implementar e muito poucos utilizadores têm auscultadores de realidade virtual para as experimentar.

MoSCoW na vida real

Embora possa utilizar perfeitamente o MoSCoW para ajudar a orientar as suas reuniões de definição de prioridades, existe uma desvantagem que o torna menos eficaz nestes casos.

Como a prioridade se baseia numa combinação de múltiplos fatores, torna-se bastante moroso para cada membro da equipa explicar a lógica subjacente às suas decisões relativas ao produto. Na minha experiência, as sessões de MoSCoW são bastante lentas e ineficientes em comparação com outras estruturas.

Mas isso não significa que não goste do MoSCoW. Na verdade, é a estrutura que utilizo com mais frequência. O meu local preferido para utilizar o MoSCoW é a lista de funcionalidades de um PRD.

Normalmente, dou aos leitores contexto sobre o valor para o utilizador, as complexidades técnicas e outros fatores no documento antes de avançar para a lista de funcionalidades. Assim, quando veem “Obrigatório” junto a uma delas, têm o contexto necessário para compreender rapidamente a lógica por detrás da minha decisão.

Desta forma, o MoSCoW permite-me obter uma lista de funcionalidades fácil de compreender num documento de requisitos do produto.

3. Método RICE

Ao contrário dos dois métodos anteriores, o modelo de pontuação RICE é um pouco mais estruturado e depende menos de decisões baseadas na intuição. Identifica quatro fatores distintos de definição de prioridades e permite quantificar e avaliar cada um separadamente. Estes fatores são:

• Alcance: Representa a proporção dos seus utilizadores que será afetada por esta funcionalidade.
• Impacto: A dimensão do próprio impacto.
• Confiança: Mostra se tem confiança de que as pessoas alcançadas obterão esse impacto.
• Esforço: É o período de tempo de que a sua equipa de desenvolvimento e produto necessita para preparar esta funcionalidade.

Normalmente, o que faz é escolher uma funcionalidade e, em seguida, atribuir uma pontuação entre 0 e 10 a cada um destes quatro fatores. Depois, calcula a pontuação RICE com esta fórmula.

Por fim, ordena a sua lista de funcionalidades pela principal métrica desta estrutura: a pontuação RICE (pontuação mais elevada = prioridade mais alta). Eis o aspeto do resultado de uma definição de prioridades RICE.

• Nesta lista, podemos ver que a Nova IU recebeu a pontuação mais elevada graças ao baixo esforço e ao elevado alcance/impacto.
• A funcionalidade Sincronização na nuvem, por outro lado, está no final da lista devido ao elevado esforço necessário para a implementar.

A pontuação RICE na vida real

Tenho referido várias vezes que tanto o MoSCoW como o Kano não são as opções mais adequadas para reuniões de definição de prioridades e sessões de brainstorming. Mas que estrutura utilizo nesses casos? O RICE!

Ao atribuir pontuações separadas a cada fator, facilita a apresentação da lógica subjacente às decisões durante estas reuniões (algo que falta no MoSCoW). Além disso, pode delegar a pontuação de cada fator nos colegas de equipa que têm mais conhecimentos nessa área.

Por exemplo, a sua equipa de desenvolvimento de produto é a mais indicada para atribuir a pontuação de esforço. Os seus analistas de dados, por outro lado, compreendem melhor o alcance potencial dessa funcionalidade.

4. Mapeamento de histórias de utilizador

Tecnicamente, Mapeamento de histórias de utilizador não é uma estrutura de priorização. Em vez disso, é utilizado para organizar o trabalho a realizar pela sua equipa e descobrir quaisquer funcionalidades que tenha de adicionar para criar percursos de utilizador completos.

Para criar um mapa de histórias, irá enumerar as principais atividades dos utilizadores (ou tarefas) e, em seguida, anotar as tarefas que os utilizadores têm de concluir para cada uma delas. Depois, irá listar todas as funcionalidades que precisa de criar para permitir que os seus utilizadores concluam essas tarefas. Pode fazê-lo com notas autocolantes num quadro branco ou utilizar uma das muitas ferramentas para gestores de produto dedicadas.

Eis o aspeto do mapa para um serviço de transmissão de música.

Provavelmente, não fará muita priorização nesta fase.

No entanto, o processo de anotar as funcionalidades necessárias para cada tarefa continuará a ajudá-lo na priorização, pois irá perceber que faltam funcionalidades para determinadas atividades (que são prioritárias para si).

Em seguida, adicionará rapidamente estas funcionalidades em falta à sua lista de pendências e irá movê-las para o topo, para garantir que cobriu com sucesso essa atividade específica para os seus utilizadores.

No exemplo acima, temos um mapa de histórias de um MVP em desenvolvimento ativo (as histórias concluídas têm uma marca de verificação junto ao nome). Ao analisá-lo, veremos que a atividade de Gestão de contas está incompleta, uma vez que ainda não criámos os inícios de sessão através das redes sociais.

Por isso, antes de começarmos a trabalhar na pesquisa de artistas/álbuns, devemos concluir primeiro a atividade de gestão de contas.

Mapas de histórias na vida real

Tal como o RICE, os mapas de histórias são uma excelente opção para as suas reuniões de priorização e de geração de ideias. Um dos principais benefícios da utilização desta estrutura é a sua capacidade de trazer a perspetiva do utilizador para a sala de reuniões.

Ao analisarem as atividades e tarefas dos utilizadores, os seus colegas terão menos probabilidades de sugerir ideias de funcionalidades irrelevantes para as necessidades e dificuldades dos seus clientes. Mesmo que as sugiram, poderá atribuir-lhes facilmente uma prioridade baixa, considerando que essas funcionalidades não ajudam os utilizadores a concluir as suas tarefas.

5. Pontuação de oportunidades

Estruturalmente, a pontuação de oportunidades é semelhante ao RICE. No entanto, ao contrário da sua equivalente, os critérios do sistema de pontuação de oportunidades não estão definidos de forma rígida, cabendo-lhe a si escolhê-los.

Para alinhar, por exemplo, o seu roteiro de alto nível com a sua liderança, poderá considerar a adequação à estratégia do produto, a viabilidade e a receita potencial como critérios. Eis o aspeto de um roteiro deste tipo, priorizado com esta estrutura.

Aqui, utilizámos uma escala de 0 a 5 para pontuar cada fator e calculámos a soma de todos os fatores para cada item da lista.

Cartões de avaliação na vida real

Graças à flexibilidade de escolher os seus próprios critérios, os cartões de avaliação são perfeitos para reuniões de alinhamento entre equipas.

Por exemplo, se precisar de alinhar o seu roteiro com as equipas jurídica e de segurança e conhecer as suas opiniões sobre as prioridades, escolha critérios que sejam relevantes para elas (por exemplo, risco de processo judicial vs. valor empresarial). Com a sua equipa de marketing, por outro lado, poderá utilizar o esforço, o custo, o alinhamento com os objetivos empresariais, o alcance de mercado e a confiança como critérios.

6. Matriz de esforço

Lembra-se da Matriz de Eisenhower, utilizada para priorizar as suas iniciativas pessoais? Bem, a matriz de esforço é uma versão desta, mais adaptada ao trabalho com novas funcionalidades de produto.

O nome completo é Matriz de valor vs. esforço, uma vez que permite visualizar a relação entre estes dois fatores para cada uma das suas tarefas. Eis o seu aspeto.

Coloca o esforço no eixo Y e o valor para o cliente no eixo X. Depois, tal como na Matriz de Eisenhower, divide-a em 4 quadrantes e coloca as suas funcionalidades em cada um deles, dependendo do seu valor e esforço. Em seguida, prioriza as suas tarefas pela seguinte ordem:

1. Vitórias rápidas (funcionalidade de elevado impacto que pode realizar agora)
2. Grandes projetos (as suas funcionalidades estrategicamente importantes)
3. Complementos (funcionalidades potenciais com uma implementação simples a considerar mais tarde)

Quanto às funcionalidades no quadrante dos desperdiçadores de tempo, normalmente irá descartá-las, uma vez que não há qualquer razão para as manter na sua lista de pendências.

Matriz do esforço na prática

Tanto o principal benefício como a desvantagem desta estrutura residem na sua simplicidade.

É uma vantagem, pois pode explicar facilmente o processo de priorização às pessoas presentes e começar imediatamente a escolher as funcionalidades certas com ela.

A desvantagem é que a matriz do esforço não mostra os diferentes fatores que desempenham um papel importante na priorização (confiança, alcance, dependências, etc.).

Assim, o melhor caso de utilização desta estrutura são reuniões breves de alinhamento, nas quais os detalhes não são importantes (uma vez que, normalmente, haverá uma sessão mais aprofundada com recurso ao RICE como acompanhamento).

Alinhe as partes interessadas com o seu roteiro de produto

É importante dar prioridade ao seu trabalho. Mas isso não terá qualquer valor se não tiver alinhado todos em torno das suas prioridades. Muitas das estruturas que discutimos hoje são colaborativas por natureza e permitem obter esse alinhamento automaticamente.

Mas, se decidir escolher aquela que não exige reunir todas as partes interessadas na mesma sala, certifique-se de que partilhou a sua lista priorizada com as pessoas relevantes e que a alinhou com as suas expectativas e necessidades.

Não se esqueça de subscrever a nossa newsletter para obter mais recursos e guias sobre gestão de produto, bem como os podcasts, entrevistas e outros conteúdos mais recentes de líderes e especialistas do setor.