Atividades de uma pessoa de Produto - Priorização

Introdução

Priorização é o superpoder de qualquer empresa que queira acelerar seu sucesso.

Na introdução do seu tratado teológico “Mere Christianity” o escritor C.S. Lewis explica que originalmente o termo “Gentleman” (Cavalheiro) descrevia algo bem concreto: Alguém que possuía terras e um brasão. Com o tempo a palavra foi mudando para indicar que aquela pessoa tinha alguma distinção, se metamorfoseando num elogio. Se alguém faz um ato gentil ou polido, é chamado de cavalheiro. Segundo o Lewis isso trouxe um problema: “Cavalheiro" virou uma palavra inútil. Seu significado específico se perdeu, e o novo significado não adicionou nada que já não existisse na língua com outras palavras e sinônimos.

Algo parecido aconteceu com o verbo “Priorizar”. Na definição do dicionário Oxford temos:

1. Designar algo como mais importante que outras coisas

2. Escolher a ordem com que se trata de uma lista de coisas ou afazeres

Talvez você pense que é assim mesmo que todo mundo define. Na prática vejo usarem a palavra “prioridade” com sinônimo de “Isso é importante", o que não comunica algo que ajude a ordenar perante as outras coisas todas que já estavam na fila. “Prioridade” acabou virando uma unidade de tempo. O modelo mental de prioridade é “coisas pra fazer logo” x “outras coisas lá que nem lembro (mas que eram prioridade no passado)”.

As tentativas de categorizar a prioridade, por exemplo “Alta”, “Média” ou “Baixa” só agregam mais uma camada de discussão sem resolver o problema. Quando se tem 10 tarefas com prioridade alta, qual atacar primeiro? E quando algum apressado poderoso inventa a prioridade “Urgente"? Para tudo pra fazer? E se tiver 2 ou 5 urgências?

Vamos dar um passinho pra trás e focar no problema:

Todo lugar, da menor startup até um gigante com milhares de engenheiros, tem exatamente o mesmo problema: Mais ideias do que gente - melhor dizendo, horas - pra executar. As empresas de hierarquia tradicional abordavam esse problema de forma política: A alta gestão define o que será feito num planejamento estratégico e a coisa vai descendo até chegar em tarefas para os times. Se houver algum debate sobre importância relativa, é lá em cima. Os times se preocupavam com qualidade e quantidade de entregas, tentando cumprir com o cronograma esperado.

Só que no mundo digital isso deixou de ser suficiente, como ficou claro no estouro da “bolha .com” nos anos 90. Um monte de empresas embarcando nas possibilidades de inovação que a internet oferecia falhando em capturar o interesse do público e indo à falência.

A lição foi dura, mas concreta:

• Focar nos processos de entrega, aumentando velocidade ou quantidade de tarefas não garante sucesso

• Sucesso vem ao entregar coisas que tenham valor para o usuário

Executar bem é o mínimo, não é nem pra ser discutido. Temos as ferramentas e conhecimento necessários. O foco sai da execução para a escolha criteriosa do que fazer. O que se escolhe executar é o que muda o ponteiro. A discussão do que fazer precisou ficar mais metódica e menos política, porque é aí que se constrói vantagem competitiva.

E aí entra a utilidade da palavra “Prioridade”. Como dito lá em cima, é decidir a ordem em que as coisas serão feitas. Ordenar não qualifica importância, é simplesmente montar uma fila de coisas pra fazer: Primeiro essa, depois aquela. Política não ajuda ou clareia o processo. Se o CEO deu 20 ideias espetaculares, alguma precisa ser a primeira, alguma será a segunda, alguma terá que ser a vigésima. Nada muda o fato de uma pessoa executar uma tarefa de cada vez. Pra começar a fazer uma coisa precisa interromper ou terminar outra. Isso é verdade pra times de 1 ou 1.000 pessoas. A capacidade aumenta, mas algo ainda precisa ser escolhido pra fazer primeiro.

Ao fazer isso se consegue rapidamente corrigir o rumo em caso de insucesso. Se a primeira tarefa já não surtiu efeito, o que se aprendeu com isso? Vale a pena prosseguir pelas outras ou agora sabemos algo que invalida a fila toda? Se muda o público-alvo a ser impactado não seria melhor passar a tarefa número 14 pro topo da fila?

Isso como se percebe é um trabalho contínuo, complexo, e fazer direito demanda dedicação constante em extrair informações de comportamento dos usuários lá fora.

Exatamente pra isso foi criada a área de Produto.

Como Priorizar

Depois de tentar boa parte dos frameworks mais famosos acabei desenvolvendo um próprio que uso em qualquer lugar que eu passe. Não é nada revolucionário (é só uma adaptação do framework mais básico de todos) mas o que vale aqui é explicar porque funciona e assim você ganha mais uma opção no seu repertório.

Como expliquei anteriormente, priorizar com critério político começou a falhar. Cargo ou senioridade não significa conhecer e acompanhar a fundo os comportamentos do público lá fora, ainda mais com as mudanças aceleradas causadas pelo advento da internet e hardwares exponencialmente mais poderosos.

Priorizar então precisa ser algo mais analítico possível. Várias tentativas de deixar esta análise mais evidente foram feitas, não vou dizer o que é melhor ou pior, mas vou analisar alguns frameworks apenas de um único ponto de vista: A possibilidade de manipulação política.

Ou seja: Se a pessoa que demite estiver na sala, ela consegue aumentar a prioridade de tudo que gosta mais? Vejamos:

Alta/Média/Baixa

É a primeira que todo mundo tenta. Parece fazer sentido mas rapidamente as pessoas percebem algo: Categorizar como “Baixa” significa nunca fazer. Então quem deu a ideia vai defender com unhas e dentes que a prioridade é no mínimo “Média”. Enquanto isso as pessoas com mais poder vão conseguir que suas tarefas sejam “Alta”. Com isso o backlog fica com 20 tarefas “Alta", algo que talvez já leve o semestre inteiro, e nenhum critério do que fazer primeiro.

Prioridade numérica

Explicar que se tenho 20 tarefas então precisam haver prioridades nos valores de 1 a 20 normalmente não adianta nada, ninguém quer ser o 18. Dizer “Isso aqui também é 2” acaba sendo possível só pra não aborrecer ninguém. Com o tempo o backlog tem 20 tarefas “Prioridade 1” mais umas 10 que o CEO falou que era “Prioridade 0”.

MoSCoW (Must, Should, Could, Won't)

Ajuda a agrupar de uma forma mais objetiva, mas já vi sair quase morte na sala com alguém não aceitando que sua necessidade seria “won't” defendendo que fosse “must”. Funciona melhor no meio de projetos que estouraram prazo e precisam de um choque de realidade.

Now, Next, Later

Esse abraça a subjetividade da coisa, é um “Lutem aí pra decidir os quandos, os porquês não são problema meu”. Ainda assim funciona bem no planejamento estratégico, dando para a liderança uma forma clara de comunicar o que considera sucesso a curto, médio e longo prazos. Pra backlog, mesmo problema de sempre, tudo vira “Now”, nada é “Later”, a fila só cresce pelo topo.

ICE/RICE e similares

Acho particularmente insidiosos, porque fazem o mesmo que por exemplo NPS ou Story Points: Dão valores supostamente objetivos que apenas disfarçam critérios subjetivos. Dizer que “calculou” o score de uma tarefa em 435 e da outra em 280 parece ser super preciso. Mas o cálculo se baseia em quê? Como dar um valor de 1 a 10 para “o quão fácil uma tarefa é?” (“E”). Como prever impacto (”I”) de algo que você nem fez gerando consenso da nota? O que é impacto “6”? E o que raios é “Confiança” senão uma arma política pra um líder dizer “Aqui eu tenho 10 de confiança” subindo a pontuação da tarefa e ninguém querer discutir? Muita ideia ruim vai pro ar promovida por alguém 100% confiante. Isso tem zero relação com a probabilidade de sucesso do lançamento.

Já o “Reach” do RICE é útil porque pode ser calculado sem relativizações. Quanto do meu público será impactado pela mudança? 100% ou 10%? Use isso como critério de ordenação (Não sabe? Ótima desculpa pra olhar o analytics).

Mas e aí o que fazer?

Por onde passo a dificuldade principal é sempre a mesma: Fazer a alta gestão articular direito as prioridades e ficar confortável com a ordem da fila resistindo ao impulso de mexer toda hora enlouquecendo os times. O que faço pra tentar solucionar é uma adaptação simples do framework mais básico de priorização, de onde nasceram quase todos os outros: A matriz de Impacto x Esforço.

Quem estudou a literatura de Produto ou de projetos ágeis já se deparou com esta matriz. Você mede o impacto e esforço em alto e baixo, aí as coisas de alto impacto e baixo esforço vão pro topo da fila. Como vimos acima “alto” e “baixo” não resolve muito satisfatoriamente, já vi tanto as gestões insistirem que a ideia deles era “obviamente alto” quanto os times de execução dando esforço alto pra algo que eles não tavam muito a fim de fazer.

O problema não é da matriz em si, é semântico. “Alto” e “Baixo” dependem sempre do referencial, e cada pessoa pode legitimamente ter o seu. Quais palavras poderiam ter significados mais objetivos, facilmente compreendidos por todos e úteis para gerar prioridades bem feitas? Eis o que uso em cada uma das dimensões:

Impacto (Direto/Indireto)

A primeira coisa é definir “impacto” sem subjetividade. O que uso é impacto das metas numéricas (podem ser OKRs) daquele time ou grupo. Uma nova forma de login pode ser super impactante se minha meta é aumento no número de cadastros, e irrelevante se tenho meta de visitas nas páginas de produtos.

Uma vez escolhida a meta, os adjetivos que descobri que conseguem amenizar muito as dissidências é “direto” ou “indireto". A escolha de palavras aqui é crucial. Impacto direto é fácil de perceber, o exemplo acima já mostra. Só que a pessoa pode achar que login é muito útil pra visitar produtos porque se eu sei quem é o usuário posso melhorar as recomendações e aí se clicar no carrossel pode ver mais produtos e… Aí você pode falar “Ok, tem razão. Tem impacto mas é mais indireto”, com o que as pessoas acabam concordando, afinal tem uma série de passos que precisam dar certo pro impacto aparecer. É muito mais tranquilo que dizer “Essa ideia não serve” ou “Isso tem prioridade baixa”.

A qualificação do impacto deve ser feita pela pessoa de Produto e quem está pedindo a task.

Esforço (Simples/Complexo)

Na computação existe um conceito que expressa a dificuldade de entregar algo: A complexidade. Algo “complexo” ou tem pontos desconhecidos ou interdependências com outros sistemas. Algo que não depende de terceiros e é plenamente conhecido é “simples”. Perceba que não há nada aqui refletindo a duração da tarefa. Pode existir algo simples e razoavelmente demorado, por ter muitas coisas a implementar. E não necessariamente algo complexo demorará. Como isso é útil então?

Lembre-se do que estamos tentando fazer: Priorizar as coisas certas, e pra isso quero diminuir a probabilidade de uma tarefa ficar se arrastando e atrasando a fila inteira. Se tenho coisas simples na fila, faço primeiro, afinal o time já as inicia com plena noção do que fazer e vai entregar tranquilamente. Depois vou olhar as complexas, que talvez empaquem um pouco, exijam pesquisa, mostrem que a documentação daquela API estava desatualizada, esbarrem no conhecimento de alguém de férias e outras formas que uma tarefa acaba criando tentáculos e crescendo de tamanho.

Como estou usando uma definição técnica, quem me diz se algo é simples ou complexo é o time que executa, jamais quem chega com o pedido. “Tenho aqui uma ideia de coisa simples pra fazer” é o início de um monte de histórias de terror.

Finalmente priorizando

Agora já temos tudo que precisamos pra desenhar nossa matriz de priorização:

Perdão pelos termos em inglês, creio que já são familiares. Depois de classificar nossas tarefas nessas 4 categorias já podemos estabelecer a priorização

Quick Wins

Tudo que é simples de fazer e tem impacto direto na meta deve estar no topo do backlog. Com sorte, você tem um monte pra fazer. Eu aconselho ordenar- agora sim - por duração. As tarefas mais curtas primeiro, pra já mexer algum ponteiro logo de saída e ganhar boa vontade de todos com o trabalho de priorização enquanto faz as tarefas mais longas.

O objetivo da ideação é achar Quick Wins. Seu backlog idealmente deve crescer pelo topo. Comece pensando na meta, traduza-a nas ações que o usuário faz, e imagine otimizações.

Big Bets

Coisas que impactam a meta mas são complexas, ou seja, a duração estimada pode furar. Iniciar uma tarefa dessa é embarcar numa aventura rumo ao desconhecido, mas muitas vezes são essas coisas que realmente são capazes de furar bolhas e elevar o patamar de um produto. Não se pode ter medo delas mas há que se saber que quando um time pega uma big bet pra fazer, pode ficar ocupado por bastante tempo. É melhor pegar quando não houver quick wins na fila ou quando algo grande é pré-requisito de outras coisas que se sabe que virão mais à frente.

Low-Hanging Fruit

Simples mas talvez não super impactantes. Fazer uma pode não fazer diferença mas fazer umas 20 talvez faça por sanar várias dores esparsas de nichos de usuários. Prefiro então juntar todas e fazer de uma vez numa Sprint específica, ou escolher algumas que agradam aquele cliente especial pra fortalecer relacionamento.

Ralo de dinheiro

Complexo de fazer e pouco impactante na meta. Precisa ler mais o quê aqui? Evite como a praga, deixa pra lá e passa pro próximo parágrafo. Se você só tem isso no seu backlog está com problemas na ideação, vai lá falar com os usuários, eu espero (mas seus concorrentes não).

Juntando tudo pra ordenar o backlog perfeito

Os Quick Wins devem sempre ir lá pro topo do backlog. Enquanto você tiver coisas simples e provavelmente impactantes pra tentar, vai com tudo. Só não esqueça de medir os impactos pra provar se as hipóteses sobre o público estão corretas, e se não estiverem qual aprendizado fica pra ser utilizado em novas hipóteses.

E o que acontece se temos 50 quick wins? Acontece que você achou um atalho pro sucesso. Agrupar tarefas é nocivo quando o critério é político. Nesse caso, se tudo tiver impacto direto na meta a ordem dessas tarefas não é tão essencial assim. O que essa matriz faz é te ajudar a separar 4 grandes grupos, a ordem dentro deles é muito menos relevante do que saber a fronteira certinha entre uma big bet e um ralo de dinheiro.

Depois dos Quick Wins eu analiso a quantidade de Big Bets e Low-Hanging Fruit (LHF) que já tenho. Se tenho poucos LHF, deixo acumular mais enquanto pego a Big Bet mais promissora. Quando junto vários, ataco em grupo como expliquei.

E Ralo de Dinheiro é o abismo profundo pra onde as ideias duvidosas vão morrer.

Embora o racional disso tudo seja longo, não estou reinventando nada. Sei que essa análise parece radical, não se preocupe se discordar. Meu objetivo aqui é dar mais ferramentas críticas quando formos escolher uma metodologia de trabalho. Uma escolha só pode ser feita entendendo os pontos fortes e fracos de cada opção, e assim entender o que se adapta melhor ao seu ambiente. Minha tese central é que priorização é um problema muito mais político e de comunicação entre as partes do que estritamente técnico. O que aprendi na prática é que gerar consenso baseado em coisas concretas funciona sempre melhor que usar termos abstratos e querer buy-in de todos. Se você consegue isso usando alguma outra metodologia, segue esse rumo (mas guarda as lições daqui porque algum dia você estará em outro ambiente e pode precisar de novas ferramentas!)

E os bugs?

É muito usual a descoberta de bugs abrir uma linha paralela a isso tudo que falei, indo pra uma fila de “expedite” ou coisa parecida para que o time pegue imediatamente ao invés de andar com as tarefas normais. Confundindo prioridade com uma subjetiva “importância” todo bug descoberto causa um mini-pânico, parecendo importante, portanto prioritário. O objetivo é nobre, mas o princípio está equivocado.

Essa urgência vem de uma ideia de que um bug é uma falha, uma anomalia no código que não deveria estar ali e precisa ser extirpada imediatamente, só que isso não é verdade. Em sua bíblia do programador “Code Complete” (1993) Steve McConnell diz que a média da indústria é de 15 a 50 erros a cada 1.000 linhas de código. Na Microsoft ele tinha conseguido chegar a 10 a 20 erros por 1.000 linhas, diminuindo pra 0.5 nos códigos lançados em produção.

Pra chegar nisso ele desenvolveu várias técnicas detalhadas no livro, como sintaxe rigorosa e testes independentes. Isso obviamente tem um custo, cada linha de código em produção então era muito mais cara que a média da indústria. Um triunfo do conhecimento humano e de jogar dinheiro num problema pra solucioná-lo!

…Mas você lembra dos produtos da Microsoft como livres de bugs? A tela azul acontecia num software que tinha em média 1 mísero erro a cada 2.000 linhas. O Windows NT 4.0 de 1996 tinha por volta de 12 milhões de linhas de código. Aplicando a média acima podemos estimar que foi lançado com 6.000 bugs (E quem usou deve provavelmente estar concordando com a cabeça).

A versão atual do Windows passa de 100 milhões de linhas de código, o que daria 50.000 bugs mesmo aplicando todas as técnicas encarecedoras de código propostas pelo McConnell.

E software de avião ou espaçonaves? Pois é, esses se tiverem erro matam gente e botam bilhões de dólares em risco. Técnicas mais apuradas de desenvolvimento e testes como a “Cleanroom” de Harlan Mills chegaram numa média de 0.1 erros a cada 1.000 linhas e no caso do software do primeiro ônibus espacial 500.000 foram pra produção sem erros detectados.

Pra se ter uma ideia de custo, em média cada desenvolvedor lançou com sucesso 2.600 linhas de código em 10 anos. Sim, 260 linhas (Menos que esse texto aqui da newsletter, que escrevi manualmente por quatro dias) por ano, 20 e poucas por mês. O software do Boeing 787 teve um ritmo parecido de 15 linhas por profissional-mês.

Pegue então o salário que você paga a um desenvolvedor, divida por 20 e este é o custo de uma única linha de código. Agora multiplique pelo número de linhas do seu produto - facilmente passou de dezenas de milhares - e este é o custo dele sem bugs. A conta fecha? Apenas lembre que cada pessoa vai soltar umas 20 linhas por mês. Espero que você seja bem jovem ou tenha algumas centenas de squads.

Não estou levando em consideração código escrito por IA aqui porque acredito que ainda surgirão análises acadêmicas mais profundas e otimizações levando em conta quantidade e qualidade do código gerado. Provavelmente os índices de bugs cairão, mas o fato de serem proporcionais à quantidade de linhas escritas permanecerá. Em algum lugar alguém esqueceu de algum caso de borda que vai acabar acontecendo. Sua opção é sucumbir à paranoia e sangrar dinheiro atrasando o desenvolvimento do que importa mais ou…

Priorizar bugs exatamente como qualquer outra coisa

Todo bug pode e deve passar pela matriz acima. Impacta na meta? Não esqueça de levar em conta quantas pessoas potencialmente vêem um bug. Já estive num e-commerce que tinha um bug péssimo na home page causando um mal-estar generalizado… até alguém (a modéstia me impede de dizer quem) mostrar que menos de 0.1% do tráfego passava pelo ponto onde o bug ficava visível, e não havia diferença na taxa de conversão de quem fazia isso ou não. Baixo impacto, incêndio controlado, consertamos quando foi conveniente.

Esforço também deve ser levado em conta. Bugs complexos de alto impacto devem ser priorizados como Big Bets, e os de baixo impacto podem ser ignorados. Dizer isso em voz alta pode causar mal-estar, mas é a decisão correta pra não entrar em ralo de dinheiro.

Chegou até aqui? 🏆

Agradeço e peço desculpas pelo tamanho pouco conveniente. O assunto é importantíssimo e por mais que muita gente já tenha falado acredito que esta forma de dissecá-lo adicione algo no seu repertório. Escrevo por amor à área e pra dar meu quinhão no desenvolvimento de produtos espetaculares no Brasil. Se achou útil, compartilhar com seus pares me ajuda muitíssimo.

Este artigo é parte da série “As 6 Atividades de Produto”, os outros textos estão aqui:

Quer mentoria, palestras ou contar comigo na sua liderança? Veja como trabalho aqui: https://produtoopentalent.com

Até o próximo número,

Fábio