Gerenciando o roteiro do produto de código aberto

Um roteiro garante aos clientes que seu produto atenderá às suas necessidades, agora e no futuro.

Nas primeiras quatro partes desta série sobre a cadeia de fornecimento de software de código aberto, explorei o código aberto como uma cadeia de fornecimento, o que é um produto, o que os gerentes de produto fazem e maneiras de diferenciar produtos de software de código aberto de seus projetos upstream. Neste artigo, discutirei os elementos essenciais de um roteiro e como determiná-los.

Os clientes, assim como as equipes de vendas e marketing que conversam com eles, adoram um roteiro. Isso lhes dá uma noção do que é realista e do que não é. O roteiro também está no cerne de um produto. Manter um roteiro de produto atualizado mantém a equipe de produto focada no cliente e alinhada para entregar o que ele precisa. O roteiro comunica a direção estratégica de um produto e a perspectiva da empresa na solução de problemas.

Qual é a diferença entre o roteiro de um produto proprietário e um que é construído em uma cadeia de suprimentos de código aberto? Não muito. Os gerentes de produto conversam com os clientes, classificam suas necessidades, traçam um roteiro e, em seguida, descobrem como fornecer recursos por meio da construção, compra e parceria.

Pense no roteiro como o plano de voo do produto. O piloto pode ter que fazer alterações com base no clima, emergências de saúde ou problemas mecânicos, mas deve sempre começar com um plano de vôo, ou não poderá decolar. O mesmo acontece com os produtos.

Focando nos problemas do mercado

Uma das maiores tentações que os gerentes de produto enfrentam é perder a noção do panorama geral e focar no último problema que ouviram de um cliente. Fixar-se apenas no problema mais recente leva a mudanças perpétuas nos objetivos, o que desgastará as equipes de engenharia e os parceiros. A influência de um gerente de produto está enraizada na confiança, a confiança está enraizada no comportamento consistente e o comportamento consistente está enraizado na confiança.

A confiança começa com a identificação dos problemas do mercado. Quando um cliente lhe conta algo, pode ser um acaso. Quando 100 clientes lhe dizem algo, isso é um problema. Um único gerente de produto provavelmente não consegue obter feedback de 100 clientes, então ele precisa ter um sistema para obter informações de todos os lugares que puder: clientes, pessoal de vendas, outros gerentes de produto, comerciantes de produtos, usuários em conferências e fontes relacionadas.

Os clientes têm muitos tipos de problemas, mas um problema de mercado é um desafio urgente que seus clientes-alvo pagariam com prazer para resolver. É um problema que aumenta a probabilidade de as pessoas comprarem seu produto ou renovarem se for uma assinatura. Resolver problemas de mercado validados pelas necessidades do cliente impulsiona a criação do seu roteiro. Seu roteiro nunca deixará todos felizes, mas pode ajudar a alinhar estratégias entre seu produto e os clientes que o compram.

Gerenciamento por influência

Depois de identificar problemas realistas que seu produto pode resolver, você precisa descobrir como resolvê-los. Essas soluções são chamadas de recursos ou, em vendas, capacidades. Um bom gerente de produto percebe que os recursos vão muito além de coisas técnicas construídas por engenheiros. Os recursos podem ser absolutamente um trecho de código criado pela equipe de engenharia, mas também podem ser algo fornecido pela equipe jurídica, como indenização ou até mesmo orientação de instalação de uma equipe de serviços. Esses recursos orientam o roteiro do produto.

Então, como os gerentes de produto cumprem seu roteiro? Eles normalmente não escrevem código – e provavelmente não deveriam – e normalmente não controlam o orçamento nem assinam acordos com parceiros. Na verdade, eles não têm controle direto sobre ninguém: clientes, engenheiros, parceiros, jornalistas, analistas e, principalmente, sobre concorrentes. Em vez disso, eles precisam administrar por influência.

Quando a equipe de produto tem um conjunto de problemas de mercado que foram validados com os clientes, é muito mais fácil influenciar as pessoas necessárias para implementar um recurso. Isso é verdade quer o recurso seja entregue por um projeto upstream, por engenheiros downstream, por uma equipe de serviços ou pela equipe jurídica.

Construir influência é particularmente importante com fornecedores upstream de código aberto. Alguns gerentes de produto presumem que não podem controlar um projeto upstream, por isso acham que é mais fácil fork o projeto e alterar o que for necessário. Não bifurque: é caro, geralmente de qualidade inferior, mais difícil de manter e você perde todos os valiosos testes de usuário upstream. Assim como os fabricantes influenciam seus principais fornecedores upstream, os gerentes de produtos de código aberto também deveriam se envolver em projetos upstream, construir confiança e usar sua influência.

Clientes x concorrentes

Copiar o seu concorrente é sempre uma tentação. Ficar de olho nos concorrentes nunca é uma má ideia, mas não priorize isso acima das necessidades dos clientes. Em vez disso, direcione os problemas de negócios de seus clientes conversando diretamente com eles e determinando os recursos que procuram. Se você sabe que é mais rápido que seu concorrente, mas nenhum de vocês resolve o problema de negócios, o cliente não pagará a nenhum de vocês.

Dito isto, preste atenção ao marketing e às mensagens dos concorrentes aos potenciais clientes, porque isso pode afectar profundamente a forma como os clientes comunicam os seus problemas e os pedidos que fazem de funcionalidades. Às vezes, um concorrente pode convencer um cliente de que tem um problema que apenas um recurso que é um dos pontos fortes do concorrente pode resolver. Seguir o exemplo do seu concorrente não é a maneira de identificar um problema de mercado ou o melhor recurso para resolvê-lo. Use a atividade do concorrente como informação, mas não deixe que ela guie seu roteiro.

Comprometer-se e apresentar o roteiro

Um bom gerente de produto conhece bem seu produto e o adora. Eles também conhecem e amam seus clientes. Nada representa melhor isso do que ficar animado ao apresentar o roteiro. O roteiro é o resultado das conversas com o cliente de um gerente de produto e da influência que uma equipe de produto exerce em nome do cliente.

Um gerente de produto só pode se comprometer com um item do roadmap depois de ter feito todos os seguintes:

Identificado um problema de mercado
Validado com vários clientes e outras influências
Trabalhei com engenharia upstream, jurídico, QE, engenharia de desempenho e outros parceiros para determinar se eles podem resolver o problema
Determinado um prazo razoável para o vencimento

É isso. Isso é o que é necessário para construir um roteiro: necessidade do mercado e compromisso de entrega dentro de um prazo.

Lembre-se sempre de que seu produto é mais do que apenas seus fornecedores anteriores. Pense no código aberto como uma cadeia de suprimentos upstream, mas pense no seu produto como uma solução downstream contendo um superconjunto de recursos de solução de problemas. A soma do todo deve ser maior do que as partes individuais, e parte do seu trabalho é diferenciar essa soma de outras ofertas no mercado. O roteiro deve fornecer recursos e capacidades diferenciados, incluindo:

Capacidades específicas do produto – não recursos do fornecedor
Recursos que estão prontos para serem testados pelos clientes (em testes beta ou visualização técnica)
Recursos que estão prontos para uso dos clientes na produção (disponíveis e lançados em geral)

Um bom roteiro será usado por seus clientes, vendedores, profissionais de marketing e outros gerentes de produto. Além disso, se o seu produto se concentra em usuários técnicos, os desenvolvedores e arquitetos contam com um roteiro para integrar o seu produto aos produtos deles. Se o seu produto for uma plataforma ou serviço técnico (como baseado em Linux, Kubernetes, Java ou máquinas virtuais), você não estará apenas consumindo de uma cadeia de suprimentos upstream; você também faz parte da cadeia de suprimentos de produtos downstream criados por seus clientes. Isso torna um roteiro sólido ainda mais crítico.

Outras considerações

É provável que várias guerras santas possam ser iniciadas e travadas sobre problemas de mercado, recursos e quais ferramentas as equipes de produto devem usar. Por esse motivo, evitei especificamente qualquer menção a ferramentas. A parte importante a transmitir é que um roteiro deve ser focado no que os clientes precisam e desejam. É trabalho da equipe de produto fornecer recursos com base nessas necessidades. Como rastrear isso especificamente não é abordado neste artigo.

Outra nuance deixada de fora desta conversa é o roteiro do projeto upstream. Quem está encarregado disso? Os projetos upstream não são produtos e raramente há alguém responsável por um roteiro de longo prazo para projetos upstream. Com alguns dos megaprojetos como OpenStack, Kubernetes ou o kernel Linux, existem gerentes e arquitetos de programas de código aberto que se concentram em um roteiro. Na verdade, isso torna tudo mais fácil para um gerente de produto de código aberto, mas a maioria dos projetos menores, que ainda podem ser um fornecedor importante para o seu produto, não têm roteiros upstream que se estendem além dos próximos um ou dois lançamentos.

Os roteiros são úteis para clientes, vendedores, marketing e outros gerentes de produto. Além disso, se o seu produto é focado em usuários técnicos, os roteiros são importantes para desenvolvedores e arquitetos que dependem deles para integrar o seu produto aos seus produtos. Se o seu produto for uma plataforma ou serviço técnico (por exemplo, baseado em Linux, Kubernetes, Java, máquinas virtuais, etc.), você não está apenas consumindo de uma cadeia de suprimentos upstream, mas também faz parte da cadeia de suprimentos de produtos downstream criados por seus clientes. Isso torna um roteiro sólido ainda mais importante.

Seu roteiro nunca deixará todos felizes, mas pode ajudar a alinhar estratégias entre seu produto e os clientes que o compram. Isto é tão importante com código aberto quanto com produtos de software proprietários.