Firebase is the front-runner in the mobile Backend as a Service (BaaS) industry, with an estimated annual revenue of $7.9 million, double that of the runner up in this space, PubNub. Although there are a couple of large enterprise customers, Firebase’ 2 million customers comprise mostly of small apps and services. In 2014, after a short 3 years in business, Firebase was acquired by Google. Leveraging Google’s existing cloud infrastructure, analytics, and development tools, Firebase leaves its competitors in the dust when it comes to full-range support for app businesses over and above BaaS.
That being said, maybe there are things Firebase can improve on. If I was Firebase’ product manager, how would I design it differently to appeal to users and customers?
Firstly, it is worth taking a look at Firebase’s goal. Firebase aims to help developers build “better apps and successful businesses”. It does this by supplying customers with the tools and infrastructure for building scalable applications conveniently. A deeper look at the parent company of Firebase, Alphabet inc., may suggest that Firebase is another one of Google’s ventures to diversify its revenue streams while still holding true to the technology-centered culture of the company.
Secondly, to improve a product, we need to look at what problems it faces. There have been many complaints about the usability of Firebase’s Firestore database. As the main draw of the platform, Firestore supplies realtime syncing of application and database and is useful for messaging applications. However, many users of Firebase have asked for more as the platform outgrows its messaging-infrastructure former self.
Furthermore, despite being a front-runner in the mobile app hosting space, Firebase’s revenue is entirely dwarfed by the $8 billion of its enterprise big brother, Google Cloud Platform. Thus, another problem that needs addressing is its revenue generating model.
As Firebase’s product manager, I would make it more user-friendly by integrating Google’s already existing CloudSQL. Many developers start out using Firebase as a way to get their websites up and running quickly. However, they soon realise Firebase’s in-house database is wanting when it comes to building scalable applications requiring the robustness of a SQL database. Firebase should add CloudSQL to its dashboard and make it easily integratable with Firebase apps. It should also allow users to easily and safely migrate data from Firestore to CloudSQL. This will make Firebase more appealing to developers who require different types of databases to solve their different development needs.
This will also help to attract developers of different types of apps, instead of the likes of messaging apps needing a realtime database. This will increase Firebase’s user base so that it gains an even larger market share, helping to increase its revenue.
An alternative solution to gain more revenue is to raise pricing on Firebase plans. However, that might force existing users to switch to competitors such as PubNub and Syncano. As a customer of Firebase myself, I would be vehemently against raising subscription rates. (not that it should affect my judgment as Firebase’s PM)
To test the desirability of having CloudSQL as a feature, I would identify Firebase websites who might benefit from a SQL database and release a beta version to them first. Depending on their usage of the feature, I will then release it as an official feature. After the release, I will keep good track of key metrics like number of users, number of paying users to test my value hypothesis. It will also be interesting to analyse the cohort of apps that join Firebase before and after the feature to test my hypothesis that a SQL database will attract a more diverse group of apps to the platform.