Ecosystems, Developer communities, Public APIs and the HUGE gap in between
In my pervious posts I mostly shared stories and examples from my technical day-to-day work at DoMetrix, and while this post is mainly inspired by the challenges I encountered so far. Today, I would like to discuss a few bottom-line-realizations and main differences between having an ecosystem around a product vs. making its data available via an API or anything in between.
API and external integrations
In todays reality, companies behind products understand that the data users generate or collect inside their platforms is valuable. this also means that having access to that data by the end-user (or business consumer) is in need, outside the boundaries or the official product interface. In fact, when selecting a product or a SaaS solution, one of the key features it must have is the ability to export that information in commonly standard formats like JSON or XML. This is a direct result of companies’ need to achieve a better understanding of their efforts in all, and across domains — R&D, sales, marketing, support, product, long-term user retention, etc.
Developer communities — A small step forward
Developers communities can quickly become the innovation hub behind a product, making it stronger and adding value to an initial offering. Companies with a significant client-base may eventually employ a dedicated person to manage such community and engage with it to better promote the business best interests. With that said, developer communities for profit-oriented businesses will be harder to sustain, unless they make the leap towards enabling an entire eco-system around the product.
Mind the Gap
Between having a an API and an eco-system lies a huge gap.
The main thing to note here is that an API is now a commodity - everyone’s got one! but an API is only a data retrieval layer, it’s not an eco-system.
If this still isn’t clear, I’d like introduce the following example — imagine that you bought a shiny, new, state of the art mobile phone, made by a leading manufacturer. When you purchased it, you were told there were millions of apps you can install on to it, to extend its functionality. However, installing that new app you heard about required you to physically connect your device to a computer, and drag and drop files into a folder on your phone. how does that strike you?
The reality of APIs is even worse — with an API you’re (only) getting access to data, not “screen real-estate”. So developers must create a parallel interface that requires the users to have another browser window open to use it…. going back to our mobile phone example, imagine you had to use 2 devices every time you started an app — one device is the original phone and another is a parallel device that runs the app. that would be unbelievable wouldn’t it? if that was the case, how many apps do you think you’ll actually have? point. made.
Browser tabs and the mental block of 3rd-party integrations
For the past few months I’ve been working on a product that integrates to another platform via API. In more details, my product consumes data from it and analyzes it, turning it into insights.
When we started on-boarding companies and have them check out our initial offering, we received some positive feedbacks and even got a few feature requests. However, checking the usage patterns of our beta users group showed that users were only coming in every few days, if at all.
When we looked deeper and held conversations with them, asking about their impressions and feedback, we also presented them with questions about a potential pricing model and what they’d be willing to pay for such service. To our amazement, while a few companies saw the value of our solution, others said they were only willing to pay a (very) small sum, since they only see themselves checking in on the system every week, or every few days, and not something they would have open at all times.
Being the creative startup-kinda’-team, not accepting that as an answer — we decided to examine the root cause of that feedback — which is essentially, in short, the imaginary phone+apps scenario I mentioned above. While our users liked that our system was updating in real-time, they did not care about consuming these insight as they were happening if that meant they had to watch another “screen” or keep another tab open. While they liked seeing trends and insights, they could not make that extra effort in having another browser window.
In my eyes, this is one of the biggest challenges integrated applications face today — that mental “block” and effort required from their users. that additional browser tab, that one more login dialog they have to go through. on top of these, being a paid service means that’s one more place you’ll have to provide billing details, which raises the bar even more. Can you imagine sharing your credit card information to every app developer on the app store? neither can I!
The recipe for delicious a eco-system
With these new understanding in place, I strongly believe that from a developers’ standpoint, an eco-system means having (at least) the following:
- Full access to both data and UI of a product. with the ability modify it within pre-determined boundaries.
- SDK libraries and abstraction layers
- A company-backed marketplace, that allows easy adaption to users, and exposure to 3rd party applications
- A revenue sharing business model between the company and its developer community.
With the above in place, developers are actively encouraged to create solutions that can extend product functionality, knowing that there’s a dedicated place to expose their solutions to potential users and generate revenue. And while doing so, they don’t have to relay on external marketing to reach their audience, or support billing, subscriptions, refunds etc. it will all be managed for them, so they can focus on their apps!