Audit Your Data Before You Build

Most ML plans become real at the data review. A promising use case can quickly change shape when the team sees what has actually been collected, how it was collected, and whether those records represent the conditions where the product must work.

This is an original companion to Part 3 of the AI & PM Insights ML strategy series. The point is to replace assumptions about data with direct evidence.

Inspect the path that produced the data

Data is not just a file or a table. It is the result of a workflow. Ask where it comes from, who created it, what changes over time, and which incentives shaped the process. Those answers often reveal missing cases, inconsistent fields, or biases that a quick schema review will not show.

For robotics and other physical systems, the operating environment matters especially. Weather, lighting, hardware versions, user behavior, and rare failure cases can all change the distribution the model sees.

Test representativeness early

A dataset can be large and still be unhelpful. Review examples with domain experts and look for the moments that matter most to the product decision. Include routine cases, edge cases, and the transitions between them.

Then be explicit about gaps. A gap is not automatically a blocker. It may define the scope of an initial release, a collection plan, or the conditions under which a human remains in the loop.

Make data ownership visible

The team needs a named owner for access, quality, privacy, retention, and the feedback loop after release. Without that ownership, data readiness is often treated as a one-time task rather than a product capability that needs ongoing care.

An honest data audit can narrow a roadmap. That is progress. It gives the team a plan it can execute instead of a promise built on unknowns.