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?

Após trabalhar como uma Business Analyst na área de Growth em start-ups de tecnologia, resolvi fazer um shift em minha carreira profissional para a área de Digital Product Management por duas grandes razões: queria entrar ainda mais de cabeça no mundo da tecnologia e queria ter impacto direto na experiência do usuário por meio do produto.

E, como produteira de primeira viagem, ao iniciar o meu primeiro desafio eu imaginava que iria me deparar com algo mais ou menos assim:

• 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.

Sabe de nada, inocente!

A realidade foi bastante diferente e, à primeira vista, parecia cruel pra mim. Vou te explicar por quê.

Assumi o papel de pessoa de Produto de um time que havia acabado de entregar uma aplicação mobile a um grande varejista do mercado europeu e que estava em piloto para um número reduzido de usuários. Validava-se a proposta de valor em comparação com outras soluções de mercado e a eficiência do fluxo desenhado sob a perspectiva da experiência do usuário e da arquitetura e infraestrutura desenvolvidas.

Mas aí vem o que, pra mim, foi a cereja do bolo e o assunto que quero trazer como foco do post: o time agora havia se voltado somente ao back-end da aplicação, tratando também de algumas novas funcionalidades que suportariam a experiência do usuário, mas mirando principalmente em integrações com os sistemas da empresa e aperfeiçoamento do código e infraestrutura já existentes, visando a escalabilidade do produto.

Aquela frase que fazia sucesso há um tempo e que você talvez postasse no feed do seu Facebook ‘inspira, respira e não pira’ nunca fez tanto sentido para mim (rs)!

Eu não tenho um background de engenharia da computação e estava começando a trabalhar com Produto. O máximo que me aproximei do tema foi usar SQL pra trabalhar com manipulação de dados (pois é… veja bem rs). Portanto, palavras que eu ouvia a todo segundo nos ritos do time como API, request, response, status code, payload, endpoint, autenticação (e tantas outras) significavam ainda muito pouco pra mim.

Além disso, meu ‘usuário direto’ agora era os times de desenvolvimento, fossem aqueles responsáveis pelo aplicativo (que neste caso eram também integralmente responsáveis pela experiência do usuário do produto) ou aqueles que eram responsáveis por outros sistemas internos da empresa dos quais nós dependeríamos.

Acho que já deu pra perceber que, dado o contexto, eu precisei me virar nos 30.

Hoje, quando olho pra trás, percebo que foi uma ótima forma de praticar a soft skill de adaptabilidade e de aplicar uma das principais características de uma pessoa de Produto: o exercício do porquê. E é disso que quero falar agora!

Aqui vão algumas dicas que me ajudaram a dar o pontapé inicial:

(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?

É importante lembrar que além de você entender o objetivo do time e como ele entrega valor, todos do time também precisam ter a mesma visibilidade. E você deve atuar como vetor dessa mensagem constantemente!

Torna-se muito fácil que o time se sinta distante do usuário final e dos resultados que o produto com que ele trabalha traz para o negócio. Por isso, é essencial estabelecer uma visão clara de produto e demonstrar para o time como as entregas estão habilitando as entregas de outros times e, portanto, impactando diretamente o negócio, produto(s) customer-facing e usuários finais.

(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.

E, para o contexto desse post, foi neste momento em que eu deixei claro que não era uma pessoa de Produto com background técnico e como eu acreditava que mais poderia contribuir com o time e com o produto naquele momento. Isso foi importante para realmente setar as expectativas que o pessoal tinha de mim e como íamos caminhar em conjunto pra atingir nosso objetivo dali pra frente.

Também aproveitei pra pedir paciência! E você vai entender o motivo já já.

(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

No contexto do meu time, o que mais me faltou foi ter um conhecimento mais profundo em torno da vertente Tecnologia. Mas não me entenda errado! A ideia aqui não foi botar o pé em uma carreira de desenvolvimento de software, mas sim adquirir conhecimentos básicos para utilizar tais habilidades técnicas para tomar decisões, entender trade-offs e captar oportunidades de negócio em potencial como pessoa de Produto.

Portanto, estudei a introdução (bem básica) a alguns assuntos: conceito de algoritmo, linguagens de programação mais comuns e principais usos, ferramentas de versionamento, contexto de banco de dados, arquitetura de microsserviços, qualidade e tipos de teste, controle de logs, integração entre sistemas, API REST, cloud computing, DevOps, automatização e processo de deploy.

(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).

É super válido mencionar que seu time pode não ter o papel de um tech lead, mas isso se aplica a uma pessoa desenvolvedora ou a todo o time dependendo de como for a sua realidade :)

(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.

Vamos ao exemplo de uma integração de alguns dos microsserviços do back-end da aplicação com um sistema da empresa em detrimento a usarmos um banco de dados próprio. O que é preciso fazer:

• 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.

Pronto! Agora é uma questão de apresentar isso pro time (junto a toda a documentação necessária), quebrar em entregas menores se necessário e a magia vai acontecer.

(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.

E envolva a pessoa que assume o papel de tech lead e/ou de arquiteta(o), sempre que possível. Vocês atuarão como a voz daquilo que é viável tecnicamente olhando pela perspectiva do back-end, também influenciando nas decisões que são tomadas nesses fóruns.

Assim, você tem em mãos aquilo que é necessário para trazer contexto ao time afim de que ele decida a melhor maneira de desenvolver aquela nova funcionalidade sob a perspectiva do back-end e para que saibam o que vão alcançar ao entregar aquilo!

(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’.

Isso torna mais fácil que o objetivo seja apenas codar aquilo que os outros times estão pedindo (vai um pastel aí? rs), de forma que as pessoas desenvolvedoras percam a noção do valor que estão gerando aos usuários finais.

Por isso, o papel da pessoa de Produto se mostra tão relevante. É preciso realizar a abstração desses conceitos de modo que fique claro qual dor estamos tratando e visando atingir qual objetivo.

Mesmo que seu time não seja inteiramente dono de determinada métrica do produto customer-facing, nunca deixe de conectar a sua entrega à métrica que vai sofrer o impacto da entrega total daquela funcionalidade.

Além disso, apesar de ser um grande desafio, é preciso fazer uma conexão entre essa camada de software ‘inferior’ que está sendo desenvolvida com a estratégia e objetivos do negócio (OKRs da empresa, por exemplo) para que seja visível o valor que está sendo entregue para além do viés de engenharia.

E… chegamos ao fim das dicas!

Respondendo a pergunta lá do início do post: sim! Eu diria que essa história de PO ‘não-técnica’ e um time voltado ao back-end terminou bem. O desafio foi grande, mas a recompensa foi alta.

Você passou ou está passando por alguma situação parecida? Conta aqui nos comentários! Bora bater um papo :)

Ah, se você quiser trabalhar com um time de Produto sensacional é só dar uma olhada aqui e se candidatar pra uma de nossas vagas se estivermos com alguma posição em aberto. Vamos aprender juntos e até a próxima!

LinkedIn: @tavaresmfe