Roy Hasson argues that data quality checks often run after bad data has already reached the warehouse, so teams need ways to catch schema changes and stale data earlier.
2
Santona Tuli and Roy Hasson say internal data and ML tools should be treated as products, with defined users, reliability expectations, support, ownership, and feedback mechanisms.
3
The guests recommend building for a specific target audience while keeping platforms extensible through APIs, SDKs, CLIs, and integrations that let users work in familiar ways.
Summary
Roy Hasson and Santona Tuli discuss why data and ML teams need to think like product teams. Roy describes the limits of reactive data tests: by the time a test fails, bad data may already be in the warehouse, dashboards may depend on it, and models may be breaking. He focuses on simple but neglected problems such as detecting schema changes and knowing when a table was last updated. The conversation also covers internal tools. A tool used by two people may become part of a dashboard or support a much larger group, so teams need to consider reliability, data quality, ownership, support, roadmap changes, and user feedback. Santona explains that her role combines product, engineering, data work, and user research. Both guests argue for choosing a clear target audience while allowing other users to connect through APIs, SDKs, or command-line tools. They also caution teams to separate experiments with immature technologies from systems that support the day job.
Data teams need direct contact with the people who consume their outputs
Roy Hasson says data teams often send information downstream without asking consumers whether it meets their needs. That creates the familiar pattern of business teams complaining that data work is too slow while data teams receive little useful feedback. He argues that teams should ask users what is painful, what is missing, and what would make their work easier. Santona Tuli adds that building for data scientists and data engineers requires using tools oneself, a practice they call dogfooding. Working with the product exposes the same friction users face and gives the builders more empathy for those workflows.
A data or ML system becomes a product when it has operating commitments
Roy says calling an internal system a product requires more than putting it on a roadmap. The team needs to decide what infrastructure supports it, what reliability and availability users can expect, who owns the data or model, and what happens when something breaks. Support and change requests also need a process. He gives the example of an internal ML prediction service that starts with two users, then becomes part of dashboards refreshed every ten minutes. Its scale can change quickly, but reliability, quality, ownership, and support still matter even when the initial audience is small.
User feedback is needed for internal tools as well as customer products
Roy says external product teams commonly run surveys, studies, and usage measurement, while internal data teams often rely on emails and informal complaints. Without feedback mechanisms, builders may only know that a tool is being used, not whether people are satisfied or are avoiding it. A poor interface can push users toward unofficial workarounds that the team never sees. Treating internal tools as products means collecting feedback and usage information, then using it to decide whether the tool is useful, what needs to change, and whether it should continue.
A platform should focus on a target user while leaving room for other workflows
Roy recommends choosing a specific audience instead of trying to make one product fit everyone. A data engineering product might focus on moving data, checking its quality, and delivering it to a warehouse such as Snowflake. An ML engineer may prefer reading from Postgres and writing files for a TensorFlow model. The product does not need to make both workflows identical. It should focus its main experience on the target user, then offer APIs, an SDK, a CLI, and integration points so other users can connect the core engine through tools they already know.
Good interfaces support simple users without blocking power users
Santona says teams can build tools that are too complex for ordinary workflows, or tools that are so streamlined that they cannot handle real needs. She prefers products that let users learn the underlying tool and get the result they need, while still offering sensible defaults for people who do not want to configure everything. Roy gives a similar example with a default Kubernetes pod that works for simple cases, alongside configuration options for users who need different resources. Santona also describes this as an 80/20 decision, where the first version should help most users before adding more advanced options.
Data quality needs to be addressed before bad data spreads downstream
Roy explains that Upsolver began as a data pipeline product for moving and transforming data. Customer conversations exposed a larger problem: the pipeline could deliver data successfully while the data itself was still poor. Traditional tests often react after the data has entered a warehouse, after people have relied on it, or after a model has tried to use it. Roy says the goal is to change the outcome by delivering high-quality data reliably. He names schema changes and data freshness as simple problems that repeatedly cause pain. Teams need to know when columns are added, removed, or changed, and when a table was last updated.
Tool sprawl can make small data problems harder to manage
Roy argues that the industry often responds to every data problem with another product. A team may end up managing many vendors and systems to answer questions that should be simple, such as when a table was last updated. He says a vendor should help simplify the end-to-end architecture rather than add more separate components. Demetrios Brinkmann connects this to ML tooling, where products may share several secondary capabilities even when their main value propositions differ. The result is a difficult choice about which tool should handle overlapping functions.
Experimental technologies need a boundary before they enter production work
Roy separates exploring new tools from relying on them for the day job. Teams can experiment freely in research and development, but production systems need mature tools, operating practices, and evidence from companies using them at scale. He warns that most companies do not have a large team available to absorb failures, fix open-source dependencies, or contribute fixes. Santona and Roy also discuss how strong opinions about technologies can become almost religious, with arguments over ETL, ELT, and data modeling. Roy says learning to work through those preferences would have helped him communicate more effectively.
"You need to sort of focus on who is your target audience, what do you need to give them to make their experience the best and allow them to work the fastest and the most convenient way that they know how."Roy Hasson31:18
Who should watch
You own an internal data or ML platform and users complain about reliability, usability, or missing features.
Your team runs data quality tests after ingestion and needs to catch schema changes or stale data earlier.
You are choosing between a simple interface and a flexible developer tool for data engineers, ML engineers, or data scientists.
