Listen on
Inconsistent metric definitions erode trust in data, leading to stalled decisions and misaligned strategies. Imagine 16 different versions of ‘customer lifetime value’ or ‘monthly recurring revenue’ floating through your organization—each dashboard telling a slightly different story, making strategic alignment impossible. This isn’t just an annoyance; it directly impacts competitive advantage and operational efficiency.
Data leaders and executives face the challenge of democratizing data access while maintaining a single, trustworthy source of truth. Carlos Aguilar, CEO of Hashboard, offers a clear approach to this problem through semantic business intelligence. His company built a BI tool that ensures every critical business metric has one definitive calculation, understood and explorable by anyone.
In this episode, Carlos details Hashboard’s unique metric centralization, its intuitive explore workflow for business users, and the strong developer tools that integrate BI into modern data engineering practices. He also shares how Hashboard scales from small teams to large enterprises, offering critical governance features like version control and automatic archiving to keep data reliable and relevant.
Key Takeaways
Centralized Metric Definitions Eliminate Data Discrepancy
Organizations frequently suffer from multiple, conflicting definitions of key business metrics like ‘revenue’ or ‘patient.’ Hashboard addresses this by enforcing a single, authoritative definition for each metric across the entire platform. This centralization ensures consistent reporting and decision-making, preventing the ‘16 versions of a metric’ problem that plagues many businesses.
Empower Business Users with Guided Exploration, Not Just Static Dashboards
Traditional BI often limits non-technical users to pre-built dashboards with limited filters, leading to constant requests for new views. Hashboard provides an ‘explore’ workflow with smart defaults and intuitive controls, allowing executives and operational users to answer their own follow-up questions without writing SQL. This shifts the data team’s focus from report generation to metric definition and data quality.
Strategic Governance Requires Active Curation, Beyond Role-Based Permissions
As self-service BI grows, so does the risk of data chaos and untrustworthy reports. Hashboard implements governance features like verification workflows, ownership assignments, and even auto-archiving for unused dashboards. This proactive approach ensures that users always know which metrics and reports are officially sanctioned, maintaining data integrity and clarity.
BI Systems Must Bridge Code-First Engineering and Click-Based Analytics
Data engineers need code-based workflows for version control and continuous integration, while business users need intuitive interfaces. Hashboard’s Git-oriented architecture supports both. Engineers can define metrics and dashboards in code, integrating with tools like DBT, while business users explore data through point-and-click. This duality enables organizations to scale BI development efficiently without sacrificing user accessibility.
Related: CorrDyn provides business intelligence services to ensure data-driven decision-making. We also assist with data quality and data reliability to build trust in your metrics. If you need help structuring your data for BI, explore our data engineering services.
Full Transcript
Jason: Welcome to Data BS, a show dedicated to tackling the big questions impacting the world of data and AI without any of the BS. My name’s James Winegar. Each week I sit down with guests from across the data ecosystem to unpack how they’re shaping their businesses or the businesses of others through their real world application of data engineering, ML AI, infrastructure, analytics, and more. No fluff, unfiltered, but slightly edited to remove noise, this is Data BS, let’s get into it.
James Winegar: All right, Carlos, tell me who you are and what you do.
Carlos Aguilar: I’m Carlos Aguilar. I am the founder of Hashboard. That’s who I am and what I do.
James Winegar: So what is Hashboard?
Carlos Aguilar: Hashboard is a semantic business intelligence tool, which means it’s a system for cataloging and creating the metrics that drive your business and letting everybody in your organization explore those metrics and answer their own questions.
James Winegar: Why a semantic BI tool?
Carlos Aguilar: There’s a couple of different workflows that analysts and data engineers and the broader audience of analytics within an organization can adapt. There’s the old mode, which is you have a bunch of dashboard builders, and every time you have a question, somebody submits a ticket to the dashboard builders and they build a dashboard. Maybe there’s one filter on that dashboard or a couple filters on that dashboard. But ultimately it’s hard to interrogate those answers, it’s hard for people in the broader organization to answer their own questions unless they know how to code or write some SQL. There’s a lot of different workflows, so there’s a lot of places where the culture is everybody’s going to write SQL and get an answer. That’s totally fine. My background is in healthcare and supply chain, and those people were not learning SQL, and data was really important. So the whole workflow behind semantic BI, and we’re not the only semantic BI tool. There’s others, things like Looker are popular examples. But especially in a digital native type of company where everything is based on data and you have a lot of people that don’t know how to code, it’s really helpful to have a workflow where you can systematically create concepts. I was at Flatiron Health before, so defining things like patients or clinical trial patients, patients activating into a clinical trial or joining a clinical trial, being screened for a clinical trial, defining all those concepts systematically, that’s the quote-unquote semantic part. And then providing those to the organization so that they can consume them, they can mix and match and filter however they want and answer both their day-to-day questions operationally and their longer-term questions strategically.
James Winegar: One of the things that I think about here is semantic versus the dashboard builder workflow. If you have the dashboard builder workflow, you end up with the definition of what is a patient? Which, if people have worked in healthcare, is a really hard question to answer sometimes. Or a visit or an appointment or whatever, and you end up with 16 versions of that metric. Then somebody pulls up whatever their favorite dashboard is that got built for them six years ago that has an older version of what the definition of a patient is that has been updated blah, blah, blah, and then suddenly they’re making decisions based off of something that really isn’t directionally correct and might have been good at the time but six years later drifted from what that organization thinks of as a patient. So the two things we really talked about there are the ability to define those metrics and then the ability to leverage those metrics to actually manage your workflow. We use Hashboard as well, so I really like the fact that we can enable an explore-based workflow for regular users who have low code skills but are data savvy enough to get some counts and bar chart type of thing and help answer the questions that they need, like what patients should be in the clinical trial. So let’s start with metrics because that defines how to do explore, and then we’ll get into the explore workflow. Could you explain how Hashboard’s metric trees help ensure this single source of truth for definition of the business?
Carlos Aguilar: Absolutely. One of the key problems that we’re solving is that in a typical scaled organization, you have a lot of different sources of truth for how the company is performing. Even if you have another semantic BI tool like Looker, you might still have 20 versions of a metric in different dashboards because Looker has a concept of data models and things they call explores which are very organized and have different concepts, but then you can have different explores. One of our unique innovations, which to us feels pretty obvious, is that we have a centralized concept of a metric. You have data models, so you can represent sales and patients and things as concepts, but then you put a line in the sand and you say, this is the specific calculation of how we want to look at revenue. There is a centralized page with all of the metrics for the entire organization and there’s literally exactly one place where you can put that metric. That metric will define things like filters, it will define things like a time grain, so we want to look at monthly active users, not just active users and cut it in any different way. It’s a workflow for the organization to be able to define a set of key performance indicators and attach metadata. You can attach goals, you can attach owners, and because this is all tied into our semantic layer, you can click in and immediately start exploring that data, and if you see a metric drop, you can start interrogating why that happened. Metric trees are another layer — it’s an opt-in feature where you can start organizing your metrics into a folder-like structure, but the concept is really to build a tree around a hierarchy of goals around your business. Typically what you’re trying to do is create a single North Star metric, typically something that goes up or a count of something that is going up and to the right, hopefully not just money. Your organization does not exist just to create money. It exists to — if you’re Facebook, to connect the world’s population, or whatever it is, if you’re Hashboard, to share insights. So you want to be driving the creation of insights. You have this one North Star metric and everybody should be aligned around driving this North Star metric. The question is, in a large scaled organization, how are random people in random parts of the organization driving this North Star metric? A metric tree allows you to create a formula where you’re effectively bringing all the constituent parts of driving this North Star metric. If you’re trying to connect the world’s population, maybe there’s five business divisions and they’re all contributing some percentage to that North Star metric. Those five sub-metrics become a child of this North Star metric. Within that, there’s going to be maybe three or four driver metrics. Again, it’s going to be some formula. Within this, we’re doing paid search to try to get some inbound folks so that we can grow this North Star metric — that’s the growth team. The product team is trying to maintain retention and there is some formula for how the product team is actually driving this North Star metric. This hierarchy within Hashboard allows you to define a formula that defines how every single last team is contributing to this mission and to this overall goal that the business is driving. It’s a little bit aspirational. Can every company do this? No, and is it always going to be data that’s readily available? Not necessarily, but you should try to systematize it as much as possible.
James Winegar: The biggest thing I see, just to bring it back to money because it’s sometimes easy to talk about compared to product metrics, is that the definition of revenue is different in different parts of the business. If you have a large capital expenditure because you’re a CPG organization, maybe you have a lot of R&D for certain product lines or brands, but then you don’t really have R&D for, let’s just say, Kleenex. It is the thing it is and it’s been the same thing roughly for 100 years. How they split out and come up with what their overall revenue is might be slightly different between these different business units and different regulatory things that they might have to deal with, or maybe they’re in different parts of the world and there’s different tax allocations and things like that if you split it out by geography. There’s a bunch of different ways that you want to roll it up to the revenue metric, which is honestly really hard to talk about for a large organization. So we have these metric trees or just metrics. Either way, because Hashboard’s semantic, it’s supporting metrics. And then we’re able to do exploration on top of that. Take a metric, active users, and then being able to split it out by various things. Can you talk a little bit more about the explore workflow within Hashboard and why you think it’s differentiated or valuable?
Carlos Aguilar: The motivation for starting Hashboard in the first place was I was running a data team. I was VP of Data Insights at Flatiron Health and managing a lot of different data assets that were going to dozens of different teams and being built into dozens of different products. My observation about visualization tools is that you have a lot of different diverse stakeholders. The whole point of business intelligence is that you’re aligning the whole organization, and different people have dramatically different expectations. You have technical people who are trying to manage it, and their normal toolset is code. They want to do things in continuous integration and they have all their tools that they’re used to using. And then the BI tool looks different. Then folks outside of the data team, they don’t care about that codebase stuff. They want easy insights, they want to be able to answer their own questions, or some folks aren’t even that curious to answer their own questions. They just want to check a number and they want to make sure that it’s reliable and trustworthy. The original motivation was looking at these tools and realizing that the codebase folks didn’t have the workflows that they loved. I spent a lot of time teaching people about data visualization and analytics, and it felt like the tools weren’t teaching people how to think about data. After teaching a lot of people Tableau and how to build dashboards and about data visualization and SQL and all these things and trying to activate people and get people to insights, I just noticed some basic patterns of how people should approach data. I had a very systematic way that I would tell people to build dashboards, which is start tracking things over time, pick your key metrics, break it down by the key drivers, break it down by a couple key attributes. I had literally this template. I wrote this up in a blog too, how to build dashboards and BI for data engineers, because oftentimes data engineers might be amazing at pipelines but they’re actually not that good at visualization. I had a very gentle way of introducing data visualization to people where you couldn’t actually get a wrong answer. If you just say start with a good dataset, which honestly is oftentimes the hardest part, you start with a good dataset and the intuition is start tracking the key things over time, break it down by the key attributes and look at the distributions. It’s the fundamentals of exploratory data analysis. That’s the intuition that we built the data explorer on — it just does that workflow. It does it for free and it does it every time. You model the data, the data is clean, that’s your job as the data team, and once you do that, Hashboard picks it up and has an automatic way of representing data that is the way that you should start visualizing it and finding insights. It’s time series by default, time series oriented, but you can change to pivot tables. The whole idea behind the workflow is having smart defaults — the thing you should start looking at, but a lot of flexibility, so you can pivot into whatever multi-chart trellis version of calculations you want, but you start with something simple, a gentle introduction into the dataset.
James Winegar: This is totally an aside right now, but one of the things I run into a lot — our customers typically are a little bit smaller, they do not have a data team. A lot of the work that we do is data literacy and how to take advantage of their data. Are you even able to ask the questions that you want to ask? Because they’re not really at that point yet. One of the things we run into a lot is they have their database that runs some application or vendor tool or ERP. And then they’re trying to answer questions over time like you’re talking about — new user activation, campaign, whatever, pick your poison. Sometimes you can’t answer those questions from the transactional database because you don’t actually have what happened with an order or what happened with a user. You just have what is the current state. The data engineer’s team or the data team or whoever is also there to help support getting to that slowly changing dimension version of the table so that you could provide that out to the users. But now, because you have metrics defined in Hashboard that can leverage the fact that they have this slowly changing dimension table, they don’t have to think about it from that viewpoint anymore — your operational user or your executive user. They just go, here’s the metric that I care about. It’s already handled by the data team, all these technical details, and now I want to split that out by — you have a bunch of pizza store demos — I can split that out by which location or which provider or which nurse or what person in the warehouse did the packing and see what happened over time across those different users or dimensions. I think it’s really powerful to take away having to ask questions about the technical details. People don’t have to think about it to bring it forward. Do you think that Hashboard’s solving that problem in the smaller market? I know you’re moving more mid-market.
Carlos Aguilar: We’re trying to take a little bit of that complexity away. That’s exactly right and it’s really about picking those defaults. You mentioned tracking things over time. Why does Hashboard use that as the foundation, why is it that by default? It’s because usually the things that you want to set up as an actual tool you want to operationalize and things that are operationally interesting are changing over time by definition. It’s not a survey result that you want to look at a single time. You might want to do that, but that’s not something that you’re going to be checking every day. The things that you’re checking every day, naturally you want to look at differences over time. So just anchoring on that time series and making it feel more like a consumer type of experience where you’re just looking at your metrics, exploring those, and able to find trends in those without thinking about the technical architecture or the transactional database and all the work that went into it. We think of it as a curated place where people like you, James, who are spending a lot of time organizing data can show off what they’ve built in a really clean and organized way.
James Winegar: I’m going to compare it to Tableau for a second. With Tableau, I never would have dreamed of providing a truly exploratory — give the ability to a CEO to go and change not the filters but group-bys and things like that, and then expose 20 different filters to them to be able to do what they need to do. Because in Tableau, you lose the ability to manage the dashboard when you do that, whereas at least in Hashboard, I’m really seeing a strong workflow there, and one of our clients’ CEOs is actively using it now. I think it’s really powerful, that workflow that any end user can take advantage of. Honestly that gets rid of so many requests as well. These little dinky, oh, I just want to change this event filter, or when I change this event filter, I also want to look at it from some other category, and that changes — maybe that’s semantically a little bit different — and giving those users the ability, whether they’re operational or executive or even data team, to be able to answer the questions, I think is really powerful. Hashboard, I think, is a really nice tool, and why? Because not only do you have this nice user workflow but you also have a nice developer workflow that ties into it, which usually people have picked either side of that coin and left the other one faint. But I think you’ve tied those together really nicely. Let’s talk about the version control for Hashboard. By doing explore, how does that come into version control trying to manage the BI from a code-driven workflow?
Carlos Aguilar: The vision here is that you have data pipelines, maybe they’re in dbt, at scale or at any moderately sized organization, you’re going to have data pipelines, probably checked into code somewhere, and you’re making changes, you’re adding new business lines, things are changing over time. It’s really painful when you’re making those changes to coordinate it with the business intelligence tool. If it isn’t codebase at all, then probably what you do is you have to set up some really sophisticated staging environment, or you just deploy the thing to production and watch stuff break and try to coordinate and time changes. What we’ve been trying to imagine is, what’s a world where you can actually hook things up end-to-end and run them in continuous integration? You’re proposing changes to your data pipelines, you can also propose codebase changes to your dashboards at the same time. The hard thing about doing this, and this is your point, is usually you have to either make the whole tool entirely codebase. I think of tools like Evidence — it’s a cool dashboarding tool which is almost entirely codebase. The people who are finding the insights, the people who are building every chart are doing it in pure code. That’s one approach and that’s a relatively easy thing that you can do, just write code for the entirety of your analytics process. It’s not really achievable for a lot of organizations. I honestly think the best thing about BI tools and visualization tools is that they’re clicky and you can explore and build your own charts and do your own thing. The question is, how do you mix these two workflows? What Hashboard has is that our actual underlying data structure has a Git-oriented architecture where we track every change as a set of differences. Even as an end-user, as you’re clicking around, we have this history of everything that’s ever happened in the tool. What this architecture allows us to do is a lot of things. It allows you to revert to previous points in history, you can see an audit log of everything that’s ever happened in the project, you can easily fork it. If you want, you can create what we call a project draft, which means you take the entire BI tool, create your own sandbox and can start playing around and propose changes to the data team, which is almost like a codebase workflow. What this architecture allows us to do is represent every single resource either as code or with point-and-click workflows. Every dashboard has a codebase representation and it also has a way of editing with point-and-click. In practice, the way people use this and interact with this is — if you want to never really use code and just point-and-click the entire time, that’s always an option. But as soon as you’re sophisticated enough or have gotten to the point where change management and coordinating things with code is now difficult, what you can do is take those important data models, those important dashboards, check them in, lock them down, and now they can only be deployed with code. We have a command-line interface for engineers which can be run in continuous integration, it can also be run for development, and if you’re using dbt, we have a tie-in with dbt too. That’s also an optional integration, so if you want to do codebase workflows without dbt, that’s also an option. A lot of flexibility in those workflows. People really love this workflow. We have more and more customers that are coming in purely for the codebase workflow and that’s also awesome to see, and the developer experience is pretty delightful. You build your dbt models, you build those models with a command-line tool, with a single command you build those right into Hashboard as your semantic layer. You’re deploying dbt as your semantic layer and there isn’t duplication of effort. Probably the nicest thing about all these workflows is business users never really have to know about them, and they’re all optional and opt-in. One of the other principles for these sophisticated BI tools — Looker says that it’s not really for small teams. Looker is for 100-plus person companies. Hashboard really scales to zero. You can start with this more sophisticated tool and opt in to these sophisticated features when it makes sense for your organization.
James Winegar: The scale-to-zero is a really interesting aspect of Hashboard to me because it has all the tooling to support a larger organization, but the way everything’s hooked in allows you to — I can have an analyst on a very small client and they just do that work within Hashboard and that just happens point-and-click at that point. Okay, now we’re at a more mature client, maybe they have their own data engineering team, maybe we’re helping with some other project. We’re going to have some mixed work there most likely, where a lot of analyst work is happening within Hashboard point-and-click style but dbt is driving a semantic layer. Then, like you were talking about, lock down the whole thing, pushes to production have to go through CI/CD, there’s a separate staging environment — all these life cycle management capabilities that you do as best practices for the code workflow, but now you can bring it to the data workflow as well. The fact that it’s opt-in at every stage is a really powerful story about Hashboard as a tool and how it scales with an organization. It’s a tool that you can start with. You don’t have to start with Power BI or Tableau because your initial cost for Power BI is 10 bucks a month. You don’t have to go deploy your own Metabase. You just go, hey, I’m going to sign up for Hashboard. Okay, cool, we’re working, we’re working, year goes by, suddenly you’re a 100-person company because you got product-market fit. Boom, okay, let’s just take Hashboard and improve the workflow. Because Hashboard has all the hooks, we’re good to go to continue to evolve our processes. I don’t have to change tool, I just have to change process. Which is a little bit easier, not a lot easier, but a little bit easier. There’s two things that you talked about with this version control that made me think about your larger organizations. When you’re talking about you have all these diffs that you’re tracking every single change across, and you’re able to create an audit log of things like that across every dashboard or exploration or metric or pick your poison, what’s Hashboard’s approach to maintaining and managing governance across the platform?
Carlos Aguilar: It’s a really important question because we’re trying to strike this balance of something that’s really accessible and anybody can go in and explore and create stuff and create dashboards, but then the core problem we’re trying to solve is multiple sources of truth. That’s actually the thing that ties that story together — governance. We’ve seen over the last decade as self-service has become more of a trend in the data space, and you have tools like Looker or Sigma or others that are just everybody getting into the data and creating resources, what you see is a dramatic increase in the number of users and — because those users need more data sources — a dramatic increase in the number of data sources that have to be put into the tool in order to support those users. And then all those people creating a bunch of stuff. All of a sudden you have the same problem where it’s, which is the right version of stuff even though you have this self-service environment. We try to have some of that. Obviously everything’s role-based, but our defaults are that things are pretty permissive. People can come in and start creating stuff. So what are the tools that we give people so that that doesn’t just become chaos? We have a lot of governance tools. We have a verification workflow, so you can verify which resources are actually right and real. We have assignees, so you can assign or say that the data team and the data team assigned workflows are the real dashboards that you should be looking at. You can set the defaults for which things are actually visible in the project. If you want only verified resources to be visible, you can set that as the default for each of those pages, so only verified metrics are available. We have things like drafting, which I brought up already, where maybe you actually don’t want to give everybody access to create dashboards. You lock that down and create a workflow where people have to create a draft and send it to the data team in order to publish that dashboard into production. There’s a lot that this empowers. I mentioned it before, but being able to restore to different points in history, that’s a really strong governance feature as well. My personal favorite, which I think we’re the only BI tool or visualization tool that does this, is auto-archive. The challenge with dashboards often is that they have a one-time utility. There’s a product launch and you create a dashboard just for the product launch. But then that dashboard lives in perpetuity even though it had an implicit expiration date. We have an auto-archive feature — the default behavior, and it’s very configurable, is it takes every resource that is not verified, that has not been looked at in the last month, and it puts it in the trash. You can restore it, but it puts it in the trash. It just naturally keeps a project clean over time. We’re trying to strike a balance. It’s a lot of work to deploy these features, but ultimately the approach is governed and curated. Let everybody explore and do a bunch of stuff and put this governance layer on top of it that allows you to know what the right things are at any given time.
James Winegar: One of the things I’ve been thinking about with Hashboard is, how do you actually manage the complexity of allowing these different hook-ins for everybody? Maybe not a topic for right now, but it’s something that I go, man, this is really complicated to build a tool that does this kind of opt-in across the board functionality. We’ve talked about how Hashboard allows scaling from really small organizations up to mid-sized organizations, and also supporting very large organizations with this deferral-based workflow. Where is Hashboard sitting in the market right now in terms of their biggest successes, and where do you think you’re going to be going over the next three, six months?
Carlos Aguilar: As a startup the inclination is to sell into other really small startups, and in BI there’s so much to build that that’s the inclination. What we’ve found honestly is that we’re a little bit upmarket. We succeed best when there is a data team, when you have more problems around sources of truth. When you’re really small, just write a simple SQL query and maybe that’ll make do. We do sell to organizations that size, but where the value proposition is really strong is when you start having really messy data and you need a place to centralize that logic. We see the best fit in the mid-market organizations between 100 and 1,000 employees today. We do see a lot of appetite for continuous integration and these codebase practices far upmarket from that, but that’s where we really see success today.
James Winegar: Hopefully we’ll go upmarket into the enterprise where the margins are better and then be able to grow the team a little bit more. On the point of growing the team, is Hashboard currently hiring?
Carlos Aguilar: Engineers and sellers — account executives — so we’re growing our sales org, and our first full-time marketer we’re also looking for. Mostly in New York. We are a little bit flexible, but we have an office based in New York in SoHo and we come in every day, so we do have that culture. Looking for sales folks with some data experience, and then software engineers — we’re always mostly flexible and looking for great folks, but probably a slight bias towards application and principal front-end folks right now.
James Winegar: Very cool. Where can people find out more about Hashboard and Carlos?
Carlos Aguilar: Hashboard.com for just our blog and our latest. Follow us on LinkedIn, we’re HashboardHQ on LinkedIn if people actually use those handles to find things. HashboardHQ on Twitter as well to follow our updates.
James Winegar: Awesome. Well, it’s great to talk to you, Carlos. I really appreciate it. Hope you have a good one.
Carlos Aguilar: Thanks for having me on.
Jason: That’s it for this episode of Data BS. If you enjoyed this episode, make sure you subscribe wherever you listen to your podcasts to not miss the next one. This episode was sponsored by CorrDyn, a data consultancy that helps organizations unlock the power of their data. If you have a data challenge, we can help. Visit corrdyn.com, C-O-R-D-Y-N dot com, to learn more. See you next time.
