A Broker Wanted the Delta, Not the Dataset
I thought the product was the dataset.
I’ve been building a small data product around commercial real estate listings: take messy public listings from LoopNet + Crexi, normalize them, deduplicate them, and turn them into a clean market file brokers can actually review.
At first, my mental model was simple:
“People want the clean CSV.”
So I focused on the CSV:
- source links
- broker fields
- pricing/rent status
- cap-rate context
- days-on-market when available
- notes when something is not publicly exposed
That still matters. A lot.
But I had a conversation with a retail broker that shifted the way I think about the product.
He didn’t only ask for another export.
He asked about a workflow where the first run captures all matching places in a geography, and the following runs only show what changed.
New openings.
Temporary closures.
Permanent closures.
Changed status.
New listings.
Removed listings.
Basically: baseline first, delta after.
That made me realize the CSV is not always the end product.
Sometimes the CSV is just the trust layer.
The real product might be:
- a saved market definition
- a recurring run
- stable entity matching
- a change log
- an endpoint that can feed Google Sheets, Postgres, or AppSheet
No dashboard needed yet.
Just: “Here is what changed since the last time you checked.”
That feels like a much stronger workflow than asking users to download the same full dataset again and manually compare rows.
For context, this came from the CRE actor I’m building on Apify:
https://apify.com/kazkn/commercial-real-estate-brokerage-intel?fpr=8fp2od
The current version is still mostly focused on clean LoopNet + Crexi market files.
But this broker conversation made the next direction clearer:
The dataset proves the data is usable.
The delta is what makes it operational.
Curious if other people building data products have hit the same shift.
At what point did your product stop being “give me the data” and become “tell me what changed”?
