Generalistas ou especialistas em seu time de produto?

Publicado por Bruno Ghisi no dia gestão

Uma das perguntas que mais ouço é “se – e quando – devo contratar generalistas ou especialistas”.

Hoje na Resultados Digitais somos 42 RDoers na área de produto, separados em 7 times auto suficientes. Estamos separados em time de problema (investigação) e solução (desenvolvimento), além de algumas outras especializações, como suporte e operação. Temos vários papéis entre estes times: desenvolvedores (front e backend), UX designers, DevOps, QAs, POs, suporte. Entretanto nem sempre foi assim.

O que um profissional de produto precisa saber

Procuramos pessoas com pensamento sistêmico, multidisciplinares, que consigam entregar valor para os nossos clientes e tomar decisões complexas em vários níveis. Elas devem ser full stack na vida. Por isso:

  • Nossos desenvolvedores opinam em usabilidade.
  • Nossos designers sabem codificar.
  • Nossos DevOps priorizam funcionalidades de negócio.
  • Nosso suporte discute performance.
  • Nossos POs abrem pull requests para criar um post neste blog.

Todo bom profissional precisa ter uma base de conhecimento e a visão do processo como um todo. Qualquer membro de time de produto precisa estar familiarizado com alguns conhecimentos, como:

  1. Análise e estatística: Entender o que está acontecendo ao analisar dados de operação, produto, usuários, suporte, mercado e desempenho do time; como irá resolver o problema de maneira escalável, provar seu ROI, avaliar benchmarkings e ter clareza de decisões baseado em dados. Por exemplo, um designer precisa entender estatística para discutir a relevância do seu protótipo.
  2. Design e clientes: Entender como funciona o processo de design, como é o perfil das pessoas que trabalham com isso, como seus clientes se comportam, a importância disto para conseguir evoluir processos e a experiência no produto. Por exemplo, um DevOps precisa entender de design para saber a importância na retenção dos clientes.
  3. Desenvolvimento e tecnologia: Entender como as coisas são feitas, as complexidades envolvidas, custos, motivações dos desenvolvedores, processos ágeis para permitir uma melhor integração entre os times e soluções realistas. Por exemplo, um PO precisa saber sobre desenvolvimento, mesmo que em nível básico, para não gerar expectativas sem sentido nos clientes.
  4. Business: Entender do negócio que está trabalhando, ou melhor ainda: ser um usuário. Assim é possível tomar decisões assertivas e contribuir efetivamente com o produto. Por exemplo, um desenvolvedor precisa entender de business para tomar decisões conscientes de exceções que não foram mapeadas.
  5. Comunicação: Quem não escreve bem não consegue expressar com clareza suas ideias. É preciso saber se comunicar para mostrar resultados, atrair novas pessoas, planejar, discutir, realizar vendas, bizdev e ter uma boa relação com seu time. Por exemplo, um QA precisa se comunicar bem para alinhar problemas entre os times e como algo deveria funcionar.

É necessário entregar o resultado como time. Isto impacta em planejar, validar, projetar e executar. O processo é uma forma de ajudar a atingir nosso principal objetivo: clientes felizes. Por isso, no final do dia, todos são responsáveis pela entrega e seus resultados, e não pelo o que uma pessoa fez individualmente.

Generalista X Especialista

Nunca acreditei em rótulos. A maior parte das pessoas foca em esteriótipos ao invés de focar em habilidades e na capacidade de aprendizado de alguém. Principalmente, subestima a capacidade de um time com um propósito claro (objetivo de negócio).

Acredito que um profissional deve sempre fazer além da sua “responsabilidade” e buscar aprendizado. Efetivamente entender o problema de negócio para conseguir tomar decisões e entender como funciona o trabalho do colega para ser parte responsável da entrega.

Me incomoda muito o fato de pessoas transferirem a responsabilidade para outros, porque não é do seu conhecimento. Com esta postura, não buscam aprendizado contínuo (e mais entendimento), e justificam que não precisam daquilo ou que entregaram a sua parte.

Independente desta visão maior, seja muito bom em algo, no seu core. Ser especialista não significa que você é um pato em qualquer outro assunto, mas que você se aprofundou em algo. As pessoas tendem a achar que ser especialista é ser um Charles Chaplin em “Tempos Modernos”.

A especialização leva a outro nível de entendimento. Problemas complexos são resolvidos com soluções difíceis, às vezes só alcançadas por alguém – ou time – com o foco necessário. A produtividade, seja no nível de processos ou pessoas, muitas vezes também só é alcançada com tal nível de especialização.

A necessidade da empresa ao longo dos anos

No início da startup ela tem poucos recursos, por isso, um time reduzido. Os problemas também, provavelmente, não atingiram um nível de complexidade que precisam de especialização, bem como seus processos são mais simples. Independente disto, obviamente, é sempre necessário resultado (e rápido).

Neste caso, você precisa encontrar pessoas que consigam resolver o todo e entregar rápido. Normalmente o mais generalistas possíveis. Por exemplo, designers que estudem o problema, conversem com clientes, prototipem, codifiquem e ainda façam a arte para divulgação. Ou seja, que juntem UX, front e gráfico. No caso dos desenvolvedores, que modelem o sistema, codifiquem, cuidem da operação e façam suporte técnico.

Ao longo do crescimento você sentirá a necessidade de especializar alguns papéis, seja devido a complexidade do problema que está sendo resolvido ou ao processo. Por exemplo, criar um time para determinada funcionalidade do seu produto, ou ter uma pessoa responsável por alguma área crítica afim de trazer know how. No entanto, não contrate especialistas que não entendem a dinâmica de um time de produto e não tenham o conhecimento geral.

As pessoas precisam ter foco e confiar umas nas outras para executarem um processo de maneira mais otimizada. Se todos fizerem tudo, perde-se o foco. Por outro lado, se cada um fizer a sua parte e não perder a noção do que acontece do outro lado, temos um processo otimizado e um trabalho em equipe.

Bruno Ghisi

Bruno Ghisi

CTO

Comentários