Minimum viable (data) product: how Slido brings a product mindset to analytics engineering
Analytics work often mirrors product development: Identify a user need, build a minimum viable product to address that need, evaluate the impact, and iterate.
For audience interaction platform Slido, a minimum viable data product (MVDP) approach has been crucial to counterbalancing and complementing the standardized approaches of dbt.
Learn how Slido used Deepnote and dbt to accelerate team workflows and build better data products.
Meeting the challenges of creating user-friendly metrics & reporting data
Slido’s mission is to transform how meetings are run. The company provides its more than 860,000 customers with a wide range of tools — from live polls and quizzes to meeting-based analytics — to help drive engagement during meetings, whether in the office, online, or in between.
Michal Koláček, the Head of Analytics Engineering at Slido, is tasked with helping his team empower the wider company and its customers with data. The analytics engineering team — which is part of the broader data organization that is comprised of data engineers, analytics engineers, data analysts, and machine learning engineers — manages 307 data sources, 189 models, 122 dashboards, and two product features.
Michal’s team prioritizes collaboration across the data organization and with end users, and MVDPs are an essential part.
“The core of the MVDP starts with the user — our priority is to make sure we identify and understand the user’s and business’s needs first,” Michal said.
Building quickly and iterating often is critical. If the team tries to build a metric or model without doing so iteratively, the chance of missing something (and thereby wasting time and resources) rises exponentially.
But when it came to transforming metrics into usable reporting data, Michal and his team kept coming up against two challenges:
1. The OLAP cube dilemma
The online analytical processing (OLAP) cube was originally developed as a standardized way to make sure metrics are version-controlled and all in one place. While a normal cube only has three dimensions, OLAP cubes can become more complex as more attributes are added — which is what happened at Slido.
“Eventually, we created a massive, tremendous OLAP cube with 200 metrics and several dimensions that was very complex,” Michal said.
Business users kept wanting more granular information, such as the number of sign-ups in a region, year-over-year growth for a particular city, or a combination of many measures.
“We’d end up pulling a custom query and putting it into a visualization layer — but this doesn’t scale — creating a lack of version control, maintenance, and knowledge of what’s in production,” Michal said.
As a result, the data team became a bottleneck. It was forced to say no to requests more often and had to build upon one-off queries.
2. Fragmented development workflows
As business user requests increased, so did the Slack messages. Michal’s team was inundated with messages asking for specific answers. So it introduced a Slack bot to manage requests, funneling them to a JIRA backlog where they could be centralized and prioritized.
While this solved the intake problem, it didn’t solve for building MVDPs. The process the team followed only brought the business user in at the end of the workflow.
“What we really needed to do was have the business user with us throughout the whole flow, giving us feedback as we go,” Michal said.
Adding collaboration to the creative process
To address the OLAP cube problem, Michal’s team used the dbt Semantic Layer, which makes it easier to define business metrics and support self-service in downstream tools. But it needed a tool that would integrate with the Semantic Layer and facilitate collaboration with business users.
That’s when Slido turned to Deepnote to bridge the gap.
“Since metrics require a lot of input from subject matter experts, data consumers, and business stakeholders to define and align on definitions, we needed a collaborative layer where we could get immediate feedback,” Michal said.
He and his team adopted Deepnote to make it easier to share their work with others.
Learn more about Deepnote’s integration with the dbt Semantic Layer in the video below:
After identifying key metrics from the OLAP cube that it wanted to redefine in the dbt Semantic Layer, the team used Deepnote as an interactive development layer to shape the map. To do this, Michal’s team would:
- Codify metric definitions in the dbt Semantic Layer.
- Build a pipeline to process metrics in production using dbt.
- Create a Deepnote notebook to explore and serve the metrics.
Thanks to its integration with the dbt Semantic Layer, Deepnote has become a comprehensive interface for both developing and sharing metrics.
Delivering long-lasting impact
With this combination of tooling, the analytics engineering team can dive deeper, easily running secondary calculations, such as defining ratios or figuring out year-over-year calculations. It can also run macros and test definitions directly in Deepnote without needing to actually have those definitions start in a dbt project.
But the benefits don’t stop there:
Reduced time to value
Now the team is prototyping against a dbt server, writing code, compiling tests, and debugging all in the same interface. By tightening the feedback loop, the time it takes to fulfill requests has been radically reduced. It’s also removed the need to context switch between different tools.
When someone asks the data team to pull a number, it’s rarely enough to provide a numerical value — an analytics engineer or analyst will want to describe how they defined the metric, provide different options or cuts, or add a visual, comparison, or benchmark metric. By building out data apps on top of its Deepnote notebooks, Michal’s team can create a holistic MVDP without actually having to invest time and effort into building something for production.
With Deepnote, engineers can work on what they're great at, which is empowering teams to self-serve data. Instead of getting bogged down writing custom SQL queries, they get to actually help teams learn how to do it themselves.
Across the company, analysts and business users alike can use and understand data on their own — as well as focus on applying their domain knowledge to the data — instead of chasing it down and trying to decipher it.
Analytics engineering is a team sport — it requires data professionals to collaborate with business stakeholders to make great data products. Running the analytics process within Deepnote ensures that it stays both iterative and collaborative.
When it comes to building metrics and models, Slido has found its incremental process to be very helpful for testing for different stakeholders and their requirements. And when combined with notebooks, analytics engineers have a collaborative, version-controlled system that not only makes data accessible to stakeholders, but also helps analytics teams find focus.
Learn more about Deepnote’s native integration with the dbt Semantic Layer
Share this post