When I started my career, I was working with a fast growing B2B SaaS company. They had just started to build out their operations team and I was the first junior analyst hire they made.
We had recently onboarded a spanking new data visualisation tool and I was the first and the only one to lay my hands on it. Revenue teams were excited to get rid of their 500+ excel sheets and move to these really clean looking dashboards which I was going to make for them.
The idea was to help Revenue teams be more data-driven, but did I succeed? We will see..
This is how it all started..
It all started with this one dashboard I made for the senior management to track business performance which included things like funnel conversion rates, sales quota attainment and customer churn details and more. I could roughly fit in about 20 visually appealing charts on that dashboard.
In no time, I observed my Revenue teams getting tempted to fiddle with the dashboards to dig deeper into the data- dashboards acted as a great starting point! However, there were follow-up data-requests from a single dashboard to further understand why things were happening the way they were. These trailing questions were directed to my inbox and suddenly my inbox was flooded with these ‘ad-hoc data requests’ from revenue teams.
Oh that’s simple- just add a lot of custom filters, create custom views and maybe add a few more charts for the FAQs to the same dashboard. I did that.
Soon enough, these ad-hoc data requests started becoming requests to build out separate dashboards for different Revenue teams. The 100+ filters seemed to still not quest their hunger for more data. So here I go making more dashboards..
One for the Sales team
One for the Marketing team
One for Customer Success and
Another one for Finance!
And then soon enough, my slack was flooded with requests from individual team members that looked like this-
Sales Rep:
“Hey Hosh! I really love the Sales Overview dashboard you made for the VP of Sales. Can you make a similar one but only for my leads and also if you could add in a chart showing their lead scores and also my activity on them please? Thanks a tonne! XoXo”
This is how my ‘dashboards-to-do’ list looked like-
One dashboard for Jack from Sales
One for John from Marketing
One for Amy from Sales again
One for Charlie from Finance
Another one for Olivia from Customer Success too!
And then there was this too..
The VP of Customer Success has a meeting with top customers every week… build a dashboard
The Sales Manager has a weekly meeting with his reps…build a dashboard
The CEO has an investor meet next month… build a dashboard.
…
The list goes on.
….
I was busy making one dashboard after another and adding more and more filters to each of them – In my head I was like “Oh wow! see? they’ve already started to become data-driven”.
Were they really though?
Not even close! Let’s understand why?
What was really happening?
The “data requests” started to become redundant and I started wondering if anyone was even looking at the dashboards I kept making.
Let’s see..
I wrote a small code to count the number of page views all my dashboards were getting and started tracking it over a few months.
The result?
An overall average of 5 views MoM for the 50+ dashboards I made. I was shocked! It was disheartening to see each of my nice looking dashboards quickly turning into “trashboards”- It was almost never looked at after the first time I had sent it to them.
It was clear that the dashboards were not efficient, they did not answer the numerous business questions in a repeatable fashion and that’s when I realised that I needed to get to the depth of this problem. One size fits all didn’t make the cut.
So what really happened just after I sent them the dashboard?
What changed? Nothing much!
Typically business users would play around with the filters on the dashboard and end up exporting ‘mini-reports’ over to their Google sheets where they felt more comfortable operating.
A few reasons why?
- Business data requests often have a limited shelf-life. Hence, they only needed what they needed in that instance to get going with a decision
- Dashboards gave them a limited ability to add ever changing business context to explain what they thought the data results actually meant
- Collaboration was challenging on dashboards. Dashboards give them limited ability to collaboratively interact with the data together as a team and chat or question the data
- Google Sheets somehow felt like home..
Context? Lost in transit..
Once the chart/dashboard has been shared, there are trailing conversations that the teams have before they can make a decision. Questions like-
“Hey! Sales are low in January, why do you think so? Did we also receive less demo requests in Jan? Let’s check?”
“Hey the product usage from our free users spiked in March! That’s amazing, maybe the new feature did it or was it something else? Let’s validate?”
The discovery process that starts from a dashboard is completely lost when a dashboard updates or its configuration/logic changes.
Ad hoc analysis is haphazardly recorded among a sea of scratch work in disparate digital ‘rough books’. Conversations around data is where the actual contextual knowledge lies and this knowledge actually accumulates, but is washed away by the Slack/Email firehose.
All the knowledge is lost in transit over multiple channels of communication so the next time they want to look at why did they decided on something, they have to either go through all the emails/slack messages or just repeat the process (well, of creating a new dashboard)!
To ensure our time is spent exploring new avenues rather than tracing old steps is essential. What we learn from data, what we say about it together and eventually what we did with the information that was evaluated is essential to be recorded.
Answers looking for Questions
Once upon a time, an early human living in the northern pole channeled his curiosity about how to keep himself warm in the cold, harsh environment he was living in. The purest form of ingenuity led him to figure out how to start a fire. The curiosity started with a question in the context of the environment he was living in at that point in time.
Imagine, what if the fire already existed for an early human living in the Sahara desert (totally different environment) and somehow he came upto it. He would most probably try to question the fire’s existence forever, run away from it or at worst try to play with fire and maybe burn himself.
Okay, not the right analogy but dashboards are the later. A single dashboard might answer questions for some users in that point in time and not for some or many.
Dashboards are answers looking for the right questions instead of the other way round. The ‘right questions’ are very contextual on its current environment, business environments keep changing, so will the questions and the process to answer them. One size fits all doesn’t make the cut.
Hey Dashboard! You look cool, but can I trust you?
“Something is fishy, can I trust this data?”
The next thing we check is-
“Who built it?”
“Did it change recently?
“hmmm, it somehow doesn’t look right? “
“How is this number calculated?”
“Why did we choose this logic?”
“Oh maybe it’s still referring to the ‘new_arr’ field we discontinued using from last week”
If there are trust issues, the dashboard is already in the process of being sentenced to death! This leads to a series of investigations between revenue and data teams to find out the proof for it’s innocence (or not). The investigations are majorly an endless chase across countless tools, spreadsheets and emails to prove the business logic leading up to that number.
Typically, the convicted dashboard is given one more chance where the data teams present the business logic behind those charts. These proceedings take time, a lot of time and happen over meetings, emails, slack messages, phone calls (again, all lost in transit and nearly impossible to trace back). If the business logic, which was once valid is no longer valid in the changing business context- the poor dashboard is beheaded with a sharp edged sword called ‘irrelevance’.
Often, the amount of time teams take to verify if the number is right is far more than the time they take to debate what data-driven business decision to make.
That’s when I realised that we had serious trust issues – some of the major reasons-
Dashboards offered very little freedom to view the complex underlying business logic (i.e code) that was used to show a chart, every person has a different definition of what the metrics should mean and sometimes they just didn’t trust the data entered in their CRMs (this is a separate problem in itself).
These trust issues did not allow teams to take real action with this data.
Sigh… So I failed my job to make my teams really ‘data-driven’.
BUT, there is a revolution coming up in the data world which is going to change things for good!
The Future of Analytics- An Experience
Modern teams ‘self-organize’ first in a way they are best able to consume information and then collaborate within their own circles of trusted humans to validate decisions.
Notion, Google Docs, Slack, Figma are all modern tools that create seamless experiential layers to allow humans to organize information in their own way and collaborate to gain consensus (e.g. polls), enable majority voting (e.g. upvotes), make autocratic decisions and ask for consent (e.g. approval processes).
However, all these methods require an ability to understand, share context and adopt one method over another with awareness!
To enable self-organizing teams to make decisions effectively and efficiently, they must deal with decisions not as “moments,” but as “processes”.
Processes are mostly a series of logical questions, the output of one process/question often is the input to the consequent process.
Decision making processes evolve and mature with changing environments or context (that acts as one of the major controlling variable). If you observe how the brain works you will notice that decision-making process often happens in portrait mode in our minds, one step leading to another in a logical fashion.
The most common mistake is to choose an approach and use it in every situation.
The ‘one size fits all’ approach to consuming data (dashboards) has been hindering teams to be an important part in the value chain of making meaningful business decisions.
Consumers of data should never have to fully leave one system and start over in another.
We need a modern experience on the data consumption layer.
The modern consumption layer must enable both, Revenue teams and Data teams to come together on one page from day 0.
One page that enables..
- to have the power and flexibility to answer data & business questions together by letting anyone connect to various data stores and query them through drag-and-drops (Revenue teams) and/or code (data teams).
- for everyone to trust the process by letting everyone see the business logic/code and the author’s commentary.
- a way to collaborate on, present, gain approval and/or consensus and share these insights with a wider audience to validate decisions.
- a way to track the process by letting them store and retrieve the data, conversations around data and the context around decisions made on one single page
Modern Revenue teams today are wildly adopting to tools like Notion, Slack or Google Docs for their daily collaboration needs amongst them where as Jupyter notebooks is now a go-to tool for modern data teams to collaborate amongst their community of trusted data wizards.
Whether they are embeds of a data-frame from Jupyter notebooks or screenshots from dashboards from BI tools, information is often cross-pollinated on either of these systems for the last mile of data-driven decision-making to take place. The need for both of these teams to talk to each other scream for a need for one place where both feel like home!
Today, these note-book style solutions are siloed to be used within Revenue and/or Data communities separately- the benefits of which are focussed on product-led collaboration which is driving their rapid adoption.
These are strong enough signs for a new paradigm shift to take place by making an attempt to bring both data and revenue teams come together, operate and help each other make decisions, all on one page.
Airbook – A Home for Revenue & Data Teams
Revenue Teams
Today, the modern revenue tech stack is saturated causing fatigue amongst revenue teams when it comes to the number of new tools they need to adopt to.
Reporting on these tools is complex and requires hours and hours of onboarding and training. Every tool has a different semantic layer that is technical enough and almost always ends up being used by an ‘admin’ to generate reports for business teams. This often introduces bottlenecks and frustrations when it comes to delivering insights to decision-makers who are non-technical.
Insights from different revenue tools need to be un-siloed in a way that non-technical teams can operate and derive their own insights from different tools all in one place without having to go back and forth with admins or data teams.
Airbook is ‘notion-like’ that lets you connect to any tool existing in your tech stack and lets you derive custom data insights all on one page.
Data Teams
One page that brings data teams closer to revenue teams as well. Insights that are sophisticated to derive and require writing SQL to various data warehouses such as BigQuery or Snowflake happen either in BI tools such as Looker or BI notebooks today. A familiar SQL IDE for data wizards to write SQL allowing them to break down analysis into re-usable SQL logic blocks and add their commentary is essential.
No Trust Issues
Encapsulating business logic into data movement and presentation is a critical part of a stable information management strategy. Too often, though, business logic is abstracted or is built and added late in the process making it difficult to build trust in the data presented.
An ability to show the underlying business logic (SQL) and the source from where the data has been extracted is essential to build trust amongst revenue teams.
Following parameters are essential to be shown:
- The fields used
- Source of the data
- Calculated metrics and their formulae, if any
- Underlying raw data
- Author’s commentary on what this data means
- SQL code
Built for Collaboration
What we learn from data, what we say about it together and eventually what we did with the information that was evaluated is essential to be recorded in a way that it can be shared and tracked.
You can share Airbooks with a teammate, your whole team, the entire company, or to anyone with a link. Add comments and call-outs to make it truly a shared document.
Conclusion
As we’ve been building Airbook we’ve been interviewing a number of organizations to see how notebooks change the way data is used amongst teams. Here’s what we’ve found-
Notebooks in general make information consumable by everyone, in one single place. Thereby, trust issues start to improve since they are viewable (and interpretable) by anyone so no one dismisses the numbers on the basis of not knowing where they came from. Moreover, these reports are full of author’s commentary to help guide readers on how to interpret the numbers and any considerations to take.
They aren’t creating dashboards for people who won’t use them, or thousands of filters to accommodate every need since people have more power to create the reports they really need.
Today, notebooks exist within Revenue & Data teams in a siloed fashion. Airbook is one home built for data and revenue teams to come together and drive the last mile of analytics together!
Leave a Reply