Existem milhares de formas de se desenvolver um produto e certamente cada Product Manager tem o seu próprio processo de como fazer isso. Olhando de uma forma macro, minimamente, esse processo vai contar com dois grandes blocos, um de Discovery e outro de Delivery. Seja o que for que acontece nesses dois momentos, se você estiver fazendo a “coisa” certa, em algum ponto você vai ter que descobrir o que fazer no seu produto e depois entregar para o seu cliente o resultado dessa descoberta.
Normalmente, o que vejo acontecendo, é que quando uma organização de produto nasce dentro de uma empresa não se tem um processo claro de como fazer produto. Isso é perfeitamente entendível e até desejável, já que quando você tem um ou dois PMs no time não tem por que ficar se preocupando com esse tipo de coisa. No entanto, quando o seu time começa a crescer os problemas começam a aparecer. Três sinais bem fortes que vejo que indicam a necessidade de você começar a ter um processo padronizado de como fazer desenvolvimento de produto na sua empresa são os seguintes:
- Em algum momento você vai precisar criar um Kanban de Portfólio, para organizar e dar visibilidade a tudo que que está sendo feito no seu produto. Se você for tentar criar esse Kanban sem ter um processo minimamente definido e equalizado entre todos os times vai ser uma missão bem ingrata.
- Com o crescimento do time você, como líder, vai precisar guiar o seu time de PMs sobre a melhor forma de se desenvolver produtos e, se você não tiver um processo minimamente definido, com uma nomenclatura comum entre todos, toda vez que você for ajudar determinado PM boa parte do tempo da conversa vai ser gasto para entender o processo que aquele Product Manager está seguindo e o que deveria ser feito em cada etapa do processo dele ou dela.
- Com novas pessoas de produto entrando no time você vai precisar explicar para cada uma delas como é feito produto dentro da sua empresa. Se cada PM tiver a sua própria maneira de fazer produto esse “processo” vai ser bem confuso e quase impossível de ser replicado.
Se você estiver passando por pelo menos uma dessas situações, que normalmente acontecem quando o seu time tem algo entre 3 e 5 Product Managers, provavelmente chegou a hora de definir um processo mínimo de desenvolvimento de produto para a sua empresa, ou, como prefiro chamar, um Framework de Desenvolvimento de Produto. Gosto da palavra “framework” porque fica mais claro que cada PM tem liberdade para customizar esse framework de acordo com a sua necessidade, mas, idealmente, existe um processo base que precisa ser seguido. Foi justamente isso que precisei fazer no Nubank recentemente, em parceria com o João Menezes (Designer Manager) e achei que fazia sentido compartilhar esse conhecimento.
Definindo um Framework de Desenvolvimento de Produto
Nos últimos anos, tanto na Resultados Digitais quanto mais recentemente no Nubank tenho utilizado um framework com as seguintes etapas (ao longo do tempo houveram inúmeras alterações, mas esta é a versão atual):
Para facilitar o entendimento, vou tentar explicar em mais detalhes cada uma delas a seguir.
Exploração
Definição: Essa é a fase onde o time irá explorar um determinado problema ou oportunidade (se você estiver utilizando uma árvore de oportunidade isso é bem claro). A ideia aqui é entender muito bem o domínio do problema em si e avaliar se faz sentido priorizar este problema, neste momento. Essa fase tem uma mortalidade altíssima, e eu diria que menos de 20% das iniciativas que começarem a serem exploradas realmente vão seguir para a próxima fase.
Alocação: Quem lidera essa fase normalmente é um Product Manager, mas pelo menos uma pessoa de Design já deveria estar sendo envolvida neste momento. Idealmente, alguém de Engenharia também.
Entregáveis: Minimamente, nessa fase, se a opção for seguir com a iniciativa adiante, espero ver os riscos de produto envolvidos no problema/oportunidade mapeados e mitigados/validados e um Press Release, contendo também um FAQ e os critérios de sucesso da iniciativa.
Solução
Definição: Com o problema definido e priorizado agora é o momento de o time pensar na solução para esse problema, ou seja, como de fato o produto será criado, alterado ou estendido de tal forma que entregue valor para o seu cliente. Neste momento é fundamental que o PM mantenha o time focado nos objetivos pelos quais estamos construindo essa solução e que todo o time seja envolvido neste processo. Diferente da fase anterior, a fase de Solução já tem uma mortalidade de iniciativa mais baixa, mas ainda assim somente 70% a 80% das iniciativas seguem em frente.
Alocação: Quem normalmente lidera essa fase é uma pessoa UX Designer, mas a participação de Engenharia aqui é fundamental. O papel do PM nesta fase é muito mais para guiar o time e ajudar com provações do que de fato criar a solução final.
Entregáveis: Eventualmente será necessário atualizar os critérios de sucesso, mas o mais comum é que ao final desta fase exista pelo menos um documento, que costumo chamar de Solution Doc, descrevendo a solução em si, tanto do ponto de vista de produto/ux quanto de engenharia.
Desenvolvimento
Definição: Uma vez que você tenha a solução definida chegou a hora de, de fato, construir o seu produto. A fase de Desenvolvimento talvez seja a mais amplamente conhecida e onde as pessoas conhecem uma gama enorme de metodologias e frameworks (Scrum, Kanban, XP, etc), então não vou investir muito tempo aqui. Do ponto de vista de Product Management o importante é garantir que o time continue focado no objetivo pelo qual o produto está sendo desenvolvido e, eventualmente, estar disponível para tirar dúvidas que o time possa ter.
Alocação: Quem lidera essa fase é Engenharia, com grande participação de Design. Neste momento gosto de ver o/a PM como alguém que vai auxiliar o time quando necessário mas não estará tão envolvido no dia a dia.
Entregáveis: Naturalmente o principal entregável aqui é o produto em produção e funcionando de forma estável e confiável. Também é nesta fase onde normalmente é definido uma estratégia de rollout e posteriormente de lançamento/comunicação da nova feature ou produto. Outros entregáveis que podem exigir participação do PM são atualizações de documentações e processos como Central de Ajuda, processos de atendimento ao cliente (Suporte, CS, etc), atualizações de discurso de vendas, pricing, a construção de dashboards para monitorar o produto nas etapas posteriores, etc.
Beta
Definição: O objetivo da fase Beta é testar toda a solução que foi definida e construída. Normalmente uma boa estratégia de rollout já inclui liberar o produto para poucos usuários/clientes no início, mas essa fase vem para reforçar isso e fazer com que o time mensure se tudo está certo com o produto como um todo, ou seja, não só a engenharia e o design do produto, mas se o valor realmente está sendo entregue, se a comunicação está funcionando, se o time de suporte está conseguindo atender as dúvidas dos clientes, se o time de vendas conseguiu adaptar o discurso de vendas, se os parceiros estão alinhados, etc. A idéia aqui é realmente fazer um lançamento simulado do seu produto e testar tudo o que isso envolve, para corrigir o que for necessário antes do lançamento oficial.
Alocação: Normalmente é o/a PM quem irá liderar essa fase, com uma grande participação de uma pessoa de Product Marketing, se houver. Tanto Engenharia quanto Design também são muito envolvidos.
Entregáveis: Por característica da fase Beta (ser um teste) essa é uma fase onde normalmente não tem um entregável claro, normalmente é apenas uma atualização/correção dos materiais que já foram feitos, incluindo o Plano de Lançamento e Plano de Rollout. Se a sua empresa trabalha com Press Releases públicos, esse é o momento onde eles normalmente são finalizados. Se trabalha com vendas consultiva, é aqui que o discurso de vendas é atualizado também.
Lançamento
Definição: Com o produto pronto e devidamente testado esse é o momento de oficialmente lançar a novidade no mercado. Se tudo tiver sido feito da forma correta nas etapas anteriores o esforço desta fase é basicamente apertar um botão e ver a mágica acontecer. A medida que a empresa cresce, a tendência é que essa fase fique cada vez mais complexa, dados os impactos que esses lançamentos tem e até mesmo a agenda para fazer isso acontecer, já que provavelmente existem muitos times de produto lançando várias coisas simultaneamente. Se esse for o seu cenário, é fundamental entender o nível de “barulho” que você quer fazer sobre cada lançamento, para não estressar os canais de comunicação e fazer os seus clientes prestarem atenção no que realmente importa.
Alocação: Se houver uma pessoa de Product Marketing no seu time, é normalmente algum PMM que irá liderar essa fase, com uma grande participação do PM. Caso contrário essa responsabilidade fica com o/a Product Manager. Em ambos os casos tanto Engenharia quanto Design também são muito envolvidos.
Entregáveis: O principal entregável desta fase é um relatório do Lançamento em sim, falando sobre o que deu certo, o que deu errado, quantos clientes foram impactados, publicações na imprensa (se for aplicável), métricas de produto e etc.
Monitoramento
Definição: Nessa última fase o objetivo é, antes de considerar que o produto foi entregue e de fato partir para o próximo desafio, monitorar as métricas e principalmente os critérios de sucesso que foram definidos para este novo produto. Aqui sempre vale reforçar que nós fazemos produto para alcançar determinado objetivo (outcome) e não simplesmente para entregar o produto em si (output). Então este é o momento de verificar se o outcome desejado realmente foi alcançado e, em caso negativo, entender o que precisa ser feito para melhorar o resultado. Outros indicadores mais ligados a operação do produto em si (engenharia, performance, suporte, etc) também precisam ser monitorados nesse momento.
Alocação: Normalmente quem vai liderar essa fase é o Product Manager, com acompanhamento próximo principalmente de Engenharia, mas eventualmente Design também. Se no time houver um Data Analyst, Business Analyst ou algo nesse sentido, pode ser que essa pessoa lidere essa fase.
Entregáveis: O mais comum é que essa fase tenha um Dashboard para acompanhamento das principais métricas e um relatório/apresentação sobre os resultados alcançados e eventuais recomendações de alterações que precisam ser feitas no futuro, com a sua devida priorização.
Alocação do tempo de cada Product Manager
Olhando para esse framework que acabei de apresentar, uma coisa que acredito que vale a pena reforçar é sobre como distribuir o tempo do time de Product Management durante todas estas etapas. O que vejo acontecendo na grande maioria das empresas é o que o PM gasta muito mais do seu tempo em Delivery, mais especificamente na etapa de Desenvolvimento. Na minha visão isso é um erro. A principal função de um PM é entender o contexto em que o seu produto está inserido (clientes, usuários, objetivos da empresa, mercado, concorrência, etc) e priorizar o que for mais relevante neste contexto. Esse trabalho é essencialmente o que é feito na etapa de Discovery, dessa forma o que eu espero em termos de alocação do time de PMs é algo próximo disso:
Uma observação que acredito que vale deixar aqui é que essa quebra em seis fases é muito pensada na didática de como explicar o framework e no acompanhamento que será feito de tudo que está acontecendo com o seu produto. Na prática, no dia-a-dia do time, essas fases se confundem bastante, especialmente a de desenvolvimento, beta e lançamento, já que idealmente elas são bem fluidas e conectadas uma na outra. Se você quiser se aprofundar mais nesse tema eu recomendo escutar os episódios do Product Backstage com o Sérgio Schuler, sobre Product Discovery, e com o Rafael Dahis, sobre Product Development.
Para finalizar, como sempre gosto de reforçar, esse framework é um processo vivo, ou seja, hoje eu utilizo ele com essas etapas e dessa forma, mas amanhã eu possivelmente vou aprender algo diferente e, naturalmente, o processo em si vai evoluindo também. O mesmo deve acontecer com a sua empresa, dado as diferentes realidades que temos. Mesmo entre RD e Nubank o processo que eu utilizo já sofreu algumas alterações, por exemplo.
Idealmente esse framework deveria ser difundido não só entre o time de Product Management, mas entre todo o time de Produto e Engenharia, pois ele envolve todas as pessoas que fazem parte desse time. Com o tempo, esse framework inicial que eu estou sugerindo aqui pode ser estendido e servir de embrião para um Playbook de Product Management dentro da sua organização. Foi algo que fizemos na RD e que pretendo fazer aqui no Nubank também, vou dividindo mais materiais nesse sentido no futuro.
