Scope the Smallest Thing That Removes the Pain

Last post was about a code review comment on YAGNI - splitting a file too early, based on a guess about future requirements. The fix took thirty seconds; the mindset shift took longer. This post is the same lesson, one level up. Not a file this time - an entire feature.

Lesson

The smallest thing that removes the actual pain, shipped now, beats the complete system, shipped later. Every additional layer of automation you design in advance is a bet on the future looking a certain way. The more of the future you try to automate up front, the more of that bet you're placing before you've had a single real user push back on any of it.

Context

I'd been mapping out an automation for a workflow that a support-team member ran almost entirely by hand - repetitive, manual, and clearly a good automation candidate. Over a series of conversations, I built out what felt like a genuinely complete picture:

Preference capture built into the point where the decision actually gets made
A reusable template system so the same setup wouldn't need to be rebuilt every time
Auto-generated outbound messages, timed and formatted to match what was already working
Calculated logic baked in, so the person running the process wouldn't have to do the math by hand anymore

I cross-checked it against the actual process, refined the edge cases, and mapped it end to end. It felt thorough. It felt like the right way to approach the problem - not a patch, a proper solution.

What Came Back Instead

I brought the full design to my lead expecting some version of "let's start building." What I got instead was a question, not a rejection:

"This is bigger than what we need right now - what if we just gave them clean data, and let them keep doing the rest manually?"

That single question reframed the entire project. It wasn't "the design is wrong." It was "you've optimized for completeness before you've optimized for delivery." The full design assumed the value was in automating the whole process. The actual value, at least right now, was in removing the one part of the process that was costing the most time for the least reason: manually digging through records to find the people and details relevant to a given task.

Everything past that point - the grouping, the judgment calls about exceptions, the final communication - the person doing the work was already good at. They didn't need it automated. They needed the part that was pure friction removed, and nothing else.

Why It Mattered

A few things became clear once the scope actually got questioned:

The full design wasn't wrong - it just wasn't the fastest path to relief. Every piece of it was justifiable in isolation. None of it was necessary to solve the problem that was actually costing time today.
A smaller change can remove most of the pain. The expensive part of the manual process wasn't the judgment calls - it was the searching. Once that search was gone, the rest of the process, still manual, was already dramatically faster.
Smaller scope means faster feedback. A single export feature can be built, shipped, and reacted to in days. A full workflow automation - templates, generated messages, calculated logic - takes meaningfully longer to build, and every week spent building it is a week without real feedback from the person actually using it.
Nothing about the bigger design is lost. It's not deleted, it's deferred. If the smaller version proves out and the team decides the fuller automation is worth it, the requirements are still there, informed now by real usage instead of a guess made in advance.

The Fix

The scope came down to one thing: a structured export of exactly the data that was previously being tracked down by hand. Nothing pre-grouped, nothing pre-calculated, nothing auto-sent. Just the raw information, organized well enough that finding it stopped being the bottleneck.

The bigger design isn't gone. It's just not what's getting built first anymore.

Result

If the fuller automation turns out to be worth building later, it gets built on top of a working v1 that's already proven useful in practice - not one that was speculatively designed against assumptions about how the team would actually use it. If it turns out the smaller version is enough on its own, nothing was spent building the parts that weren't needed.

Same principle as the YAGNI post, different altitude. Down at the file level, it's about not splitting code for a use case that doesn't exist yet. Up at the feature level, it's about not building the complete system before you've shipped the smallest version of the fix. Either way, the question is the same: what does the problem actually need right now - not what does it look like it might need eventually.

Part of an ongoing series documenting lessons from my internship. Previous post: YAGNI - Don't Pay for a Guess.