Why we built StatX
Every startup is a journey. This is the story of our journey so far.
It was 2015, and it was clear that mobile had eaten the world — with over 1.5 billion smart-phones worldwide.
But the best and widest-used mobile apps were for consumer use: Facebook, WhatsApp, Instagram and the like. Business users need information to make decisions and the fact that everyone has a mobile phone makes it an ideal vehicle for business information delivery.
But there were precious few widely used mobile apps for business users.
And the mobile apps were mostly re-cast or shrunk versions of legacy web applications with onerous user interfaces. The closest thing to business information delivery on mobile was email. But email was invented long before mobile phones, and is generally too long-winded and inefficient for information retrieval. So messaging made a mark as an alternative to email (Slack, HipChat etc.). But messaging suffers from the problem of being another “stream” that the business user struggles to keep up with. Instead of reducing the burden of email, messaging apps have added the burden of yet another flow to keep track of. Messages flowing away in a chat among friends may be fine, but a stream is simply not an ideal means for business information delivery.
Business dashboard apps are better suited for information aggregation and summarization but are heavyweight, still largely legacy web-based, not native mobile, and really have not exploited the power of the mobile platform.
The time was ripe for something new…
Prasad had built enterprise SaaS software at Instantis (acquired by ORCL), but this was the old legacy web-app kind. He had learnt that business users have complex and disparate software systems around them, yet desperately want ease of use and easy accessibility to their business data. Business data is complex, yet users often need to focus on a few critical pieces of information (e.g. revenue this quarter, number of bugs still open and number of emails clicks in a marketing campaign). So the idea of the “stat” germinated to simply and easily capture just the summary metric or status on top of the deeper data that would continue to exist in the legacy systems. And it was clear that there was a crying need for this to be in a mobile app for all the reasons above.
Independently, Pablo had successfully co-created Google Now from zero to hundreds of millions of users. Google Now had delivered on the promise of bringing to mobile, just right, relevant information to the consumer and getting their attention via the power of push notifications. Google Now had at one point sent millions of notifications a minute during the FIFA World Cup. This was built on the information that Google had about the user — email, calendar, browsing history etc. Pablo wanted to build something at the same scale in a business context, with a revenue model.
Prasad and Pablo met through a mutual co-worker who had worked at Instantis and Google, discussed the above and a whole lot more, and decided to combine their respective expertise to solve this really big problem: delivering just-right updates to a business user on mobile from data that might live anywhere.
Our vision was to be the universal mobile app where you expect to efficiently get data and updates from any system or any person.
We worked to put together a prototype of the app and were very lucky to quickly find investors that believed in us and in the potential. Zaw Thet of Signia Venture Partners, Kanwal Rekhi of Inventus Capital Partners and Rob Siegel of Xseed Capital invested $2.5M to enable us to build a superb team and product.
The building blocks
Deep Mobile DNA
We decided early on to build StatX as a native mobile app for both iOS (in Swift) and Android (in Java) and simply not built a web app at all. This forced us to build for small screens, quick glances, touch interfaces, simplicity, and visual attractiveness. And since we were not porting a legacy web app, we were building native mobile from the ground up. So the StatX mobile app is unlike any other business mobile app you will find.
We think of browser-based web apps as legacy, the way COBOL server apps and Windows client apps became legacy two decades ago. Non-native mobile apps are distinctly inferior in visual appeal, user interface performance and the ability to exploit the underlying mobile platform.
We had the benefit of a blank slate, so we first created this simple, basic yet universal building block — the “stat” (hence the name of the company StatX) to contain and convey updates. Twitter had created the tweet to contain succinct text. We created the “stat” to convey the kind of information commonly needed in a business context — to be a either a numeric value (e.g. revenue, deal funnel, email opens, Facebook followers and building energy use) or a status (e.g. are we done, what stage is this deal at, do we have approval on a budget and what items in this checklist are completed).
The stat was always intended to be a quick, succinct summary instead of the full underlying data set.
We came up with an initial set of common numeric and status representations and grew this list over time. We carefully designed each stat to be a pure native mobile object to exploit the power of mobile and also respect its constraints.
So we designed the stat to
a) have ‘just right’ information density — to be visual, to have succinct and quick conveyance of the critical information, to have a certain number of them that fit on a mobile screen without requiring too much squinting or too much tapping.
b) be an “accumulator” — that is, the stat would always display primarily the latest value/status — because that is most often what you care about. This is superior to a stream of email or text messages where there is no accumulation and you have to peruse the entire trail.
c) allow for collaboration — by allowing a human to update the stat by touch (exploiting the fact that mobile phones have touch interfaces) and efficiently provide an update to others.
d) leverage push — to exploit the fact that the user always has her phone and we can always get her attention with a push notification. Hence, if the value of a stat changes, it triggers a push notification without any explicit action. A cool additional result of this is that if a user is looking at a stat, it updates automatically without refresh.
We created a really simple sharing model — borrowing from the group notion in consumer messaging apps (WhatsApp, Messenger etc.) — to create simple, flat groups that would share a collection of stats (instead of text) and be always in sync (via push) when any stat changed. We have built the group model to be “private” by default to the members. We do have a notion of “open” groups that are intended for publishing and can be followed by anyone who is interested in the content, but this is currently not our focus.
Because the stat is touch-enabled and can be updated on the phone by a human, StatX can be used by a group (team members, service providers and their clients etc.) to collaboratively send instant updates to the group.
The third major piece was to enable the stats to be fed by data from existing systems. Clearly, businesses have data in a wide variety of systems. There are a myriad of functional groups — CRM, Accounting, DevOps etc. and many deployment modes — in the cloud or on premise or even on the desktop.
So we decided to provide many ways to populate stats in StatX.
First we built out a REST API to allow data to be sent to StatX from any external software system. We created plug-ins to Microsoft Excel and Google Sheets that call this API — and this enables any spreadsheet cell to be sent with a single click to a stat and shared with any group of users on mobile. We also created a Zapier connector to allow any of the 750 Zapier-enabled apps to send a zap to StatX as a result of any event in their system — to create or update a stat.
But we realized that we needed to make it even simpler for an end-user to pull data from an existing cloud-based app. So we built an “in-app connector” ability to connect to a cloud data source all on the phone — perform the authentication, do a quick tap-tap configuration and have a set of stats auto-created and auto-updated from data in the remote app.
This is really the first time this has been done in a pure mobile app.
So you can connect directly from mobile to our growing list of apps (QuickBooks, Xero, Google Tasks, WordPress, MailChimp, GitHub etc.) and get an instant dashboard that keeps you informed about relevant changes in the connected app. We have architected our system to allow us to quickly add new apps and have them appear on our users’ phones with no mobile app version update needed. If a cloud-based system has a REST API, we can easily connect to it and bring its data and updates to mobile.
So put these four aspects together — the deep mobile DNA, the stat, the sharing model, the connectors — and StatX is really this new animal that simply has not existed before. Frankly, we have struggled with this “X for Y” model of what to call ourselves. Are we the “Instagram for Business”, “ Twitter for Data”, “WhatsApp for Business”, “Slack for visual updates on mobile”, “Google Analytics for your business”, “Tableau for mobile” … None of these seem to fit.
A simple description that comes closest is this — we are a hybrid messaging + dashboarding mobile app.
This makes sense — business data is delivered in dashboards and business teams need to collaborate. In our world, the “dashboard” is composed of these mobile-optimized stats that are tied to a piece of important data. The stats become the live shared data-rich canvas that teams use to collaborate. Because of the unique properties of the stat, we believe our dashboards are unique — they are truly native mobile, simple, succinct, efficient and bi-directional. Our messaging is unique — instead of creating text, the user simply updates a stat by touch to succinctly send an update to the group.
In order to expand the “data from anywhere” capability, we will eventually open up the ability to create in-app connectors to third parties. Thus, any third party with their data available via a REST API would get an instant dashboard+messaging app for their users. And with this StatX will evolve from being an app to being a platform.
We very much wanted to build a recurring revenue model (Prasad has been doing recurring revenue starting back in the mid nineties) and we found we were blazing a new trail here. Almost all consumer apps have a one-time fee, only a few content-oriented apps have recurring fees. Many business web apps are SaaS and many have associated mobile apps, but we found none that rely purely on a mobile app for recurring revenue.
Since StatX could connect to a myriad of cloud apps, we had to make a choice about which in-app connector would deliver enough value that we could charge a recurring fee. We stumbled into accounting as our first vertical, and QuickBooks in particular, because we were working with an accounting firm that was interested in simply providing live financial updates to their users. We started with manual updates on the phone but eventually realized that we needed automating updates by pulling data directly from QuickBooks. We have found terrific reception to our QuickBooks connector (see reviews on Intuit’s apps.com) and users will pay a recurring monthly fee of $10/mo to get live financial updates. There are 1.5 million QuickBooks Online users worldwide, representing a TAM of $180M annually. We have already added a Xero connector, with a potential of 500K users, representing another $60M in TAM
This is just one vertical, we are in the process of doing this with many more. Stay tuned.
Prasad Raje & Pablo Bellver