Meus 123 dias como Product Owner

Aprendi, trabalhei e me dediquei na tentativa de influenciar os fatores que me levassem até meus objetivos, evitando que o destino fosse obra do acaso. Mas quem disse que tudo está em nossas mãos? Se busca garantias ou certezas, talvez esse não seja o artigo certo para você.

Quando achei que minha vida profissional estava estavelmente traçada, uma soma de fatores fizeram com que eu tivesse a desafiadora oportunidade de me tornar Product Owner do portfólio de produtos Cloud.

Mas antes de começar o relato do que aprendi e pratiquei nos últimos 123 dias, cabe alinhar as responsabilidades do Product owner… Segundo o Scrum Guide, o PO é a pessoa responsável por maximizar o valor do produto, o trabalho do time de desenvolvimento e a gestão do backlog (fila de correções e melhorias) do produto.

No contexto que estou inserido a função de PO é mais abrangente, pegando emprestado algumas palavras de Joaquim Torres, publicada em seu livro “Gestão de Produtos”, na Locaweb o Product Owner também é um Gestor, responsável por todos os aspectos de um produto, durante todo seu ciclo de vida, desde a sua concepção até o final de sua vida.

Assim como o Joaquim, compartilho a visão de que estes papéis são dois lados de uma mesma moeda, pois não dá para priorizar backlog e maximizar as entregas sem um profundo conhecimento do produto, seus objetivos e usuários.

Ciente desta responsabilidade e na tentativa de estruturar uma linha de atuação e autoavaliação, depois de muito ler e buscar referências de amigos e profissionais da área, compilei um quadrante e o intitulei de POMI:

Panorama

Não é por acaso que este é o primeiro dos 4 pilares, é necessário entender o produto em suas diferentes camadas e contextos para conseguir desenvolver e priorizar as histórias que melhor atendam as necessidades do estágio que se encontra do seu ciclo de vida.

Dentre os diversos caminhos possíveis para compor minha visão optei por aprofundar meus conhecimentos sobre o produto, mercado e cliente. Mesmo já estando inserido no contexto do portfólio Cloud limpei o cachê dos meus conceitos e fiz uma busca a partir da atual estrutura e funcionamento da tecnologia. Na sequência mapeei os concorrentes e os novos entrantes. E, por fim, entendi as necessidades e interações que os usuários possuíam e vivenciavam.

Fiz de tudo para me jogar de cabeça nesta busca, pois todo este conhecimento serve de insumo, input e combustível para diferentes métodos de priorização. Até o momento tive o contato com a Matriz Rice (reach, impact, confidence, effort) e uma adaptação de uma técnica de cálculo de ROI x esforço de Paulo Caroli, muito bem explicitado em sua famosa obra “Direto ao Ponto”.

Operação

Pense em uma série de engrenagens, como aquela cena do filme Tempos Modernos, do Chaplin. Somente com total sinergia e conhecimento de suas rotações seria possível incluir um novo componente no sistema.

O produto também possui uma série de fluxos e áreas envolvidas para que se mantenha operante. Sem julgamento de valor, é importante que domine este mecanismo para poder atuar e estimular o melhor de cada integrante, tornando, dessa maneira, o produto cada vez mais rentável, desejável e de alta qualidade.

É possível organizar times, tribos, squads de diversas formas. Minha experiência até aqui me mostrou que a diplomacia e o sentimento de posse compartilhado são catalisadores para a busca da integração perfeita.

Voltando para os exemplos, na Locaweb é esperado que o Product Owner seja uma “bordadeira”, unindo diferentes retalhos para formar uma grande colcha. Em outras palavras, cabe ao PO ser e construir pontes entre áreas e pessoas para que os processos e informações fluam de forma otimizada.

Outra prática que sempre defendi e gerou ótimos resultados é o compartilhamento da responsabilidade, do chamado “ownership”. Mesmo o PO sendo a “voz” do produto, é essencial que o Marketing de Produtos, Engenharia, UX e Operações componham a definição e construção da visão, estratégia e evolução de portfólio. Somente desta maneira, diversa e multidisciplinar, os desafios serão endereçados e superados de forma eficiente, sem criar idéias fixas ou visões de mão única.

Metodologia

Este pilar é essencial, pois apenas mergulhando de cabeça no mundo Ágil conseguirá encontrar a melhor forma de interagir, colaborar, sustentar e potencializar as entregas junto ao time de desenvolvimento, um dos objetivos essenciais do Product Owner.

Exatamente por isso, meus primeiros passos foram dados no sentido de entender o Manifesto Ágil, que se trata de uma declaração de princípios que fundamentam o desenvolvimento ágil de software. Criado em fevereiro de 2001, por um grupo de 17 analistas de software, em Utah/EUA, com o objetivo de descobrir melhores maneiras de desenvolver software de forma colaborativa e acessível.

Com seus 4 valores e 12 princípios (que ainda não me sinto preparado para analisá-los aqui) o que mais me encantou no manifesto foi a coragem de desconstruir processos rígidos e planejamentos clássicos para abrir espaço para entrega de valor de forma flexível e colaborativa.

Com estes conceitos me senti melhor preparado para realmente entender as propostas do Kanban e Scrum. Isto porque, tais frameworks, muito mais que cerimônias, quadros e dailys, orientam a formação de um “modus operantes” e cultura de geração de valor.

Inovação

Não basta como PO, dominar a arte da priorização, as entranhas dos fluxos operacionais, nem toda a biblioteca de metodologia já criada. O real diferencial reside na alquimia destes pilares para compor e alimentar sua capacidade desconstrutiva, criativa e inovativa.

Imagine quão complexo é assumir que tão inevitável como a queda dos grandes impérios, os esforços e conceitos que te impulsionam até aqui, não serão os mesmos que sustentarão sua competitividade nos próximos anos. Então, como se valer das atuais perspectivas e dogmas para prever e entender como o cliente, mercado, empresa e tecnologia será em 2, 10 ou 20 anos?

Eita tópico desafiador! Não é a toa que, mesmo se autoavaliando com um belo “8” nos outros 3 pilares, se não abraçar a inovação continuará sendo um Product Owner mediano, tendo que se contentar com suado “6”.

Ainda estou arranhando a superfície e, em um futuro próximo, poderei compartilhar mais aprendizados, contudo, o que meus 123 dias como Product Owner já me mostraram:

• A importância de transformar certezas em hipóteses;
• A distinção dos componentes supérfluos dos fatores que realmente definem o valor do produto;
• Desenhar cenários com o intuito de praticar a capacidade de aprender e reagir, não com a presunção de prevê-los.

Ufa… Olhando para trás quanta coisa aconteceu nestes 123 dias, talvez o tempo não seja uma boa métrica quando lidamos com vertentes como intensidade e profundidade. Nos últimos dias brinquei frequentemente com o time que minha rotina era composta de 50% (de suor), 30% (de paixão), 5% (de de acaso) e 15% (do puro suco do desespero… rs).

Sei que muito ainda está por vir, e tenho MUITO à aprender como Product Owner, mas espero que este breve e preliminar relato ajude você (e me ajude) a entender melhor este novo mundo.

Por isso, fica registrado aqui meu pedido: compartilhe o que achou. Toda crítica e opinião, além de sempre bem-vindas, serão aceleradores na busca da divergência criativa frente a convergência cega.

Agradecimento:

Sei que essa prática é comumente usada em livros, mas não poderia deixar de agradecer ao Marcelo Vianna Doni e ao Paulo Lomanto, grandes amigos e referências de Product Owner e Coordenador Técnico, que muito me ensinaram/ensinam e colaboraram/colaboram para assumir a cadeira que ocupo hoje.

>> Cassio Scozzafave irá falar mais sobre o tema no Fórum Mestre GP, que acontece dia 21 de setembro, na Ancham SP. Saiba mais sobre o evento AQUI.