What is a technical spike and how do you scope one for an AI feature?

Fenwick Grid Analytics builds GridPulse, which reads a utility's sensor readings and decades of handwritten maintenance notes to flag which transformers are likely to fail soon. Nomvula Dlamini is the AI PM who has to decide, before any of it gets built for real, whether a weekend demo on three tidy substations means anything at all.

How to answer this, stage by stage

Nobody is scoring whether you know the dictionary definition of "spike." They are scoring whether you can name the one number that would have stopped a bad build before it started.

Let's learn

Say we build a tool that reads a utility's sensor data and forty years of handwritten maintenance notes, and scores each of its 40 substations by how likely a transformer is to fail in the next 90 days.

Before GridPulse, a crew supervisor spent about 3 hours a week paging through paper logs across all 40 substations, ranking them for early inspection mostly by a fixed five-year rotation and memory of which ones "always give trouble." A demo weekend on three of the newest, best-digitized substations made GridPulse look obviously right, matching what the supervisor already suspected in all three cases.

This is the whole ranking system GridPulse is meant to replace: a folder, a rotation, and one supervisor's memory.

Here's the turn: the extra mistakes on old logs are not really the problem. The problem is that Nomvula was ready to greenlight a six-month build straight off that one clean weekend, before anyone had tested whether GridPulse works on the substations that actually matter most, the old ones nobody has properly inspected in years.

At its worst, GridPulse ships after only the clean-log validation, marks an old, poorly-logged substation "low risk," and that transformer fails anyway, an outage that reaches 14,000 customers for six hours. The whole predictive-maintenance program gets shelved afterward, not because the idea was wrong, but because nobody scoped a real test of where it was weakest.

What I would leave alone: a simple rule like flagging any substation with no inspection in 25 years needs no spike at all. That is a lookup, not a probabilistic judgment call, and testing it like one wastes the two weeks that matter more elsewhere.

The lesson: a demo proves a model can do the easy version of the job. A spike is the only thing that tells you what happens on the version of the job you'll actually be judged on.

Now here is the same thing as a story

The short version above is what you'd say scoping the spike in a planning meeting. Read this one for what it felt like the week Nomvula almost skipped that meeting entirely.

Nomvula Dlamini has spent four years turning Fenwick's field data into things a control room can actually act on. She can tell a genuine sensor anomaly from a wiring glitch by the shape of the graph alone.

The demo weekend went well, better than well. Three substations, all recently digitized, all ranked by GridPulse in an order that matched exactly what the crew supervisor already believed. The room was ready to greenlight the real build on the spot.

Not every AI idea needs two weeks of doubt. This one, sitting in the expensive, unsure corner, clearly did.

Thaddeus Vrba, a field ops supervisor who has walked every one of the 40 substations himself, leaned over during the celebration and said, "you're about to spend six months proving what any lineman could've told you about those three in an afternoon. What about the other thirty seven?"

That one remark reset the scope. Instead of a six-month build, Nomvula proposed two weeks: freeze a real test set of 60 substations, the 22 with a known past failure plus 38 without one, spanning logs from 1979 to 2024, and name the one number that would decide anything.

Four things, decided before day one. Everything else about the spike falls out of these.

The kill number: catch at least 80 percent of the 22 known failures inside the top fifth of flagged substations, tested specifically on the oldest quarter of the records, not averaged across all of them.

Ten working days, each with one job. No day was left open for "and also let's just keep building."

By day four, the number on the clean quarter looked exactly like the demo: 93 percent. By day eight, the number on the oldest quarter came back at 38 percent, and it was clear the model was reading right past the exact abbreviations that showed up only in decades-old notes.

The real question was never whether GridPulse could rank three good substations correctly. It was whether "it works" had ever meant "it works on the records we'll actually be judged on," and the two weeks were the only thing that told the difference.

The spike didn't kill GridPulse. It killed the plan to build it before fixing the old-log pipeline first.

When the demo first landed, someone said, "let's just move fast and build the real thing, we can tune the details later," and it sounded reasonable, since three for three looked like more than enough proof.

The demo was never the finish line. It was step one of five, and the middle three were the only ones anyone had skipped.

Rerun that celebration with the two-week spike already scoped: the 38 percent number surfaces on day eight, at a cost of about 18,000 dollars and two people's time, instead of surfacing eight months and 420,000 dollars into a full build, after an outage had already made the decision for everyone.

What I'd tell myself, hearing Thaddeus's question land in that room: a great demo is real evidence of exactly one thing, that the model can do the easy version. It was never evidence about the version that would actually matter.

SPARK, the five letters that scope a spikeNot a script for distrusting every promising demo. SPARK is what tells you exactly which case the demo never tested.

The recap, one line per letter: situation is a supervisor's manual rotation, payoff is trusting a risk score enough to act early, anchor is the two-week, 80-percent-on-old-logs kill number, risk is silent misreads on old abbreviations, and keep out is everything past the model itself.

And if you want to be sure it really works, try it somewhere elseSame five letters, a veterinary clinic instead of a power grid. The record-keeping problem barely changes shape.

Dr. Ilse Vantongeren runs product for Bright Paw Veterinary Group, testing GaitCheck, a tool meant to flag likely lameness in dogs from a short phone video of them walking. Mapped onto SPARK: situation is a vet tech watching a dog walk across the room and judging gait by eye, in about 90 seconds per visit. Payoff is catching subtle early lameness the eye tends to miss on a busy day, before it worsens. Anchor is a two-week spike scoped to one kill number: matching a specialist's lameness grade on 50 real recorded visits, across dogs of very different sizes and coat lengths, not just the golden retrievers used in the demo clip. Risk is the model reading a low, wide-set dog's normal gait as lameness, since its training clips leaned toward taller breeds. Keep out is any in-app video capture guidance or breed-specific tuning, both left for after the spike answers the one question.

A different profession, the same missing slice: the cases the demo never happened to include.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "one question, one kill number, a deadline in days, a list of what we skip," and stop.
Cost: no budget for a full two weeks. Say so honestly, and scope three days against 15 hard real cases rather than skip the spike entirely.
The demo really was strong, for real: if the spike confirms the number holds even on the hardest cases, that's a genuine green light, and saying so plainly is what makes the method trustworthy rather than reflexive doubt.

Where people run it wrong.
They let a great demo set the scope for the real build, skipping the spike entirely.
They build the test set from whatever data was easiest to pull, not the cases most likely to break the model.
They decide the kill number after seeing the result, which means no result ever actually kills anything.

How to use it live. The moment you're asked to scope a spike, ask yourself: what's the one case the demo never actually tested? Build the golden set from that case first, name the number that would kill the idea, and the rest of the scope follows on its own.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0