1 ano como Product Owner

Atualmente vivemos a chamada era do conhecimento onde a transformação digital está revolucionando o mundo em vários aspectos, desde como assistimos filmes, até como nos movemos pela cidade. Você ainda assiste tv?

O mercado de trabalho sem dúvidas é um dos setores que está se transformado assustadoramente rápido e isso obriga profissionais, principalmente de Tecnologia da Informação, a se reinventarem todos os dias para manter-se sempre atualizado e não ser atropelado pela evolução.

Desde novembro de 2016 minha carreira deu uma virada, passei de Analista de Sistemas para Product Owner. Neste artigo vou relatar de como foi essa mudança e todos os desafios que enfrentei até agora em 2018.

Antes de ser Product Owner

Antes de falar sobre as experiências como Product Owner, vou descrever rapidamente como era minha atuação como analista de sistemas.

Em 2013 após fracassar em um negócio próprio de marketing digital, fui contratado para trabalhar como Analista de Sistemas na Softplan. Meu trabalho era ser a “ponte” entre o time de desenvolvimento e o cliente.

Oficialmente a empresa rodava o framework scrum, então, os desenvolvedores me chamavam de PO, mas, não fazia a mínima ideia do que era isso.

Tínhamos um processo muito bem definido, que era assim:

1. O cliente pedia alguma coisa;
2. Eu ligava para ele e entendia o que ele queria;
3. Fazia uma proposta técnica super detalhada com custo e prazo e enviava para o cliente;
4. Se ele aceitasse, passava para um Analista de Requisitos especificar;
5. Fazíamos uma reunião de verificação da Especificação (na prática, os analistas apresentavam a especificação para os desenvolvedores e os mesmos criticavam);
6. Codificação;
7. Teste;
8. Entrega para o cliente.

Se você conhece um pouco sobre desenvolvimento de software, percebeu que não éramos nada ágeis, mas, sim uma grande cascata dentro do scrum. Esse processo levava meses!

Na prática eu era um tirador de pedidos, o cliente pedia, eu entendia e colocava pra fazer. O processo era totalmente reativo e não existia evolução de produto.

Meu mindset era: tenho que fazer o meu. Ou seja, mandar propostas para os clientes. (tenho vergonha dessa frase).

Virei Product Owner

Minha cabeça começou a virar quando fiz uma entrevista em uma startup para ser Product Owner, obviamente fui mal no processo, mas, caí na real e vi que estava muito longe de ser um PO.

Neste momento também percebi que Analistas de Sistemas estavam em extinção e se eu quisesse evoluir na carreira, teria que me reinventar. A partir deste evento, comecei a correr muito atrás de aprendizado. Participei de eventos, conversei com POs de outras empresas, li livros, ouvi podcasts, etc.

Em 2016 a empresa passou por uma transformação ágil, onde a principal mudança foi quebrar em times menores e criar a função de PO oficialmente.

Quando soube que isso aconteceria, decidi que eu seria um dos POs, imediatamente comecei a correr atrás e deixei claro meu objetivo para a diretoria e gerência. Bem, deu certo, fui entrevistado e escolhido para ser PO.

Legal! E agora?

Bem, quando virei PO o que eu mais ouvia na empresa era frases assim:

• “isso o PO vai resolver…”,
• “isso temos que envolver o PO…”,
• “esse problema tem que falar com o PO…”,
• “agora você é o PO, então…”,
• “o PO deve sempre…”, etc.

Fiquei meio assustado com isso na época, mas, confesso que agora até gosto.

O que mudou de fato?

Tudo! Lembra que eu só enviava propostas? Bem, agora eu sou responsável pelo o sucesso e o fracasso de alguns produtos.

Isso engloba convencer todas as áreas da empresa das minhas decisões. Passei a trabalhar muito perto do Marketing e Comercial, antes eu mal sabia quem eram as pessoas dessas áreas.

Constantemente tenho interações com time de suporte sobre priorização de chamados, com o time de pós-vendas para ver como está a venda do produto que lançamos, com o time de marketing para gerar conteúdo para nossos clientes e ver como vender mais.

Muitas interações com o Time de desenvolvimento. Aprendi que não tenho que criar listas de coisas para fazer, tenho que convencer e motivar o time para seguir no caminho que estou propondo.

Só um exemplo: Quando vamos evoluir um produto, não digo que temos que fazer tais funcionalidades… digo que nosso cliente vai gerenciar melhor a empresa dele com nossa solução e nós podemos ganhar dinheiro com isso.

Além disso, busco mostrar que devemos fazer algo sob 3 perspectivas:

• Do cliente: o que vamos resolver pra ele (não é emitir um relatório mais rápido. Mas, olhar para uma solução nossa e ver que a empresa está indo bem ou mal).
• Da empresa: retorno financeiro no curto e longo prazo.
• Do time: tecnologia! Tento sempre mostrar pra eles que podemos fazer algo novo e eles poderão aplicar as melhores práticas de engenharia de software que preferirem.

Data driven na veia

Sempre gostei de coisas concretas, por exemplo: ligar o ponto A com o ponto B, alcançar X% de alguma coisa. Estou aprendendo a cada dia tomar decisões embasada em dados. Mesmo se eu tiver errado, pelo menos tenho como justificar minha decisão.

Quando virei PO e de vários sistemas, a primeira dúvida foi “por onde começar?” para tomar a decisão, plotei o gráfico abaixo que mostra o posicionamento de cada sistema em relação a quantidade de atendimentos abertos no suporte e a quantidade de clientes.

Esse gráfico clareou minha mente, ele mostra que o sistema 1 e sistema 2 são estáveis, porque tem muitos clientes e poucos erros, enquanto que o sistema 4 tem muitos erros e poucos clientes. Na prática o sistema 4 tomava mais de 60% de nosso tempo.

O interessante aqui é que o gráfico matou nosso feeling, tínhamos o total sentimento que os sistemas 1 e 2 eram mais complicados.

Com esse gráfico consegui convencer parceiros, suporte, diretoria e meu time que valia a pena investir no sistema 4 por 2 motivos: reduzir a quantidade de erros e aumentar as vendas do sistema.

Este gráfico embora simples, me deu muita segurança para definir o que faríamos em todo o ano de 2017.

Existem outros exemplos que tomei decisão baseadas em dados, como:

• Descontinuar uma funcionalidade;
• Entender o uso de um sistema que vamos evoluir em 2018.

Posso detalhar em outro momento.

Motivação do time

Em um momento do ano percebi que o time estava meio desmotivado, havíamos perdido um pouco da gana por fazer as coisas, não estávamos indo muito bem. Então, resolvi fazer uma apresentação para mostrar o roadmap do produto para relembrar a todos o porquê das nossas demandas.

A apresentação era cheia de tabelas e demonstrações financeiras, mostrei para o nosso diretor e ele disse, “Cara, isso está cold demais!”. Fiquei sem saber o que pensar, mas, ele me disse que como PO eu tenho que convencer as pessoas, como se fosse o Flautista Encantado, daquela fábula da Disney que o flautista toca e os ratinhos vão seguindo ele. Na prática me sugeriu usar Storytelling

.

Bom, segui o conselho e mudei a apresentação, detalhe, a apresentação para o time era no dia seguinte.

Fiz uma história usando a jornada do herói, onde eu mesmo era o “herói”. Falei sobre os altos e baixos da minha carreira e mostrei meus objetivos pessoais e que para eu alcançá-los eles são fundamentais.

O resultado foi que consegui conectar eles com a história e no final estavam comigo.

Depois disso, o time mudou, o entrosamento aumentou, as cobranças internas aumentaram e eles se engajaram totalmente nos projetos.

Aprendi que um bom time é uma baita base para o PO.

Visão Sistêmica

Tive a real noção do que é isso quando tive que refazer o modelo de negócio do sistema sistema 4.

Na prática, eu queria mudar a forma de cobrança do sistema, que era por tarifação, ou seja, o cliente pagava alguns centavos por arquivo recebido no sistema 4. Minha proposta era transformar num SaaS e cobrar um valor fixo por mês.

Para encurtar a história, tive que pensar sob várias perspectivas:

• Parceiros: os parceiros antes não vendiam o sistema porque não ganhavam dinheiro, tinha que convencer eles que a nova proposta seria boa para eles.
• Pós-vendas: tive que prever comissão para pós-vendas, parece óbvio, mas, como eu nunca tinha feito isso antes, não imaginava que tinha que ser feito.
• Administrativo: como isso seria cobrado do cliente, outra nota fiscal? Mais um item na nota de manutenção?
• Jurídico: como deve ser o contrato com esse novo modelo?
• Marketing: como será a comunicação, apenas para clientes da base? Prospects também?… Tem que gerar conteúdo, quem gera? Quando o marketing pode fazer as coisas?
• Diretoria: o custo disso compensa? Você fez as contas?
• Suporte: uma campanha de marketing pode gerar ligações no suporte e aumentar o transbordo deles.

Enfim, tive que falar com todas essas pessoas e sincronizar tudo ao mesmo tempo. Consegui!

Mindset Financeiro

Demorou para eu entender, mais, percebi que sou responsável por tudo relacionado ao produto e obviamente o financeiro faz parte.

Estou a cada dia buscando entender o impacto financeiro das decisões.

Tenho comigo a seguinte lógica: A empresa existe por causa do Produto. Parceiros vendem nosso produto, marketing gera leads qualificados para consumir nosso produto, suporte tira dúvidas do cliente sobre o nosso produto, o dono da empresa ganha dinheiro com o nosso produto, o PLR é sobre as vendas do nosso produto, o setor de desenvolvimento faz o produto.

Logo, em minha cabeça, todas as áreas são despesas para manter do produto. Entendo que o produto paga o custo de todas as áreas.

Montei um fluxo de caixa imaginando o seguinte cenário (não vou detalhar valores):

Despesas, na tabela abaixo considerei todas as áreas da UNIC, o grande desafio aqui é entender como fazer o rateio para chegar em um valor correto da despesa.

DESPESAS

• Pré-vendas
• Pós-vendas
• Suporte ao cliente
• EAD
• Customer Success
• Marketing
• Canais
• Faturamento/contratos
• Time de infraestrutura
• Data center
• Custo por posição de trabalho
• Custo do time

As receitas são um pouco mais fácil, mas, também desafiador. Em tese, basta pegar a quantidade de clientes por sistema e multiplicar pelos usuários e valor de manutenção, porém, existem variáveis que dificultam, como: permuta de sistema e descontos.

Receita total por sistema

• Receita do sistema 1.
• Receita do sistema 2.
• Receita do sistema 3.
• Receita do sistema 4.
• Receita do sistema 5.
• Desenvolvimentos para clientes sob demanda.

Minha ideia com esses valores corretos é entender a situação financeira do time. Somos viáveis financeiramente?

Um de meus objetivos é inserir esse mindset financeiro nas pessoas do meu time. Quero que isso também influencie nas decisões deles por exemplo: é economicamente viável gastar mais tempo para fazer a implementação perfeita?

Algumas vitórias como PO

Precificação do sistema 4

Além de ter sido o primeiro, pra mim foi o maior desafio porque foi diferente de tudo que eu já havia feito na minha vida profissional.

Quando assumi como PO, existiam 2 modelos de comercialização do sistema 4 que eram inviáveis.

1. Tarifação, o cliente pagava utilização, porém, o parceiro não vendia porque não ganhava dinheiro.
2. Licença de uso, essa prática tornava o sistema inviável, porque multiplica-se o valor de manutenção pela quantidade de usuários, logo, o sistema ficava com preços astronômicos e a concorrência oferece o mesmo serviço por uma fração do valor.

Então o desafio era fazer os clientes verem valor no sistema, os parceiros ter vontade de vender e chegar num preço justo de mercado.

Bem, comecei a pedir ajuda aos universitários, aliás, aos mestres no assunto (Ionan e Marcus Anselmo). Fui apresentado ao conceito de corredor de preço. Pesquisei concorrência, entendi nosso público-alvo e cheguei num posicionamento de preço do produto.

O gráfico abaixo mostra o corredor de preços que fiz.

Corredor de preço de massa

Depois disso montei um quadro e comparei nossas funcionalidades com a dos concorrentes e cheguei numa proposta.

O fato mais importante é que não adiantaria nada apenas rever o preço do produto sem fazer uma reformulação. O motivo é simples, nosso maior concorrente era um sistema muito melhor que o nosso e muito mais barato. Por isso investimos em reformular o sistema.

Projeto de UX no sistema 4

Depois que tomei a decisão de evoluir o sistema 4, em paralelo nasceu uma iniciativa de introduzir User Experience no noss ERP. Aproveitei a oportunidade e juntei essa iniciativa com a evolução do sistema 4.

Foi um ótimo projeto, totalmente co-criado entre eu, os desenvolvedores e 2 designers.

Vou resumir o projeto em tópicos:

• Fizemos levantamento de personas;
• Entendemos as dores dos clientes;
• Prototipamos;
• Validamos;
• Prototipamos denovo;
• Validamos;
• Prototipamos novamente;
• Validamos;
• Desenvolvemos;
• Entregamos.

Agi dando direção para o produto, tinha que ser tipo o Google, muito fácil de usar e o usuário ficar menor tempo possível usando. O resultado foi que conseguimos reduzir o sistema para uma única página e recebemos uma série de elogios tanto internamente quanto de clientes.

Relançamento do Sistema 4

Com o projeto de UX, eu juntamente com o Marketing, planejamos o relançamento do sistema, isso incluiu:

• Gerar conteúdo: escrevi 3 posts de blog para educar o cliente sobre a necessidade do sistema;
• Criamos uma landing page abordando dores e como poderíamos saná-las;
• Colocamos um protótipo clicável para o cliente experimentar.

Pecamos um pouco no acompanhamento do lançamento, mas, no fim das contas foi um sucesso, saímos de 141 clientes para 233 em 3 meses. Um aumento de 60%.

Outras vitórias e aprendizados

Ao longo do ano tive algumas pequenas vitórias, mas, importantes para mim. Vou apenas citá-las.

• Descontinuidade de uma funcionalidade: tínhamos uma feature problemática e queríamos descontinua-la, fiz todo um levantamento de clientes, trabalhei forte na comunicação e descontinuamos, você pode vê mais detalhes neste post.
• Projeto de SLA: participei de um grupo em conjunto com o Suporte para implantar SLA na empresa, neste grupo atuei bastante na elaboração dos critérios de criticidade e convencer as pessoas que o SLA é bom e não apenas uma cobrança de prazo. O projeto está rodando e tivemos sucesso no primeiro mês.
• Comunicação: evolui muito meu poder de comunicação, sempre exponho meus pontos, fiz vários vídeos para comunicar decisões de produto e tenho conseguido pensar friamente colocando minha opinião pessoal de lado quando outras ideias são melhores.
• Respeito: me sinto respeitado na empresa, já ouvi alguns feedbacks elogiando que penso pra frente, sou visionário, aceito outras ideias, sinto que as pessoas de outras áreas gostam de interagir comigo.
• Segurança: aprendi a dizer Sim ou Não e menos talvez e eu acho. Procuro sempre dizer Sim ou não mesmo que esteja errado. Entendo que isso passa segurança para as pessoas, ainda bem que acerto mais do que erro.

Próximos desafios

É óbvio que não sou o melhor PO do mundo e tenho ainda muito o que aprender, para o ano de 2018 quero focar nos seguintes pontos:

• API: aprofundar meu conhecimento em gestão de produtos com API.
• Custo de atraso: entender e aplicar o conceito de custo de atraso nas priorizações de produto.
• Growth hacking: gosto bastante de marketing, acredito que este conhecimento pode me ajudar a elevar as vendas de meus produtos.
• Job to be done: conheço este conceito a pouco tempo, estou estudando e pretendo aplicar já no projeto do gerencial financeiro.
• Itens do PDI.
• Outras coisas que vão aparecer durante o ano…

Conclusão

É fato que em 2017 evoluí profissionalmente uns 10 anos em 1. O trabalho como Product Owner me proporcionou enxergar cenários por completo, me aproximou das pessoas e me fez ter um propósito.

Hoje, não me vejo fazendo outra coisa que não seja trabalhar com produtos. Arrisquei bastante, dei a cara pra bater, ouvi bastante feedbacks e cresci com todos eles. Tenho total ciência que não sou expert em todos os pontos que mencionei neste artigo, mas, o fato é que faço as coisas acontecerem.