Como estamos construindo a plataforma da RD Station
Bom… alinhar o entendimento sobre o termo plataforma vai ser nosso primeiro passo por aqui, dado que é um termo muito ambíguo e que gera muita dúvida nas discussões. Vou tentar dar exemplos práticos para ilustrar um pouco melhor e servir como apoio à teoria. Depois disso, vou entrar um pouco no contexto das Martechs (Marketing + Tech) para, ao final do artigo, ser mais específico sobre o contexto da RD Station. Bora lá?
O que são plataformas? Do que se alimentam? Onde vivem?
Vamos começar pela definição básica apresentada no livro Platform Revolution, em tradução livre:
Uma plataforma é um negócio que gera valor ao habilitar interações entre produtores e consumidores. A plataforma é uma infraestrutura aberta e participativa para tais interações e define as condições de governança para elas. O propósito abrangente de uma plataforma é: promover os encontros entre os usuários (produtores/consumidores) e facilitar a troca de bens, serviços e moeda social, habilitando desta forma a criação de valor para todos os participantes.
Gosto bastante desta imagem para ilustrar o valor do ecossistema das plataformas que tirei do livro Modern Monopolies:
Beleza… teoricão… então vamos a alguns exemplos que também peguei do Modern Monopolies para ilustrar um pouco melhor esse definição.
Um dos exemplos que o livro traz é o YouTube. Para termos uma noção do desafio que é para o YouTube promover o encontro entre um usuário e um vídeo relevante para ele, é importante entendermos a ordem de grandeza das publicações na plataforma: em 2020, a cada minuto os usuários subiram cerca de 500 horas de vídeo, ou seja, a cada hora são quase 20 dias de vídeos se fossemos assistí-los linearmente. Para assustar um pouco mais: a cada dia sobem 3 anos de vídeos! É uma escala impressionante.
Sendo assim, o YouTube precisa elaborar regras, padrões e políticas para conseguir garantir que os vídeos existentes na plataforma façam sentido para a audiência que ele quer atrair. Vou fazer uma comparação bastante esdrúxula aqui para ficar bem fácil de entender. A pornografia impulsionou muitos avanços tecnológicos na história da humanidade e com a internet não foi diferente. Muitas plataformas de vídeos pornográficos já existiam na internet muito antes do próprio YouTube e até hoje são tão populares quanto ele. Mas por que eu estou falando de pornografia aqui? Justamente para ilustrar que o que diferencia o YouTube de plataformas de vídeos pornográficos, tais como XVideos ou Pornhub, são apenas as regras, os padrões e as políticas de uso da plataforma. Provavelmente se o YouTube permitisse a publicação de vídeos pornô, esse seria o tipo de conteúdo predominante em seu acervo e não seria possível que ele se tornasse uma das maiores plataformas educacionais do mundo, por exemplo.
A analogia que eu mais tenho utilizado para ilustrar a mentalidade para a construção de plataformas é o iOS. O pioneirismo do iPhone não estava necessariamente no hardware e sim no software. A mentalidade através da qual a Apple desenvolveu a plataforma do iOS habilitou que uma enorme quantidade de pessoas desenvolvedoras de software construíssem aplicativos para o iPhone e criassem inovação complementar. Essa estratégia gerou um diferencial absurdo para o produto da Apple ao se comparar com os outros celulares e smartphones existentes na época. O slogan do iPhone chegou a ser “tem um app para isso”, pois era possível encontrar aplicativos para qualquer coisa que você quisesse ou precisasse: de jogos a gestão de finanças. O sistema operacional do iPhone é tão poderoso que permitiu o surgimento de empresas que são gigantes atualmente, como o WhatsApp por exemplo.
Segundo o Modern Monopolies, um fator importante para o sucesso de uma plataforma é sua capacidade de reduzir o custo das transações e quero usar justamente o exemplo do WhatsApp para ilustrar. Na época do lançamento do iPhone, uma das empresas que dominava o mercado de telefonia móvel era a BlackBerry. Os telefones da BlackBerry possuíam um produto praticamente idêntico ao WhatsApp: o BBM (BlackBerry Messenger). A proposta era a mesma que a do WhatsApp: ser um SMS gratuito e ilimitado, que se não me falha a memória era o que tinha escrito na descrição do aplicativo do WhatsApp nos primórdios da AppStore, quando ele inclusive custava cerca de 1 dólar para os usuários. Antes do iOS e da AppStore, se alguém quisesse transformar o envio de SMS em gratuito e ilimitado precisaria fundar uma operadora de telefonia ou uma empresa de engenharia para construir um smartphone com o hardware, sistema operacional, logística e tudo que envolve esses negócios absolutamente caros, complexos e arriscados. Com a venda de milhões de unidades de iPhone por todo o mundo, a Apple encurtou (e MUITO!) toda essa cadeia de produção e permitiu que as pessoas focassem apenas no desenvolvimento do software. Além disso, a Apple não precisou colocar energia em construir um concorrente para o BBM (apesar do iMessage até ser) para conseguir vencer essa competição com larga vantagem.
Martech é um universo à parte
Uma referência que gosto bastante para representar a complexidade e profundidade de soluções no mercado de Martech (Marketing + Tech) é o supergráfico da ChiefMartech. Se liga:
A logo da RD Station está nessa imagem em algum lugar por aí e, sempre que bato o olho nesse infográfico, lembro dessa imagem:
A quantidade de soluções de marketing e a especificidade de casos de uso é muito impressionante. Além disso, as tecnologias para marketing evoluem muito (MUITO!) rápido… a cada dia surgem novas necessidades e, consequentemente, novas soluções. A partir da constatação de que a tecnologia muda em curva exponencial e que, por outro lado, as empresas se adaptam a elas em curva logarítmica, surgiu a Lei das Martechs:
Entendendo tais características do mercado no qual a RD Station está inserida e a velocidade em que as necessidades dos nossos clientes evoluem, começamos a pensar as estratégias para conseguirmos não deixar essa “boca de jacaré” do gráfico da Lei de Martech abrir ainda mais. Uma de nossas apostas em produto para vencer este desafio é através da construção de uma plataforma robusta que permita que o mercado desenvolva soluções complementares ao redor da RD Station, nos moldes do que aconteceu com a Apple e o iOS.
Mentalidade de plataforma na RD Station
Como expliquei anteriormente, um dos principais desafios de uma plataforma é conectar os produtores com consumidores. Ao se construir uma plataforma, um dilema inicial a ser resolvido é que os autores do Platform Revolution nomearam de problema do ovo e da galinha:
Os usuários não usarão uma plataforma até que ela tenha valor e uma plataforma não tem valor se os usuários não a utilizarem
A RD Station atua em um recorte bastante específico de mercado que são pequenas e médias empresas de mercados emergentes. Por ser a empresa líder do segmento no Brasil e contar com um importante ecossistema de clientes e parceiros, a plataforma da RD provavelmente não terá que lidar com o problema do ovo e da galinha uma vez que possui uma base de quase 40.000 clientes.
Uma das formas de criar diferencial e causar disrupção (detesto essa palavra mas bora lá), segundo Thales Teixeira no livro Unlocking the Customer Value Chain, é a hiper-especialização. Sendo assim, o desafio da nossa plataforma vai ser construir novas mecânicas para permitir que soluções de marketing e vendas, especialmente aquelas mais específicas dos países em que atuamos, consigam se integrar facilmente à RD. Ao tornar nossa plataforma extensível para nosso ecossistema, conseguimos nos tornar cada vez mais especializados para os mercados onde os concorrentes da RD não entrarão com tanta facilidade devido à necessidade de educação do mercado, um dos principais diferenciais e que é parte fundamental da cultura da RD Station.
Existem algumas formas de habilitarmos inovação complementar no produto. A mais óbvia e talvez a base para a grande maioria delas é a construção de APIs públicas. Evoluir nosso conjunto de APIs, ter documentação melhor, trabalhar forte para a construção de uma comunidade desenvolvedora ao redor da plataforma da RD é importantíssimo para atingirmos nossos objetivos de negócio. No entanto, como já havia citado em um artigo anterior por aqui: API é apenas uma interface!
Ao longo do último trimestre de 2021, nosso time de plataforma (que chamamos de Foundations por aqui) trabalhou bastante em identificar outras oportunidades “plataformizáveis” que não somente APIs. Pensamos em algumas outras mecânicas que, ao juntar com a necessidade de abrir cada vez mais APIs, acabamos nomeando como Open RD Station (créditos ao Juliemar Berri, que se inspirou no Open Banking para dar o nome à visão).
Vou explicar brevemente como funcionam duas das mecânicas que são hipóteses fortes para serem validadas em breve: Open Segmentation e Open Automation.
O Open Segmentation consiste em habilitarmos os nossos produtos RD Station Marketing e RD Station CRM consigam criar novos casos de uso de segmentação sem que o time de plataforma responsável pelo motor de segmentação da RD precise desenvolver código. Ao construir esse tipo de mecânica, teremos a possibilidade de decidir quais destas mecânicas devem ser liberadas também para dar mais poder ao nosso ecossistema de aplicativos e quais delas devem ser utilizadas somente por nossos times internos para dar escala à nossa produtividade.
A Open Automation também é um caminho por onde conseguimos enxergar inúmeras oportunidades para a construção de mecanismos com enorme potencial de criação de inovações complementares. Seguindo a mesma lógica do Open Segmentation, a ideia é habilitar que nossos produtos RD Station Marketing e RD Station CRM, além dos aplicativos do nosso ecossistema, consigam criar tanto novos gatilhos de automação quanto ações e, eventualmente, divisões de caminho sem que nosso time do motor de automações precise programar cada um destes casos de uso.
Reflexões finais
É bem provável que nosso maior desafio em construir a plataforma da RD Station de forma escalável e inovadora esteja na mudança de mentalidade. Conseguir construir o produto de forma equilibrada, dosando bem entre o genérico e o específico, é bastante difícil e requer muita sabedoria para não cairmos em projetos estruturantes gigantescos ou com baixa conexão com o cliente/objetivos do negócio. Estamos nos policiando para começarmos sempre resolvendo os problemas de forma específica para depois irmos generalizando ao invés de construirmos a plataforma de forma super generalista mas, ainda assim, sabemos que nem sempre esse tipo de abordagem é possível.
Se interessou pelo tema? Me conta aí como você abordaria esse tipo de problema… como você buscaria esse equilíbrio entre plataformas especialistas vs plataformas generalistas?
