Select Page

Our focus on insights was one that came about organically as we went about solving our customer pain points. CloudMunch’s UI allowed users to view insights about their automated tasks, builds, deployments and assets. Over time, we gradually realized that “insights” were what our users actually appreciated the most.

When I first realized that we were pivoting from automation to insights, I was a little concerned. Insights seemed like a Demo feature (like the “Demo mode” we see in Televisions – which is put into televisions only to be used in showrooms and is never accessed by actual users) or a feature which looks appealing but is actually impractical (Kabir gave me a good example for this one – Touch screen controls for car audios; imagine actually using one while driving). What follows are mostly my thoughts on this change in direction and how we ensure it works.

Provide Distinct Value

“Build vs. Buy” is a question all tech teams ask themselves and one we have had to answer frequently when selling our automation platform. Selling an Insights product might bring up similar questions. Our first challenge will be to get customers to see enough value in Insights AND want to try CloudMunch.

Most tools today (ex: Github, Jira and Sonarqube) already provide insights. To be of value, we will need to provide different and better ones. To this end, rather than duplicating information, our value might lie in providing insights where tools intersect. For example, Github provides data about development trends, Jira the actual value being generated (defect fixes, stories) and Sonarqube trends about the quality of code. CloudMunch, since it can access all three, can provide insights about which modules are more likely to be buggy than others (and so allow teams to plan more effectively).

Another possible USP (which came up in a conversation with Prasanna) is that most tools don’t yet provide insights over time. Take for instance a project team’s history making production upgrades. While they may already use a system to get the necessary approvals and plan upgrades, they may consistently miss their estimates on the risks or time necessary. Using information generated over time from gating systems, which themselves don’t use this data, CloudMunch could generate insights – which would help managers predict outcomes of a production upgrade more reliably.

Different Customers

Hitherto our customers were development teams themselves or senior managers managing several teams. With the pivot to insights, these may not be our typical customers any longer. With Insights, value may be best seen where there is some communication using insights i.e. where distilled information (from different sources) is presented from publishers to subscribers.

One example could be that of a DevOps team providing services to several in-house teams. They could use CloudMunch to quickly create tasks, monitor services and use Insights to provide periodic consolidated updates to their customers. Another could be a compliance team whose job it is to monitor project teams for quality. Each team may use its own tools but the metrics collected could be standardised using Insights and compared across teams.


As an automation platform, self-service was one of our core principles. Our framework is built to be extensible. Tutorials walk users through step-by-step lessons in configuring new types of integrations, adding instances of integrations and configuring automated scheduled tasks.  This makes sense for an automation platform. However, users still need to run the task, fetch data, transform and store it in the JSON format we use for our reports. Since our focus now is insights, there is scope to improve what we mean by self-service. In addition to what we already offer, our APIs could also allow users (who may be concerned about adding credentials into CloudMunch or just not want to worry about automation or scheduling) to just post processed data necessary for an insight card.


CloudMunch is already extremely customizable and allows for extensive fine tuning of its look-and feel by each user. However, features and usability within the application may now need to be tailored specifically for a different type of team. Consider the two example teams we saw earlier. For both, customization and adding new integrations will be useful but key features they’d need would be the ability to customize their dashboards and to be able to export PDF-versions of dashboards (to publish to others without access to CloudMunch).


As an automation platform, the value we provided a customer was obvious and remained largely unchanged over time. With insights, our sustainability in the long-term is a question we need to delve into. The insights we provide are built over APIs made available by other systems. This makes us vulnerable to any changes made to those systems. For instance, several startups which used to provide insights based on data exposed by Twitter APIs are now dead in the water because Twitter changed their APIs. How do we avoid this future ourselves? Another aspect is retaining customer loyalty. As the tools we work with improve, the insights we provide may no longer remain (or seem) valuable. How will our small team remain ahead of and consistently provide more value than these tools?

This is where CloudMunch comes into the picture and takes the pain out of these uncertainties. There are certainly interesting times ahead for us at CloudMunch. Wish us luck!