This blog post is Human-Centered Content: Written by humans for humans.

As Solutions Engineers and Architects, our mindset around BI tools and data platforms needs to continuously shift toward treating data and analytics as the product, as opposed to informational outputs for once-off consumption. We are no longer responsible for proposing solutions that solely consider the core pillars of the data ecosystem in isolation. Instead, our solutions must extend to consider the user at every point along the data arc and do so concurrently instead of in a sequential manner.

User considerations at the data layer are just as important as user considerations at the analytics & reporting layer. As two of our analytics engineers pointed out in a recent article:

• “Before a single visualization gets built, you should be asking, ‘What grain(s) of data do I need for the visuals required in this workbook?'” – data engineering layer
• “If the table relies on user input, then do as much engineering upstream and leave the final manipulations that rely on user input within the Workbook” – analytics consulting layer

What Are Data Products?

Before discussing how InterWorks approaches data product development, it is worth grounding ourselves in how we define data products, and the value that they bring.

A data product is the operational layer between your data and your decisions, where users don’t just see data, they shape it.

Through application specific workflows, data products are where your data stops reporting and starts working, closing the gap between insight and action.

dbt Labs, for example, extend this definition by listing the core characteristics of a data product as: discoverable, addressable, trustworthy, self-describing, interoperable, and secure & governed. These characteristics will become increasingly relevant as organizations mature their data product practices.

From Dashboards to Data Applications

The shift from dashboards to data products is more than a technology change that BI tools, such as Sigma, afford the community. This shift represents a change in how we think about what we’re delivering. Dashboards and reports still serve a valuable purpose, but they carry fundamental limitations: They look backwards, they’re built once or rebuilt periodically, and they put the full burden of analysis on the person consuming them.

Consider a simple budgeting analogy. Traditional BI is like recording your expenses each month with the outcome telling you what you spent. Alternatively, a finance tracker that models your previous spend, allocates budgets to categories and runs a health check against your monthly target actively helps you manage your future. One looks at the past, the other helps you act on it.

Additionally, both dashboards and data apps can be visually well-designed. The core differentiating question isn’t how they look, it’s what comes next. Can users act on what they see? Can they complete that action without leaving the tool? And can whatever decisions are made be captured and written back as new, informative data? Hence, data products enable action.

The table below further illustrates how success is measured differently across the two: Dashboard teams track usage, load times and refresh rates, as well as last-viewed statistics, while data product teams focus on active users, feature adoption and drop-off rates at critical flows. These are the metrics that tell you whether something is genuinely being used to fulfill an objective, not just being deployed.

What Are We Building: Dashboard or Data App?

If users are primarily viewing data, a well-built dashboard is often the right fit. At InterWorks, we define a data app as meeting the following four requirements:

• Input: Users are inputting data across various fields
• Logic: Rules and calculations run on that input, transforming it into a desired output
• Views: The outputted data is presented in specific formats, with different screens available to different roles
• Roles: Different users with different jobs in the process (submitter, approver, manager, admin) who hold different permissions with specific functionality

If all four conditions apply, you’re building a data app. If only some do, you may be in dashboard territory, and that’s perfectly valid.

Our Development Approach

What makes data app development at InterWorks different is our process. When we build a data product, the goal isn’t to simply develop and ship something. It’s to build something that is adopted, genuinely usable and results in a satisfying user experience. The outcome is that users should be more informed and be able to complete their objective in the fewest steps possible, without friction.

That doesn’t happen through a single activity at the end of a project. It’s a continuous process that runs both before and throughout development. To accomplish this shift from develop and ship to true adoption, we apply a user-centric approach from start to finish. In practice, this calls for a deeper sense of requirements analysis, a strong consideration for specific user journeys (i.e., how does error handling occur, or, should these modeled scenarios all be written back to the data warehouse or can the user select which ones to save?), carefully thought-out design principles, and a data model that accommodates all of the above.

When applicable, we like to follow a two-phase process, aligning with core elements from Sigma’s BUILD model:

Our process begins tackling the first four elements. This can be achieved with our bespoke design sprint, delivered by a Solutions & Analytics Architect, for example, working alongside your team. Before a single screen is built, our team ensures that we have a comprehensive overview of your requirements, a preliminary write-back architecture designed, and rapid wireframes developed, tested and approved. This is the foundation on which everything else is built.

Concerning the development cycle phase of the model, we follow a dual track approach whereby continuous discovery and development happen in tandem. This approach allows us to evolve alongside Sigma itself, where product functionality and AI-integrations outpace the traditional longer-term roadmap, meaning that a static three-month plan is often obsolete before delivery begins.

Continuous discovery ensures that we are always building to validated requirements that leverage the latest functional availability as well as getting a working product into the hands of users as quickly as possible. Unlike a dashboard that is built, deployed and largely left alone, a data product is versioned and continuously updated: New features, new capabilities and ongoing refinement based on how real users interact with it.

The result is a loop that adapts to changing business requirements in real time, rather than following a rigid path defined months prior, meaning that if any technical or product debt is incurred, we’d only need to refactor or reexamine two weeks’ worth of work as opposed to 3-6 months.

Sigma AI Apps

Sigma AI Apps are purpose-built to close the Analyze → Decide → Act loop alluded to earlier. During Sigma’s 2026 Workflow conference, Greg and Katrina presented their best practices for building AI applications, covering two core frameworks (see here):

• The BUILD model – a mostly pre-build planning framework that we’ve covered in depth here.
• The Analyze → Decide → Act continuum

The Analyze → Decide → Act continuum illustrates one of Sigma’s core advantages. In traditional BI environments, someone analyzes a dataset, surfaces an insight and passes it down the line. If we’re lucky, someone captures the thinking behind the decision and writes it back to the warehouse. But how often do companies actually implement that discipline? With Sigma AI Apps (and specifically their write-back capabilities) all three stages can occur in one place, and critically, the decisions and intelligence generated at the “Act” stage can be written back to the warehouse, preserving tribal knowledge rather than letting it evaporate.

Building Without the Overhead

One of the most common barriers to building data products is the perceived complexity of the infrastructure required. Historically, application development meant separate runtimes, hosting environments, licensing models and security configurations, all sitting apart from where your data actually lives.

Sigma AI Apps change that equation by bringing application development to where your data already lives. You’re building inside an environment where all configurations are already in place. The result is a dramatically lower barrier to entry, with data sourced in real time.

If you’re ready to move from dashboards to data products, or simply want to explore where the right entry point is for your organization, get in touch with us. We’d love to help you image how we might solve your data problems with data apps.