I've built things that nobody wanted or needed, and it was all because I made an assumption.

In a previous job, I was supporting a product that produced reporting files meant to be submitted to a state regulatory body. When I saw our data specialists spending so much time submitting each file one by one, I thought, "surely, there's a better way!"

So, I advocated for a feature that would bundle these files together, enabling our data specialists to submit them in bulk instead of tediously uploading one file at a time.

Well, I completed the feature, deployed it, and let our team use it.

After 3 months, the data specialists admitted they had used my feature only once.

What I didn't realize was that each file could contain errors or somehow be rejected for various reasons. Every data failure involved connecting with another human to figure out what went wrong, and what I had built made it impossible to get to the level of detail they needed to triage data issues.

The tediousness I witnessed was because of the way the business was designed, not the way the system was defined.

I learned to ask more about the process I'm attempting to improve, and more importantly, how it affects the people that are using tools I build. The most important lesson that I took from this experience is this:

If I am not a user of the product, my opinion of how it should work will be biased and I should offer fewer suggestions on how the system should work.

I should seek to solve problems that the users actually have, rather than solve problems that I think they have.