Sua API pode ser sensacional, ou seja, ter uma proposta de valor clara e bem definida, ter um portal de devs lindo, com os melhores protocolos de segurança e um design orientado ao RESTful. Ela pode ser mantida por uma excelente plataforma de APIs, entre diversas outras práticas recomendadas.

Mas por que eu, desenvolvedor, deveria usar sua API?

Já conheço outras APIs e confio nelas. Meus aplicativos vivem bem. Não sei quem você é.

Pois bem, você definitivamente precisa de um Plano de Marketing. Não faz sentido ter a melhor API do mundo se ninguém a conhece, e não entende do que se trata quando a encontra.

De fato, se sua API é sensacional e você já tem um Portal de Devs bem feito, já é meio caminho andado. Se você pergunta “O que seria um Portal de Devs bem feito?”, terei o prazer de responder a essas e outras perguntas neste artigo.

Vamos começar =)

Contrate um feirante

Alguns feirantes são excelentes vendedores. Passar dias vendendo sua mercadoria para milhares de estranhos deve ter algum efeito para desenvolver a skill de vendas. De fato, vender é uma habilidade tanto quanto falar em público ou organização pessoal. Ninguém nasce sabendo, certo?

O caso é que as dicas de criação de um Plano de Marketing para sua API passam diretamente pelas melhores estratégias de vendas de praticamente qualquer coisa. Se for peixe na feira ou sua Interface de Programação de Aplicações (API para os íntimos), o fato é que há alguns princípios universais. E, quando seguidos (e adaptados ao seu mercado e ao seu público-alvo), esses princípios inevitavelmente trazem resultados. Veja os princípios:

1. As pessoas julgam um livro pela capa;
2. As pessoas aprimoram seu julgamento com a contracapa ou folheando o livro;
3. As pessoas recomendam os livros que gostam;
4. As pessoas não gostam tanto de livros que não contêm um história;
5. Não há um gênero que agrade a gregos e troianos.

Perdão por ter usado uma analogia de vendedor de peixe e agora livros e Guerra de Troia. As analogias tornam isso simples de entender: se o feirante sobre o qual estamos falando for um bom vendedor, ele vai misturar um pouco de cada uma dessas técnicas e aí ele pode deixar de vender peixe e começar a vender livros a qualquer momento, uma vez que ele conhece as técnicas. Ele pode vender até sua API!

Vamos então nos aprofundar um pouco mais em cada uma dessas técnicas.

#1 – “Nunca julgue um livro pela capa”

Já ouviu essa frase em algum lugar? Acreditou nela? Vamos fazer um teste então. Você leria este livro?

É claro que esse é só um exemplo, mas podemos citar outros inúmeros. Infelizmente, o ser humano tem uma tendência natural a avaliar e julgar com informações superficiais e imprecisas, e isso torna o design de aplicativos, sites e produtos em geral uma característica muito importante.

Com sua API não poderia ser diferente, certo?

Um bom design deve ter o efeito “Uau” nas pessoas. Quando um potencial desenvolvedor entrar no seu site e procurar pela sua API, ele deve encontrar um Portal que desperte esse efeito. O grande problema é que a maioria das APIs não tem um componente visual adequado e, por conta disso, tudo que os devs encontram são blocos de texto, como este da MailJet:

Eles perceberam isso e mudaram. Veja como ficou a nova versão:

Bem melhor, não é? A nova versão é muito mais visual e contém exemplos mais claros. Esse é apenas um exemplo. Se você estiver precisando de inspiração, confira a página de Developers do Google. Das dezenas de APIs e SDKs existentes, praticamente todos são extremamente visuais e muito simples de entender, com instruções a respeito do que a API faz primeiros passos. Também há tutoriais e vídeos explicativos. A página da API do Drive, por exemplo, tem um quickstart com 8 linguagens de programação diferentes. Isso que é capa de livro, hein!

Se você tiver a oportunidade de encontrar seu público-alvo pessoalmente, em um evento, por exemplo, você deve preparar um pitch. Pitch é uma das artes envolvidas em vendas e sua técnica consiste em:

1. Introduzir sua marca e seu produto (no caso, sua API);
2. Expor as vantagens e os diferenciais da API, ou seja, sua principal proposta de valor;
3. Exibir uma demonstração ao vivo ou exemplos genuínos da sua API em ação (ou ambos).

Um pitch ideal dura poucos minutos e se tornou tão icônico no mundo do empreendedorismo que passou a ser chamado Elevator Pitch, em alusão a um encontro entre empreendedor/vendedor e possível investidor ou cliente em uma viagem de elevador. Não se fica muito tempo dentro de um elevador, e o intuito desse tipo de pitch é vender de forma rápida e eficiente.

#2 – Você já leu uma contracapa?

Digamos que o Joãozinho entra no site da sua API e pensa: “Essa API até parece legal, mas não entendi direito o que ela faz. Mexo com isso depois”. Mas sabemos que ele nunca voltará, certo?

O melhor mesmo é que a pessoa interessada tenha a chance de testar na hora, ou seja, abrir seus métodos e classes e botar a mão na massa. Em termos gerais, quanto menor for o seu TTFHW (Time to First Hello World), melhor. Falamos um pouco sobre isso nos slides de Indicadores para APIs. Você pode baixá-los de graça aqui.

É com base nisso que a analogia da contracapa de um livro faz todo sentido. É comum que a capa não seja o suficiente para que as pessoas tomem uma decisão. Quantas vezes você pegou um livro, olhou a capa e aí virou para olhar a parte de trás ou abriu para folhear e caçar algo interessante? Por dentro, você queria dar uma chance. Mas somente a capa não era suficiente para te conquistar, então você buscou mais conteúdo no interior do livro. A não ser que a capa fosse horrível, como aquela ali em cima.

Com uma API, é a mesmíssima coisa. A primeira experiência que alguém tiver com sua API será o divisor de águas. Se sua API tem um design RESTful, então há boas chances de você estar alinhado com as expectativas dos desenvolvedores. Se sua API ainda não tem um bom design, confira nosso material com 10 dicas para te ajudar a criar APIs RESTful.

Mas não é apenas o design. Você precisa oferecer uma boa documentação e um ambiente para testes adequado. Você realmente está repelindo devs, caso algum interessado tenha que passar quinze minutos procurando o SDK, mais vinte requisitando um token de acesso e outros dez tentando entender como fazer uma chamada ou decifrando a saída da chamada (caso você realmente queira complicar e não retorne JSON nem XML).

Isso tudo significa que alguém deve conseguir explorar sua API por completo sem escrever uma única linha de código. Você acha que conseguiria fazer isso em sua própria API? Novamente, lembre-se do TTFHW.

Esses conceitos são conhecidos como Developer Experience (DX). Você também deve se preocupar em oferecer padrões esperados e comuns na Internet. Já dei o exemplo do JSON e do XML. Lembre-se também de padrões de autenticação, como o OAuth, e use linguagens de programação comuns como Java e Python. Resumindo, você deve focar nos seguintes aspectos de DX:

• Documentação completa, abrangente e atrativa;
• Design focado em facilidade do uso (com padrões e linguagens de programação próximas ao seu público), além de SDKs úteis;
• Uma API que contemple tanto as chamadas de baixo nível para acesso de dados, quanto as chamadas de alto nível para gerenciamento do fluxo de dados;
• Um tempo mínimo de Time To First Hello World, como comentamos nos slides de Indicadores para APIs de Sucesso.

No próximo artigo, falaremos sobre os princípios universais restantes.