Você já ouviu falar sobre NFR (New Feature Requests)? Basicamente, é um processo onde departamentos, e as vezes até clientes, solicitam ao time de produto funcionalidades ou novos recursos para o seu produto. Podemos dizer que é um canal oficial de coleta de ideias, também conhecido como Inputs Gathering.
Essa coleta de ideias pode acontecer de duas formas:
Descentralizada - Formato que empodera os demais times a criarem tickets. Nesse formato, é mais difícil a identificação de ideias de qualidade, além da organização de ideias tão dispersas em um único local. Centralizada - Formato que cria um "gatekeeper" (guardião) que conversa com diferentes departamentos e só ele(a) cria o ticket, aproveitando o mesmo formato e qualidade. Nesse formato, produto pode acabar se tornando o gargalo que tanto trabalha para combater.
Veja que, cada formato tem o seu "downside", ou seja, o seu ponto negativo. O desafio é você observar o seu time de produto, o seu relacionamento com outros departamentos, ferramentas, e identificar qual você considera o mais interessante para o seu momento.
O maior desafio, todavia, não é apenas a criação do ticket, e sim a comunicação com os demais departamentos. Muitos reclamam de não serem ouvidos adequadamente por produto, outros que não possuem atualizações sobre seus tickets, entre outras falhas de comunicação.
Para dar uma ideia da importância desse processo, segundo pesquisa da Pendo de 2020, As 2 maiores fontes de ideias de produto para Produtos B2C vem de outros Times de Produto (43%) e de Outros Departamentos (30%). Por isso, é vital que você tenha esse processo de aprendizado muito bem organizado para alimentar o seu produto adequadamente.
Todavia, pera pera pera.. você já parou para pensar que essa palavra é MUITO engraçada? To-da-vi-a Toda-via, melhor que ela só "Não obstante". Aiai!
Todavia, suportar uma boa comunicação com diferentes departamentos não é uma tarefa simples, diversos sistemas tentam atuar nesse processo, como ProductBoard, Monday, Jira, Pendo, Aha!, Roadmunk e muito mais. Mas a teoria não está dentro de uma ferramenta, então vamos conversar como se você estivesse criando esse processo na unha, seja através do Trello, Google Sheets ou Airtable. Segue uma lista básica de alguns campos que você poderia ter na captura de ideias:
Campos Básicos Título Descrição Autor
Campos Opcionais Priorização (P1, P2 e P3 já funcionam) Tipo de Requisição (Feature, Melhoria, Debt, Documentação) Componente, Módulo ou Categoria Departamento Clientes Impactados Anexos
Veja que com esse trabalho, você já teria uma lista de captura qualificada, identificando melhor soluções, sabendo quem conectar para obter mais informações, entendendo a prioridade da tarefa pela perspectiva do autor (e não sua), se isso impacta alguém (evidência da importância), entre outras informações.
Recentemente na empresa, quebramos o campo de Descrição em 2 campos, para qualificar ainda mais a ideia:
Por que esse pedido? Que problema você está tentando resolver? Qual benefício você vê por trás dessa solicitação? Por que devemos investir nisso? Que valor essa solicitação traz para os usuários ou para a empresa?
Você poderia descrever um pouco mais sobre essa ideia? Você tem mais informações sobre o problema ou solicitação? Você tem algum ticket, material ou evidência que possa nos ajudar a entender melhor e priorizar essa solicitação? Você vê alguma possibilidade de quebrar este pedido em pequenas entregas? Como ideia deve funcionar?
Basicamente, através dessa quebra, a gente captura o "porquê" da ideia primeiro, e o "como" e "o que" na segunda pergunta. Isso leva a qualidade da descrição a um outro nível, entendendo os benefícios da mesma, o que sabemos sobre ela, o quanto baseada em evidências ela é, nos ajudando bastante quando fizermos a avaliação técnica da solução, tanto quanto impacto, esforço, quanto confiança.
Por mais que esse formulário mais caprichoso e orientado a qualificação das ideias, sem se tornar muito burocrático para os autores, o segundo problema de acompanhamento da solicitação, ainda pode ser um grande problema. É claro que muitos sistemas já possuem suas próprias formas de trabalhar isso, seja através de tags, colunas (kanban), filtros, agrupamentos, entre outras classificações. Como eu disse anteriormente, para você trabalhar a teoria, pense que essas ferramentas não existem, como você comunicaria o status de cada tarefa?
Depois de estudar dezenas de nomenclaturas de diferentes fontes, sistemas e produtos, vou compartilhar a que eu considerei mais objetiva e completa, inclusive utilizando atualmente no meu processo de Inputs Gathering:
Sob consideração Todas as solicitações começam a vida neste status. Este é o estágio de coleta de informações em que procuramos usuários para discutir, refinar e votar nos recursos que mais importam para eles.
Atualmente recusado Um pedido que não está em nossos planos imediatos, mas agradecemos novas discussões e votações.
Investigando Uma solicitação é movida para o status de investigação quando nossa equipe está investigando a viabilidade de uma solicitação. Isso não é garantia de inclusão futura.
Planejado Planejado indica que uma solicitação fez ou já faz parte de nosso Roadmap e Backlog. Isso não é garantia de inclusão futura.
Em progresso Isso indica que uma solicitação está sendo trabalhada por nossa equipe.
Concluído Isso indica que uma solicitação foi implementada e liberada.
Já Possível Quando se acredita que uma solicitação já é oferecida pelo produto.
Recusado Uma solicitação que foi recusada e provavelmente não será considerada.
Obs: Os termos são usados em inglês, visto que meu time é internacional, mas coloquei traduzido para facilitar o aprendizado, em inglês os termos seriam Under Consideration, Currently Declined, Investigating, Planned, In Progress, Completed, Already Possible e Declined.
Agora nosso processo de captura de ideias está bem mais robusto e teoricamente coerente, onde eu capturo as ideias com os campos básicos e alguns opcionais que me gerem mais qualificação da ideia (cuidado para não ficar muito burocrático e desanimar as pessoas quanto a participação), e depois aproveito a lista gerada para dar visibilidade aos itens, não só sobre as informações inseridas, mas também o status de cada item.
Você ainda pode utilizar a mesma lista para já avaliar essas solicitações em cima da sua matriz desejada (estamos usando a ICE atualmente). Então, o cliente (autor) conseguiria não só visualizar as ideias do seu departamento (e de outros) como também visualizar o score que ela teve em cima dos critérios avaliados. Isso traz mais transparência e confiança ao processo.
Por fim, uma dica final é trabalhar ao máximo a redundância de informações, colocando descrições abaixo de cada pergunta do formulário de captura, e ainda linkando com uma documentação explicando campo a campo, com exemplos e até mesmo template de preenchimento. Quanto mais mastigada suas informações, maior a adoção de seus pares.
Essa adoção vai gerar muita qualidade para você alimentar seu backlog com evidências, obter mais ideias na hora de discutir oportunidades e soluções para atingir seus resultados desejáveis do Product Roadmap, e melhorar (ainda mais) a relação que produto tem atualmente com todos os departamentos da sua empresa.
Boa sorte :)