Once you have the product foundations, you need devs who engage with the 'why', actively - Jean-Michel Lemieux

Fotografia de capa por Matteo Vistocco, tirada por uma Canon, EOS 6D

Na minha humilde opinião, o melhor tipo de desenvolvedor são os problem solver/product-minded engineer, que nada mais é que um dev que se preocupa com o problema que tá resolvendo ao invés de só a beleza do código. Esse perfil consegue ver além de cuspir software e focar no problema pra construir um produto, seja ele codificando ou não (escrevi sobre isso inclusive em um artigo anterior).

Se aprofundar em mentalidade de produto é crucial pra alcançar esse oásis de pensamento, e dentro de produto, quero trazer pra vocês um pouco sobre estratégia.

Estratégia de produto é o fator chave quando se fala em criar produto porquê é quando respondemos:

Qual problema queremos resolver?

E parece ser uma pergunta fácil de responder, mas é muito fácil se perder e criar algo que não gera valor algum, por isso pra conseguirmos ter uma resposta adequada precisamos ter três pontos em mente: foco, insights e ação.

Foco

Se você já passou por uma cadeira de gestão em tech, você provavelmente você já ouviu:

Precisamos contratar mais devs! O time atual não tá conseguindo tocar as iniciativas!

Será que realmente é falta de dev ou é falta de foco?

Assim como no início da nossa carreira escutamos do programador sênior do time que não é pra refatorar todo código ruim que encontramos pois se não vira um fluxo inacabável de trabalho, essa ingenuidade de falta de foco também acontece dentro da diretoria, e é onde se gera burnout e infelicidade da equipe com a empresa pelo estresse gerado de jogar fora o trabalho que nem foi terminado.

Stakeholder-driven roadmap é o nome que dão a conhecida prática de dividir o time de engenharia entre os stakeholders para ver quais features eles acham que devem atacar, ao invés de o usuário ser o centro de onde vem as ideias e de onde por o esforço do time. É muito fácil gerar trabalho no modelo stakeholder-driven, mas não resultado.

Defina poucos problemas para atacar mas foque em resolve-los muito bem, e para isso existem várias formas de ter insights para enfim tomarmos uma ação para solucionar.

Insights

Após ter definido o que se quer focar, chegou a hora de pensar em possíveis formas de resolver o problema, as ideias pra isso vem de insights que temos no dia a dia do produto.

Insights podem vir de vários lugares e aparecer a qualquer hora, o lugar mais clichê e mais conhecido que podem surgir é dos dados de uso do usuário.

Sabe aquele PO/PM, que sempre pergunta se foi colocado tal evento do analytics em parte da aplicação? esses dados além de poderem ser usados para aparecer em um dashboard bonitinho e colorido, servem tanto para nortear a empresa do que atacar no produto atual ou mesmo ter uma ideia de um novo produto.

Um exemplo bem comum e mais presente no cotidiano do desenvolvedor é os tech insights; OpenAI apareceu do nada com uma tecnologia fantástica que nos faz pensar em como podemos melhorar nosso produto com inteligência artificial sem nenhum conhecimento técnico sobre o assunto. Imagina poder diminuir mão de obra da operação com algumas chamadas a API? Ou então aumentar o potencial criativo de um publicitário pra ampliar o seu alcance?

Ação

Após ter um foco e analisar os dados para saber como atacamos ele, vamos definir ações para alcançar esses objetivos, vamos definir um roadmap.

Eu divido o roadmap em 2 estilos:

  1. Output-based roadmap: pra mim o pior tipo, pois aqui a gente cria uma jornada onde a quantidade de tarefas entregues conta mais que o resultado que elas geram e os "achismos" são o centro de tudo (um exemplo é o stakeholder-driven roadmap que eu disse acima).
  2. Outcome-based roadmap: é o qual eu acredito ser o ideial, pois agora definimos as tarefas baseado no resultado que elas geram e o usuário fica no centro de tudo

Existe muito mais a se explorar dentro do assunto estratégia de produtos, como metodologias que podem te ajudar como o OKR que é bem conhecido e bem usado.

A proposta é fazer você perceber que se você possui a habilidade de programar, a capacidade de criar uma ferramenta com potencial para melhorar a vida de muitas pessoas, então por que não aprimorar essa habilidade e direcionar seus esforços para gerar um valor ainda maior?

Quer ser um dev fora da curva? aprenda sobre produto.

Read next...