Nikith Vijay

V1 SHIPPED N-Smart · US electric utilities · case study

The layer under the smart layer

Overview

N-Smart tracks what a US electric utility owns — poles in the field, tools in a truck, stock in a warehouse. I ran product on V1: the version that had to model all of it correctly before anything clever could sit on top.

My role

Product management. User stories, systems thinking, the full UI/UX flows and wireframes. The visual design was a different agency's work, not mine.

Team

MeGANSDS

Worked in

Figma

Figma — flows, wireframes, specs

Timeline

4 months
Apr – Jul 2025

n-smart · V1 N-Smart V1 roll-up dashboard — poles, tools and inventory alert counts above one live map of Washington DC

Impact overview

Marketing to product

We'd run their social media for three years. I used that to argue my way into the product work — my first PM engagement, and Ganesh's.

One model, three pillars

Poles, tools and inventory under a single structure — a truck modelled as a warehouse that moves, so nothing needed a second system.

Honest about the seam

I did the flows. Another agency did the pixels. The AI layer their site sells today came after me. This page covers my part.

Utilities can't fix what they can't find

An electric utility in the US owns an enormous amount of physical stuff spread across a lot of ground. Poles — wooden, steel, concrete — standing in weather. Calibrated test equipment worth thousands a unit, living in trucks. Warehouses of parts feeding crews who are rarely in them.

The failure mode isn't dramatic. It's a thermal imager nobody can locate, so a second one gets bought. It's a multimeter used for six months past its calibration date, so every reading it produced is now questionable. It's a leaning pole that was fine at the last inspection and won't be looked at again for a year.

N-Smart's answer was sensors — but a sensor is only as useful as the model underneath it. A tilt reading means nothing if you can't say which feeder the pole is on, who is responsible for that feeder, and which crew has the tools to go fix it. That model was V1, and that was my job.

How an agency that ran their Instagram ended up running their product

We had been N-Smart's social media agency for about three years. Three years of writing about grid modernisation, pole sensors and utility operations to sell someone else's product — which is an unglamorous but genuinely effective way to learn a domain. I wanted to move into product, so I pitched them. They said yes. Ganesh and I took it on together; I headed it.

Founders for the domain, field staff for the truth

The founders briefed me on the grid side — feeders, pole types, what a service center actually is. That got me the vocabulary. It did not get me the behaviour. For that I went to their on-field employees in the US directly, which is how the parts of V1 that aren't obvious got in: that a tool goes missing by being somewhere it shouldn't be rather than by vanishing, that a crew will switch off any alert they can't tune, that a truck is functionally a warehouse.

What this page is careful about. I owned the product thinking, the user stories, the flows and the wireframes. A separate agency did the visual design on top of that work — the finished screens below are theirs, drawn from my structure.

N-Smart's platform today sells an AI layer — risk scoring, predictive maintenance, a sense-think-act loop. That is V2 and it came after me. The customer logos on their site today are not from my period and I make no claim on them.

The structure

The diagrams below are a clean redraw of V1's architecture, made from the original wireframe board and the shipped interface. The board itself is the primary artefact — it's the thing I actually produced — and it looks like this:

The full N-Smart V1 wireframe board — two labelled tracks, Tools and Poles, with dozens of numbered greyscale frames wired together by prototype links
The V1 board: two tracks — Tools | Admin and Poles | Admin — numbered frames, prototype links, modal specs and nav-state variants. Every screen the build team worked from started here.
A close crop of the wireframe board showing tool list screens in card and table form, connected by yellow prototype links, beside truck-tracking map frames
Closer in: the tools track. Card view and table view of the same data, wired to each other, with the truck map and the Add Tool modal spec sitting alongside.

Three pillars and a rail

Everything in the product lives under Poles, Tools or Inventory, with a roll-up dashboard on top that summarises all three rather than becoming a fourth place things could hide. A left rail cuts across the pillars for the things you do — reports, users, service centers. Two axes, no orphans.

All — roll-up dashboard alert counts + one live map Poles 415 feeders · 1,756 poles Tools tag-scanned, calibrated Inventory 145 warehouses · 5,718 SKUs Map + geofence Tilt / vibration thresholds Alert history Checkout requests Calibration ladder Truck manifests Warehouse floor plans Checkouts Sensors & tags Left rail, cutting across all three: Dashboard · Tools · Users · Reports · Trucks · Service Centers pillars answer "what am I looking at", the rail answers "what am I doing"
The same table/card view toggle, search and detail pattern repeats inside all three pillars — learn one, you can use the others.

A truck is a warehouse that moves

The load-bearing decision. Everything belongs to a Service Center — not to the utility, not to a region — because that's the unit a crew actually reports to, so permissions, stock and tooling all inherit from one place.

And rather than build vehicles as their own thing, a truck is modelled as a warehouse with a driver and a route. One inventory model covers a building and a Ford F-350. It's why a truck can carry a manifest and raise a missing-tool flag without a second system existing to make that possible.

Tenants × 167 one utility, or one utility’s region Service Center × 112 supervisor · address · contact Warehouses × 145 fixed site, geofenced Trucks × 32 a warehouse that moves Feeders × 415 the grid hierarchy Inventory — 5,718 SKUs Checkouts Sensors & tags Floor plan — indoor position Driver Tool manifest Route — A to B Missing-tool flag Poles × 1,756 Tilt threshold Vibration threshold Type & connectivity 5 roles — Super Admin · Executive Admin · Service Center Admin · Technician · View Only scoped by Service Center, so the same screen shows a different slice of the same data
One inventory model covers fixed sites and vehicles. A truck is just a warehouse with a driver and a route.

The tool loop, and the two states that cost money

A tool is never simply present or absent — it's somewhere in a cycle. Available, requested, checked out, scanned back in. Running above that is a calibration ladder that flags equipment before it goes out of date rather than after.

The two states worth designing for are the expensive ones. Missing — no scan inside the window. And Cross-Track — scanned somewhere it doesn't belong, which is how tools actually disappear. Cross-Track is the state that stops the first from quietly becoming the second.

Calibration due flagged before, not after Out for service unavailable to book Available in a warehouse, scanned Requested technician raises it Checked out on a truck, on a job Scanned back in a hub read closes the loop back on the shelf, and the clock resets Cross-Track scanned at a site it isn't from Missing no scan inside the window
Solid lines are the happy path. Dashed lines are the two states the reports module exists to surface.
n-smart · tools Tool list — each tool with last scan time, availability, tag ID and a calibration traffic light, with request actions per row
The tool list as it shipped. Calibration is a four-step ladder, not a date field — over 3 months, 1–3 months, under a month, due. Availability carries the Cross-Track state.

The pole loop, and why thresholds are tunable

A pole reports deviation angle, vibration and battery. Those readings become alerts by crossing thresholds — and the thresholds are configured per feeder, not hard-coded. A pole on a coastal run and one on flat inland ground don't lean the same way. An operator who can't tune that will switch the alerts off inside a week, and then the sensors are decoration.

Three bands. Only two of them make work.

Sensor on pole deviation angle · vibration · battery Reading arrives over 2G, low power Feeder thresholds set by the operator 0–10° — normal 11–15° — watch 16°+ — critical watch and critical raise an alert · normal writes to history and stops there Alert raised against the pole, not the map pin Surfaced map cluster + dashboard count Dispatched crew from the Service Center Resolved logged to pole history history is what makes the next reading mean something
Only two of the three bands generate work. That's the whole design — an alert a crew can ignore is worse than no alert.
n-smart · poles Feeder configuration screen — each feeder card showing its service center with tilt and vibration alert counts, banded green, amber and red
Per-feeder threshold configuration. The banding — 0–10°, 11–15°, 16° and beyond — belongs to the operator, not to us.

What it became

The build covered 112 service centers, 145 warehouses, 415 feeders and 1,756 poles in the working data model, with five roles scoping who sees what.

n-smart · inventory Warehouse detail — a searchable SKU table above an architectural floor plan with a live indoor position marker
Warehouse detail. The SKU table carries purchase order, shipment, supplier and project manager — and below it, the actual floor plan with a live indoor position for the thing you're looking for.
n-smart · poles Pole monitoring map — feeder geofence drawn over Washington DC streets with pole markers coloured by alert severity and a pole detail card
Poles inside a feeder geofence. Each marker carries pole ID, type, connectivity and its last alert — the operator's view of a working feeder.

The place the board shows me changing my mind

Reports exists three times on the wireframe board. Twice as a Sankey diagram — tool states flowing into a single total — and once as plain horizontal bars carrying exactly the same five numbers.

The Sankey is the better-looking drawing. It is also the worse answer: someone opening Reports wants to know how many tools are missing, not how the categories relate as flow volume.

Pass 1 — Sankey Pass 2 — Sankey, re-weighted Pass 3 — plain bars
Same five numbers, three times. The question for the case page is which one you argued for, and why.

What I took from it

  • Domain knowledge compounds sideways. Three years of marketing their product is why I could argue about feeders in week one instead of week six.
  • Ask the people who carry the thing. Cross-Track, tunable thresholds and the truck model all came out of field staff, not out of the brief.
  • The unglamorous layer is the one that has to be right. Everything N-Smart sells today runs on top of a model of poles, tools and service centers. Getting that model wrong in V1 would have been expensive in a way no AI layer could fix later.
  • Know which part was yours. I did the thinking and the structure. Someone else made it beautiful, and someone else made it smart.

It was the first time I'd run product rather than delivery, and the thing that transferred wasn't a method — it was the habit of going to the person who actually does the job before deciding what the screen should say.