CASE 02 · REZYSAVE
Owning an IoT product, from 20M unclean rows to nine kinds of reader.
The executives came with a high-level styling request. Underneath it sat 20M+ rows across 120+ columns, unorganized and unstandardized, and nine kinds of reader who each needed a different answer out of it.
(TL;DR)
- SITUATION
- A high-level styling request from the executives, and 20M+ rows across 120+ columns underneath it, unorganized and unstandardized, with nine kinds of reader to answer.
- WHAT I DID
- Client-side product owner to a 20+ person offshore team: I standardized the data, built the device naming, inventory and install system, and wrote the direction the build was made against.
- RESULT
- A working dashboard all nine can read, and 1,265 connected devices findable by their code alone across 11 properties and 229 buildings, counted 2026-08-27.
(THE ROLE)
I owned the product from the client side of a 13-hour time difference.
I arrived on a two-month contract with 20M rows and 120 columns to analyse, and inside two months I owned the product for a 20+ person offshore team. I did not design the dashboards. I called the delivery team at five and six in the morning, worked through each page with their design manager, and told them what the system had to know. The job was to hold what nine kinds of reader each needed out of it, and to say so before it got built.
DECISIONStayed the client-side owner rather than the drafting hand, so every screen answered a named reader instead of a preference.
(THE NINE READERS)
- PROPERTY MANAGERS
- ADMINS
- INSTALLERS
- TENANTS
- REGIONAL PROPERTY MANAGERS
- OWNERS
- INSURANCE
- INVENTORY MANAGERS
- INSTALL MANAGERS
(THE FLAW NOBODY ELSE CAUGHT)
Anyone could sign up with any role they wanted. The whole team missed it.
The approved Figma mockups never had a ‘pick a role’ step. Design and dev built the sign-up flow with one anyway: one link to every email, and anyone could claim any role, unchecked, straight up to regional manager. Nobody checked the build against the mockups; I caught it because my job spans design, development, and the client’s business, not just one of them. I drew the flow that closed the gap, sign-up links already resolved to a tenant and unit before they go out, to show the team what to build instead. No role to pick, nothing to approve.
DECISIONHeld QA alongside product ownership, and checked the build against the approved mockups rather than against itself.
Before
the built flow, redrawn: the role-picker the mockups never had
After
the flow I designed and shipped: no role to pick, nothing to approve
The mockups never had ‘pick a role’; the built flow did. I caught the gap and drew the fix.
(THE NAMING, INVENTORY AND INSTALL SYSTEM)
Building an enterprise naming, inventory, and install system.
Every device carries a code that says exactly where it belongs, down to the property, the building, and the unit. The code does three jobs at once: it tracks what exists, it maps each device to its place, and it plans the install in advance, so a crew arrives already knowing what goes where instead of scanning anything in the field.
DECISIONDesigned the naming scheme before the fleet outgrew anyone’s ability to track it by hand.
1,265 CONNECTED DEVICES ACROSS 11 PROPERTIES AND 229 BUILDINGS, COUNTED 2026-08-27
A grammar is only worth what it joins to. Every property, building, unit and device sits in one master table, and every install and every report resolves against it rather than against somebody’s copy.
SCROLL THE DIAGRAM SIDEWAYS TO READ IT →
Planning it in advance is only real at the point where an installer opens the app: the unit and the code are already decided before the phone comes out of the pocket. And a device is not counted as installed until its data has actually sent, which is on the flow above because it is the part everybody wants to skip.
(20M ROWS INTO A WORKING DASHBOARD)
20M rows of unclean data into a working product.
Getting from the one to the other meant sitting with the real schema and standardizing it first: 120+ columns, no standard between them, and one measurement arriving in five different formats. What shipped is a working dashboard all nine kinds of reader can read, each of them getting a different answer out of the same devices.
DECISIONSat with the real 20M-row schema and standardized it before validating a single screen.
A property manager opening the water view is not asking what the portfolio looks like. They are asking whether a leak is running and what it is costing, off the same device stream that fills every other screen. That is the whole point of standardizing it first: nine readers, one stream, nine different answers.
(DIRECTING THE BUILD)
The direction went on the working documents themselves.
Rather than hand over a picture and hope, I annotated the property manager view panel by panel: the renames, the gauge bands, and what each section had to tell its reader. Behind it sat the rest of the direction: the data dictionary every sensor mapped into, the payload each alert had to carry, the mold and water rules, and the master table the whole system joined against.
DECISIONWrote the direction on the working documents themselves, so the team read each requirement next to the thing it applied to.
(WHO MADE WHAT)
Product management mine; the screens were designed by the client-side design team.