The data pipeline that powers the product has been essentially the same since the second iteration. Real-time water quality readings, normalized by ZIP code, with anomaly detection running against historical baselines.
The first four product iterations failed. Not because the data was wrong. Because the product was answering the wrong question.
The question we were actually answering
The question we were answering through the first four iterations: "What does the water quality data show?"
The question users were actually asking: "Is my water safe?"
These seem like they should produce the same answer. They don't.
"What does the water quality data show?" produces pH measurements, turbidity readings, conductivity levels, bacterial indicators, and trend lines. Accurate, technically impressive, and completely meaningless to someone standing at their kitchen tap.
"Is my water safe?" requires knowing what safe means to that specific person, in their specific situation, with their specific concerns. For a new parent, it means: is this water safe for formula? For someone with a dog, it means: can my dog drink this? For someone on a restricted diet, it means: does this water interact with anything I'm managing medically?
The data pipeline couldn't answer "is my water safe?" without knowing what "safe" meant to each person. We had to build that layer.
The five iterations
Iteration 1: Infrastructure intelligence. We built a leak detection product that used operational data to identify potential water main issues before they became emergencies. Technically elegant. Users don't think about water mains. They think about the water that comes out of their tap. Zero emotional resonance.
Iteration 2: Contamination alerts. We pivoted to real-time contamination detection, bacteria, chemicals, regulated compounds. The framing was: we'll tell you when there's a problem before you find out through official channels.
The problem was that we had built the wrong instrument. Formal contamination notification is a public-health function: the utility and the regulator hold it, and they hold it with verification steps, notification duties, and a legal channel for issuing it. We were a consumer engagement product sitting next to the same data. A consumer engagement product is not the right thing to be telling a household to stop drinking its water, and we were not softening an accurate warning to protect our numbers. We were getting out of the way of a warning system that already exists and is obligated to work. What we could add was context around published readings, which is a different job with a different standard of care.
Iteration 3: Lab testing. We positioned the product as a health checkup for water, proactive testing on a schedule, like getting a physical. We added softer language, cleaner design, less alarming terminology.
The problem was speed. Lab results take days. By the time results arrived, the curiosity that prompted someone to request a test had completely dissipated. Engagement rates were near zero.
Iteration 4: Real-time dashboard. We removed the lab testing entirely and built a clean dashboard showing real-time measurements. pH, turbidity, conductivity, updated continuously, displayed clearly.
Beautiful data. Still meaningless to anyone who didn't know what the numbers meant. A pH of 7.2 means something to someone with a chemistry background and nothing to everyone else.
Iteration 5: Personalized context. The version that worked combined real-time data with contextual translation:
- "In your ZIP code's most recent reported samples, no contaminant exceeded its federal legal limit." (Not raw measurements.)
- "Seasonal runoff in your region typically affects turbidity during May-June. Here's what that means for your household." (Not just a turbidity number.)
- "The most recent reported samples for your area show no bacterial indicator above its regulatory action level." (Not the indicator values themselves.)
Two things that output is not, and the product says so on the same screen. It is not a claim about health guidelines, which are stricter than legal limits and are a different argument; every figure is measured against the enforceable legal limit. And it is not a verdict on whether a given household's water is safe, because a sample result for an area is not a statement about a tap. The framing is what makes someone look. The limit is what makes the statement defensible. We do not tell anyone their water is safe for their infant, and no consumer product should.
That was the version that finally worked.
What changed and what didn't
The data pipeline is essentially identical to iteration one. The measurement sources are the same. The update frequency is the same. The anomaly detection logic evolved, but the fundamental architecture is unchanged.
What changed: the translation layer. The system no longer outputs measurements. It outputs meaning.
The translation is personalized by ZIP code, which allows the system to provide context specific to the regional water source, seasonal patterns, and local treatment characteristics. Someone in a rural area with a private well gets different context than someone in an urban area on a municipal system. Same data infrastructure, different output.
The design principle
Every AI system produces some output: a recommendation, a measurement, a prediction, an alert. The assumption most builders make is that output quality is determined by the quality of the underlying model or data.
It's not. Output quality is determined by whether the output is interpretable and actionable by the specific person receiving it.
A pH reading of 7.2 is highly accurate data that most people cannot interpret. "Your water quality is within normal parameters" is lower information density but creates a usable mental model.
The design principle: identify the decision or action the user needs to take, then design the output to support that decision directly. Don't output data that requires the user to apply expertise they don't have.
This sounds obvious. It's consistently the last thing builders think about, because builders have the expertise that users don't. When you understand pH, outputting pH values seems natural. When you don't, when you just want to know if you should give this to your dog, the pH value is noise.
The empathy problem in AI product design
The harder version of this challenge: users often can't tell you what they actually need.
If you ask someone what they want from a water quality product, they'll say: accurate data, real-time updates, easy to use. These are inputs. What they actually need is a clear answer to a specific safety question that maps to their household situation, delivered in terms they don't need to translate.
Getting from "accurate data" to "is this safe for my dog?" requires not just asking users what they want, but observing how they actually behave. Users who requested a test and never opened the results weren't satisfied with the product. They were demonstrating that the product had failed to create urgency. The iteration that finally worked created urgency because it made the safety question concrete and personal.
You find the right framing by building the wrong ones, watching what happens, and pivoting until users actually engage with the product the way you need them to. Five iterations is not unusual. It's the number it takes for some problems.
PurviewX builds AI products that work for real users, not just technically. Start a conversation.