Chegando ao mercado com um produto de código aberto
O papel do marketing do produto e das mensagens planejadas em um lançamento bem-sucedido.
Este artigo é o sexto de uma série sobre gerenciamento de produtos em uma cadeia de suprimentos de código aberto. Nos artigos anteriores, abordei os seguintes tópicos:
- Código aberto como cadeia de suprimentos
- O que é um produto
- O que os gerentes de produto fazem
- Diferenciando produtos de projetos
- Gerenciando o roteiro do produto de código aberto
Neste artigo, vamos nos concentrar na interseção entre código aberto e marketing de produto.
O que é marketing de produto?
Muitas pessoas com uma longa carreira em engenharia, inclusive eu, têm ideias erradas sobre vendas e marketing. Como uma comunidade de engenharia, vemos isso como encomendar brindes, nomear coisas, executar campanhas publicitárias e criar white papers. Há uma piada na comunidade de marketing sobre como os engenheiros estão sempre dispostos a fornecer suas “opiniões” sobre decisões de marketing sem compreender totalmente a disciplina, mas os profissionais de marketing raramente – ou nunca – fazem sugestões sobre melhorias no código. Para trabalharem juntos, engenheiros e profissionais de marketing devem compartilhar uma definição comum.
Embora os profissionais de marketing de produtos ajudem a conduzir essas tarefas comumente reconhecidas, a função é muito mais rica. Os profissionais de marketing de produtos, profissionais de marketing técnico e evangelistas têm responsabilidades externas, como criar conteúdo (por exemplo, blogs, comunicados à imprensa, white papers, demonstrações), entregar sessões de roteiro para clientes (bem como analistas e jornalistas), construir conteúdo para equipes de vendas e muito mais. mais. Combinadas, essas funções de saída são frequentemente chamadas de lançamento de um produto no mercado, mas, igualmente importante, o marketing de produto também tem funções de entrada. Eles servem como outro par de olhos e ouvidos para ouvir as necessidades do cliente e fornecer informações para a estratégia do produto. Há um ditado em gerenciamento de produtos: nada de interessante acontece dentro destas quatro paredes. As empresas devem sair pelo mundo, falar com os clientes e, mais importante, ouvi-los.
Em organizações menores, o gerente de produto costuma ser responsável por todo o trabalho de entrada e saída. Em organizações maiores, essas funções são frequentemente divididas em gerenciamento de produtos e gerenciamento de marketing de produtos. Às vezes, as funções são até divididas em marketing técnico e funções evangelizadoras. Combinadas, essas funções, bem como a do arquiteto (uma função de engenharia) e da pessoa com experiência do usuário (UX), são frequentemente chamadas de equipe de produto. Embora o marketing do produto seja geralmente responsável pela chegada ao mercado, há um papel colaborativo a ser desempenhado por todos os membros da equipe do produto. Esta colaboração é essencial, especialmente no contexto de uma cadeia de abastecimento de código aberto.
Marketing de produto e código aberto
Existem muitas áreas de foco definidas em diferentes estruturas de marketing de produto (por exemplo, Estrutura Pragmática ou Os 4 Ps). Como esta série se concentra especificamente em produtos de software empresariais e em nuvem no contexto de uma cadeia de suprimentos de código aberto, exploraremos as seguintes funções dos comerciantes de produtos:
- Posicionamento e mensagens: esta é uma metodologia acordada sobre como sua empresa falará sobre seu produto e onde ele se encaixa no mercado. O objetivo é tornar mais fácil para os clientes entenderem onde seu produto é forte.
- Personas de compradores e usuários: um pouco diferentes das personas de engenharia, são uma descrição generalizada do que interessa aos clientes típicos e por quê. Eles ajudam a alinhar todos na organização para atender às necessidades do comprador.
- Plano de marketing: descreve as estratégias e táticas que uma equipe de produto usará para conscientizar as pessoas sobre a tecnologia e como os compradores serão adquiridos.
- Lançamento: O lançamento do código e o lançamento de um produto são duas coisas distintas. A versão disponibiliza o código, os binários ou o serviço. O lançamento foca em quando, onde, como e quanto o produto é discutido no mercado.
- Alinhamento de vendas: as vendas de produtos são muito mais eficientes quando as equipes de vendas, marketing e até mesmo de engenharia falam sobre um produto e sua tecnologia da mesma maneira. Normalmente, essa é uma função do marketing de produto.
- Conteúdo: inclui blogs, apresentações e outras formas de conteúdo focadas em clientes, parceiros, jornalistas, analistas e até mesmo membros da comunidade de código aberto.
Um mergulho profundo em cada uma dessas áreas está além do escopo desta série de blogs, mas é importante entender como o marketing de produto se encaixa na equipe de produto, especialmente no contexto de código aberto. A actividade na cadeia de abastecimento a montante pode informar, mas não dita a forma como os comerciantes de produtos comunicam o valor dos seus produtos. O upstream pode ampliar a liderança inovadora e impulsionar a adoção de tecnologia, mas não é um funil de vendas em si.
Considere minha analogia anterior sobre sabão em pó (código aberto como conscientização); só porque OxiClean oferece valor como um excelente removedor de manchas em um limpador em spray multiuso, não significa que cada usuário desse limpador em spray multiuso seja um bom líder para seu sabão em pó. Quando alguém está comprando sabão em pó, estar ciente da tecnologia OxiClean pode torná-lo mais interessado, mas as pessoas compram sabão em pó por motivos diferentes dos de produtos de limpeza em spray multiuso. Pense nisso algumas vezes e deixe-o penetrar.
Os comerciantes de produtos são responsáveis pela venda do produto, não pela cadeia de abastecimento. A cadeia de abastecimento apenas fornece consciência sobre quais tecnologias são eficazes na resolução de problemas técnicos.
Por exemplo, Kubernetes é uma ótima tecnologia e um ótimo projeto upstream. Qualquer cliente interessado em operar contêineres em grande escala provavelmente conhece essa tecnologia. No entanto, alguns clientes estão procurando uma solução hospedada de uso geral, onde outra pessoa a execute para eles. Outros clientes potenciais estão interessados em construir uma solução altamente personalizada no local, com controles de segurança rígidos. Esses dois compradores estão comprando por motivos diferentes, mas ambos notarão o nome Kubernetes. Kubernetes é bom para conscientização, mas não é um funil de vendas. Você não pode vender a um cliente que deseja um serviço hospedado uma solução local ou vice-versa.
Conforme mencionado em um artigo anterior, “O que as equipes de produtos de código aberto fazem?”, os profissionais de marketing de produtos precisam ter cuidado para não tratar a cadeia de suprimentos de código aberto como um funil de marketing barato ou gratuito. Esta é uma enorme armadilha. Outra armadilha é tornar a “edição comunitária” gratuita para uso pessoal. Isso não é bom para clientes em potencial e também não é bom para construir uma comunidade. A metodologia de trabalhar retroativamente a partir das necessidades do cliente é uma ótima maneira de evitar essas armadilhas.
Trabalhando para trás
Trabalhar de trás para frente a partir do cliente requer a captura das informações mais importantes sobre o produto, incluindo por que um cliente se importaria e, por sua vez, por que os vendedores e parceiros deveriam se importar. Isso ajuda a alinhar naturalmente a compreensão de todos sobre o seu produto. Trabalhar de trás para frente irá naturalmente destacar as lacunas entre o produto e a cadeia de abastecimento a montante. Dito de outra forma, ao trabalhar de trás para frente, será extremamente óbvio onde os projetos upstream por si só não fornecem tudo o que um cliente pagante precisa (por exemplo, uma solução Kubernetes hospedada).
Trabalhar de trás para frente costuma ser descrito como escrever primeiro o comunicado à imprensa. Um comunicado à imprensa é apenas um dos muitos tipos de documentos usados pelas equipes de produto. Documentos semelhantes incluem, mas não estão limitados a:
- Documentos principais de mensagens
- Posicionando documentos
- Documentos de mensagens
- Documentos de posicionamento e mensagens (P&M)
Assim como ao criar o roteiro do produto de código aberto, não se deixe levar pela ferramenta; pense na importância do processo em si. Por exemplo, existem muitos modelos diferentes para documentos de P&M, e equipes diferentes geralmente criam seus próprios campos. Alguns documentos de P&M vão mais fundo e exploram as diferenças entre personas ou outros fatores. Os campos reais e a profundidade técnica variam de acordo com a equipe, mas o processo é o mesmo. Trabalhe de trás para frente a partir do cliente.
Documento de posicionamento e mensagens
O documento de posicionamento e mensagens une todas essas coisas em torno de uma estrutura coerente. Nem toda equipe de produto cria esse documento, mas é uma metodologia que força a equipe de produto a pensar profundamente sobre o que está tentando alcançar, por que e para quem. A construção deste documento ilumina a missão do produto, o que ajuda a alinhar todos, desde os fornecedores upstream até os vendedores.
Aqui está um modelo de documento de posicionamento e mensagens que você pode usar como base no Google Docs.
(Scott McCarty, CC BY-SA 4.0)
Armadilhas
As empresas participam do código aberto por vários motivos, muitos dos quais são falhos (consulte "Estabelecimento de metas de código aberto" para ver os bons). Por exemplo, a transparência é absolutamente uma boa razão, mas não é a única razão para participar do código aberto. Uma razão melhor é o aspecto do código aberto voltado para a comunidade. Este é um investimento melhor para cada dólar gasto no desenvolvimento de uma tecnologia, porque outras pessoas estão ajudando você a construí-la gratuitamente (veja também “Por que a Red Hat está investindo em CRI-O e Podman”).
Código aberto não é marketing gratuito. Tratar o código aberto como desconto ou marketing gratuito é uma estratégia para o fracasso. Você deve diferenciar a missão do seu produto da missão upstream. General Motors, Volkswagen, Toyota e Tesla não vendem carros porque anunciam que robôs utilizam para construir os carros, que marca de aço utilizam ou que lâmpadas LED utilizam.
A combinação de todas as escolhas feitas pela equipe de produto é o que diferencia um produto. As equipes de produto, especialmente as equipes de marketing de produto, devem compreender isso com total clareza. Cada dólar gasto para destacar o valor do fornecedor é um dólar que não gasta para destacar o valor do produto.
Dito isto, a equipe do produto deve pensar de forma absolutamente holística sobre a cadeia de valor desde os fornecedores até o produto. Compreender o valor fornecido pelos fornecedores é um componente significativo no valor do produto. Mantenha o foco nas necessidades do cliente e trabalhe retroativamente. Não comece pelos fornecedores e siga em frente.
Conclusões
Embora eu tenha abordado muito material, este artigo ainda não arranhou a superfície do marketing como disciplina — na verdade, múltiplas disciplinas (digital, conteúdo, produto, marca, anúncios, etc.). Os comerciantes e gerentes de produtos precisam trabalhar retroativamente, desde a necessidade do cliente até o produto, mesmo com software de código aberto. Eles devem se concentrar em capacidades e recursos pelos quais o cliente se sentirá bem em pagar. Os gerentes de produto e profissionais de marketing não devem cair na armadilha de tratar o código aberto como um funil para seus produtos.
(Scott McCarty, CC BY-SA 4.0)
Da próxima vez que você estiver lendo material de marketing de um produto de código aberto, preste atenção ao posicionamento e à mensagem e tente inferir com qual pessoa eles estão falando. Se algo não está fazendo sentido para você, pode ser porque não é direcionado a você! Também pode ser porque a equipe de marketing está cometendo o erro de se concentrar no que um projeto upstream faz, em vez de em seu produto.