Maria Fernanda Tavares

Jun 8, 2021

8 min read

Uma PO ‘não-técnica’ e um time dedicado ao back-end de uma aplicação mobile

Será que essa história termina bem?

  • um produto customer-facing;
  • um time formado por pelo menos 1 designer, 1 pessoa desenvolvedora front-end, 1 back-end e 1 agilista;
  • uma estratégia de produto clara para conversar com o roadmap e o backlog;
  • um objetivo claro a ser atingido pelo time em um espaço de tempo pré-determinado (por exemplo “aumentar em 20% a conversão de determinada etapa do fluxo em Q3”);
  • existência de uma estrutura de dados e ferramentas à disposição para manipulá-los.

(1) Entenda qual o objetivo do time e como ele entrega valor

É válido se perguntar:

  • Qual é o produto com que o time trabalha?
  • Qual a visão desse produto?
  • Quem é o ‘usuário direto’ desse produto? Ou quem são?
  • Que resultado espera-se gerar com esse time? Em quanto tempo?

(2) Alinhe expectativas com cada membro do time

Uma das primeiras coisas que gosto de fazer quando entro em um time novo ou passo a trabalhar com pessoas novas é conhecê-las. Em 1:1, costumo seguir essa ‘receitinha’:

  • falo um pouco de mim como pessoa: de onde vim, quantos anos tenho, que faculdade fiz e porque escolhi essa carreira, hobbies, família, pets, etc (já vai quebrando gelo e fazendo uma amizade);
  • falo da minha trajetória profissional: que foi que eu fiz lá na faculdade, porque eu escolhi o mundo da tecnologia, porque eu escolhi Produto e porque estou no lugar em que estou atualmente;
  • peço que, se a pessoa se sentir confortável, faça o mesmo;
  • pergunto qual é o momento atual do time e o que ela tá esperando do meu papel ou como ela espera que trabalhemos juntos.

(3) Estude!

Como já a diz a tríade de Product Management, a pessoa de Produto é a intersecção entre UX, Tecnologia e Negócio.

Martin Eriksson

(4) Não tenha vergonha alguma de fazer perguntas

Lembra que eu te disse que pedi paciência pro pessoal do time quando alinhei expectativas? Foi por isso aqui!

Apesar de eu ter investido tempo em alguns estudos e até cursos, ainda era necessário linkar a teoria à prática, além de no dia a dia sempre surgirem novos assuntos com os quais a gente ainda não entrou em contato. Então, sempre que necessário, eu fazia perguntas (mesmo que fossem triviais às pessoas desenvolvedoras) pra que eu conseguisse me manter por dentro dos problemas que os outros times estavam apresentando, pudesse começar gradualmente a drivar um processo de discovery, assim como entender impedimentos com os quais poderíamos nos deparar.

(5) Desenvolva uma forte relação com a pessoa que assume o papel de tech lead.

Para que você consiga definir problemas, levantar hipóteses de solução e realizar experimentos, dado que estamos tratando de dores técnicas, o seu peer principal se torna a pessoa que assume o papel de tech lead do time. Tão migos quanto a dupla dinâmica product manager e product designer! E aí já vem o gancho pra dica (6).

(6) Não se esqueça qual é o seu papel!

Ainda que o time fosse essencialmente voltado a desenvolvimento de APIs, integração entre serviços e infraestrutura, meu objetivo não era entender os pormenores do funcionamento do código e muito menos de definir como algo seria feito. Estou falando o óbvio, eu sei, mas isso realmente pode gerar confusão quando você está em um time com essa configuração.

  • entender a solução atual;
  • definir o problema, ou seja, por que a solução atual não atende mais as necessidades da aplicação;
  • entender como a integração com o novo sistema interno da empresa trará ganhos para o produto pensando no objetivo que temos a atingir como time;
  • definir quais métricas, juntamente a(o) tech lead, poderemos acompanhar para medir esses ganhos.

(7) Envolva-se nos fóruns de discussão de experiência do usuário.

Faça questão, por meio de uma boa gestão de stakeholders, de arranjar um espaço nas discussões relacionadas aos produtos customer-facing que dependem das entregas do time tais como as de estratégia, roadmapping, processos de product discovery e priorizações de novas funcionalidades sempre que isso for de encontro com o objetivo que o seu time pretende atingir.

(8) Exercite ainda mais veementemente o porquê por trás de cada estória desenvolvida.

É muito comum que, pela natureza do produto com o qual o time trabalha, as dores sejam também muito técnicas. Soma-se a isso o fato de que, dada a maneira como os times de desenvolvimento estavam configurados, era muito comum que o time do qual eu fazia parte não fosse envolvido em algumas discussões em torno de novas funcionalidades. Como consequência dessas somas de fatores, chegavam muitos pedidos específicos como ‘criem o endpoint tal’ ou ‘passem a retornar tal status code na request XPTO’.

Nós desenvolvemos produtos digitais com inovação, agilidade e excelentes práticas, para que o mercado brasileiro e latino-americano acompanhe a velocidade do mercado digital mundial.