The challenge
Soda provides a powerful set of tools to detect monitor and data quality problems. While the signals Soda produces are valuable, users must still carry complex workflows outside of the Soda platform to understand and resolve the underlying issues.
When a quality check fails, teams have to diagnose the cause, trace impact, find an owner, coordinate in Slack or Teams, open a Jira ticket, change the upstream system, and confirm recovery.
Soda was considering a broader role in that process. In this strategic apporoach, Soda agents could prioritise issues, assemble context, investigate likely causes, and recommend (or take) actions.
Several paths and unknowns remained open. The primary audience could be an executive, a data quality lead, or a data engineer. Priority and value needed credible calculations, automation needed clear limits, and the company had to decide whether Soda would manage resolution or monitor it.
The vision was built out as a working app so participants in user research sessions could respond to the workflows in real time. This high-fidelity artifact also opened the door the for rapid product development once validated.
Making the strategy tangible
I translated the proposal into four connected layers.
- An operational Inbox for issues, access requests, tasks, and policy violations
- Health & Performance views for organisational trends, compliance, impact, and resolution metrics
- An issue workspace covering priority, investigation, resolution, and human approval
- Agent-mesh onboarding to connect data sources, organisational knowledge, and business intelligence
I built the experience in React. Configurable mock data supported each research scenario, so I could run multiple sessions without rebuilding the product between iterations.
The prototype served as a research instrument. Its fidelity made terminology, workflow, automation, metrics, and Soda’s place in the data stack concrete to users. It also gave product a reference for interaction and visual detail.
Testing the vision
I ran ten hour-long interviews with existing Soda customers. Participants included hands-on data practitioners, platform owners, and business leaders.
Each session used the same set of tasks. Participants assessed organisational data health, prioritised issues, investigated an incident, reviewed agent recommendations, and set access boundaries.
The interviews were used to sharpen the requirements for information, action, and control.
Users trusted metrics they could inspect
Participants understood concrete signals like mean time to resolution, failed checks, affected products because they could connect each measure to work. Less tangible scoring like “Value Impact” and composite priority scores were generally seen as less trustworthy, or less useful.
Needs varied by role. Leaders focused on trends, business impact, and comparisons across domains. Operational users looked for the next issue requiring attention. Each group wanted control over filters and views.
Lead with useful, concrete metrics and make them easy to inspect and understand.
The agent had to shorten the work
Participants did see value when the agent completed part of the resolution process.
Useful examples included root-cause summaries, timelines, similar incidents, draft communications, assignment, and PR generation. One participant asked for a “one-button fix.” Known analysis needed to appear in the interface before someone opened a prompt.
The prototype offered a dedicated Soda AI view alongside contextual entry points. Chat could support open-ended work; common tasks needed direct actions in the issue workflow.
Trust required evidence and control
Customers considered AI assistance when they could inspect and control it.
They asked to see the basis for a priority score, the commits and lineage behind a diagnosis, and the status of each agent action. They also wanted override and approval controls. Participants accepted proactive diagnosis and reserved production changes for human approval.
Show the work behind each agent decision. Include reasoning, references, status, and a clear state for proposed, approved, and completed actions.
Deployment requirements shaped adoption. Some customers needed bring-your-own-key support, controlled data access, or self-hosting before they could use the agent.
Redefining Soda’s role
The Kanban workflow exposed a product boundary.
An early prototype organised issues into Found, Under review, and Fixed, with action driven via a familiar Kanban pattern.
Moving a card could not confirm a fix. Resolution required a change to the underlying system followed by a successful rerun of the relevant Soda checks.
Teams already coordinated work in Jira, Slack, Teams, and other systems. Soda’s role was to supply detection, priority, technical context, impact analysis, suggested actions, and verification.
The revised vision defined Soda as a data quality command centre. It would coordinate the resolution process through existing tools and keep the authoritative record of data quality recovery.
Outcome
Research removed several assumptions from the original concept and produced a clearer product direction.
- Group related alerts into issues
- Calculate priority from visible operational and business context
- Show investigation by default
- Place direct actions beside approval controls
- Work through tools teams already use
- Confirm resolution with rerun checks
- Record agent and human decisions
The direction became the focus of a dedicated product initiative. The prototype served as the implementation reference for workflow, information architecture, interaction, and visual detail.