How Much Do You Spend Attracting and Supporting Freemium API Developers?
02 May 2013
I had a question from an API owner land in my inbox. It is regarding the amount of attention and resources that should be spent on on-boarding new customers. Directly from the email:
How would you suggest companies place a quantifiable value on free API users? I know that it is very important to have a lot of people use your API so that they can make great things with your API and also give people a chance to really understand the value of what the API offers, but do you have any thoughts on how companies should decide how much to spend on an API conversion (AdWords, Hackathons, etc.)
Let's first address the freemium part of the question. It is my opinion that every API should have a freemium layer. But only as one part of a well planned developer incentive ladder. This freemium tier is the top layer of your funnel. It will provide a way for people to test drive your API, understand what it does and the value it can deliver in their world.
Your freemium layer should be easy to access, no billing required and provide a sensible access to your API resources--also your freemium tier should never appear as if it is in danger of going away. But freemium should be that first step, with clear, meaningful next steps towards on-boarding users as paid customers. Provide clear paths to becoming a solid, revenue generating and contributing participant in the platform.
Make it clear to developers that at a freemium level they don't get support, that they have to pay to get that. Don't let this tier of users dominate you. With this said you better have good docs, code samples, active forum, FAQ and other essential building blocks for your self-service, freemium customers to use. But the amount of resources dedicated to your freemium customers should be minimal.
In my opinion, your resources should go into supporting your paid tiers of customers, the one who fee your revenue model, communicate and provide feedback to your platform and deliver value to your platform and business--reciprocating the value you have provided them. API ecosystems are a two-way street.
The second part of the question I think is regarding how much resources you should spend to attract developers into the top part of your funnel, potentially bringing them into your freemium tier, with hopes of quickly converting them into paid. I have a different perspective on this than probably many other companies. I'm a fan of organic campaigns vs. paid campaigns.
My approach to API Evangelism is about generating organic content that will help explain what an API does and the value it delivers. I hack PHP, Python, Ruby or mobile projects against the API. I find problems to solve, that may reflect what my target audience is trying to solve. I just don't think very many people are ever going to look for an API. They are going to be looking for a solution to their problem, and it may just be the solution your API provides. So advertising and traditional marketing is harder to dial in. I prefer identifying, coding, solving the problem and telling the story that speak to the customers I'm looking for.
The downside of an organic API evangelism campaign is it takes time to work. It takes months before you see anything. It is a very SEO driven approach, but it is how I've built API Evangelist over 3 years. Its lower cost than Google Adwords spend and hackathons, but takes someone with passion and domain expertise, mad programming skills and the ability to write stories, publish to Github and work social media like kung foo master--to execute!
The moral of the story is, that you should spend as little as you possibly can on bringing in developers into your funnel, and supporting them in operating at your freemium tier. Don't let the freeloaders rule your world. But this is easier said than done. Its a lot of work to generate resources that will bring the right customer in the door, in an organic way, and it takes a lot of outreach to engage with the customers you have in the door to develop a sensible developer and partner framework.
I think I have several more stories to derive from this great question, so stay tuned.