Don’t Build in a Vacuum: Why Great Software Starts with Listening

There’s a dangerous moment that can happen when you’ve been doing something for a long time.

You start believing you actually know what you’re doing. We forget that great software starts with listening.

After many years of working in technology, I’ve solved a lot of problems. I’ve written software, designed systems, consulted with clients, managed architecture teams, and built products of my own. That experience has taught me how to recognize patterns, anticipate problems, and make decisions that I probably would have struggled with much earlier in my career.

Experience is incredibly valuable. But I’ve also learned that experience can equally create a blind spot.

The more problems you’ve solved, the easier it becomes to look at the next one and think, I’ve seen this before. I know what needs to be done.

Sometimes you’re right. And sometimes that confidence quietly turns into assumption.

At that point, our experience can actually start to work against us. We start designing before we’ve listened enough. We start solutioning before we’re certain we understand the problem. And because every decision makes perfect sense based on what we already know, we may not notice how far we’ve drifted from the people we’re supposed to be helping.

That’s how we end up building in a vacuum.

And recently, despite everything I’ve learned over my career in technology, I caught myself doing exactly that.

We Love Solving Problems, but Great Software Starts with Listening

One thing I’ve know about people like myself who work in technology is that we really like solving problems.

I’ve been fortunate to wear a lot of different hats over the years.

• Developer.
• Architect.
• Consultant.
• Technology leader.

Every one of those roles essentially exists, in one way or another, to solve problems.

There’s an incredible feeling that comes from seeing a raw idea become a working application. Every feature you complete feels like progress. Every completed screen feels like momentum. Every technical challenge solved is another reason to believe you’re getting closer to something great.

The danger, however, is that progress can become addictive.

Expertise Can Become a Blind Spot

It’s true that expertise can be both an advantage AND a liability.

The more experience we gain, the easier it can become to make decisions quickly and decisively while foregoing asking “is this the right thing to do?” We have to be careful not to build in the proverbial vacuum.

Because expertise can encourage assumptions. If we’ve solved similar problems before, why not use that same method again?

Maybe we’ve seen customers ask for comparable features in past projects. Or we assume that since we’ve worked in the industry for years, we surely know what people need better than they do. Right?

Well, sometimes we do. Sometimes we don’t.

Without stopping to take a step back and think about it, we might have already invested a lot of time building a solution not one wants or has asked for. We end up building what we assume people want, not what we “know” they do.

We may not realize when we slowly start building in a vacuum.

My Reminder Came From an Unexpected Conversation

Just last year, I started building my Online Sim league platform called SimLeaguesPro.

The initial goal seemed straightforward. Build a site for online leagues that included my old Fantasy league mod.

I’d spent years participating in online simulation baseball leagues as both an owner and commissioner. I knew there were many frustrations that commissioners faced, and I believed I could build a platform that made running those leagues easier while improving the overall experience for everyone involved.

As often happens with passion projects, the vision started small, but quickly started expanding outward as I went.

Every new idea seemed like a logical improvement. Dashboards became management tools. Management tools became community features. Community features became fantasy leagues, notifications, cloud storage integration, and dozens of other ideas.

From my perspective, every one of these made the platform better and more capable.

At least, that’s how it looked. So I kept building.

Eventually, I reached a point where I felt confident enough to ask a few experienced league commissioners to take a look.

I wasn’t nervous about this step. Quite the opposite. I was energized and confident that what I built would “wow” them.

I expected a list of bugs, a handful of feature requests, and maybe a few comments about improving the workflow. I remember thinking, “This is finally coming together.”

Then I started to read the feedback. Instead of giving me something I wanted to hear, I got something far more valuable. I got feedback to pulled me back out of the vacuum. It challenged my assumptions and the reality of what I thought I was building.

The Feedback I Needed, Not the Feedback I Wanted

Now let’s be clear. The feedback that was giving wasn’t harsh, rude or dismissive.

In fact, it was quite thoughtful and thorough.

The commissioner pointed out that the main workflows required more effort than what they were trying to streamline. While I thought I had added “capabilities”, I really had been building up technical complexity. Where I thought things made sense, outsiders were met with confusion and frustration.

The feedback wasn’t really about any one individual feature. It was about the project as a whole. It forced me into being somewhere I hadn’t been the entire time I was building up to that point. Standing in someone else’s shoes getting an outside perspective at last.

While I thought I was doing right by the community, one thought came across loud and clear:

“I’m not sure this actually solves a problem any one has.”

It showed me that somewhere along the way, I stopped building with the community, and had instead started building for them. While these two ideas sound almost identical, they’re definitely not. I was in the vacuum so my assumptions were personal and disconnected from the community.

When you’re building with people, every conversation shapes the direction of the product.

When you’re building for people, it’s surprisingly easy to substitute your own assumptions for what you think others want. And the likelihood of going far, far in the wrong direction becomes increasingly likely.

It made me realize I wasn’t coding as part of the community. I was coding in a vacuum.

Technology Exists for People

Being forced to stop and think hard on the feedback I’d received reminded me of something I came to know about myself a long time ago.

Technology is what I do. People are why I do it.

Over my career I’ve worked with incredibly talented developers, seen remarkable systems designed by brilliant engineers and watched teams solve extraordinarily difficult technical challenges.

But none of those accomplishments would have mattered if they failed to solve someone’s real problem. Whether completing a banking transaction, booking a hotel room or signing up for an industry event, the solutions I saw being made, and built myself, all solved a real world problem for someone.

It comes down to the fact that technology doesn’t exist because it’s technically impressive. It exists because someone’s day gets a little easier, a little faster, or a little better because of it.

That’s true whether you’re building enterprise software for thousands of employees or a small application for a niche community.

The measure of success isn’t how many lines of code you write.

It’s how much value someone gets out of using it.

Listening Is Part of the Architecture

When building programs, web sites or apps, we spend countless hours discussing system and technical architecture, but very little time discussing requirements architecture. We plan for things like:

• Scalability.
• Availability.
• Performance.
• Security.
• Maintainability.

And those conversations absolutely matter.

But there’s another architectural discipline we don’t discuss nearly enough.

Building continuous feedback into the product plan itself.

Not just during Beta or User Acceptance Testing. And definitely not just before a production launch. But from the very beginning.

Having real conversations with the target users to gain real insights and feedback early, and often. Every assumption we make inside that vacuum can feel perfectly logical. Even though it might be working against our end product.

So it’s important to make sure that any assumption has an expiration date. So that we don’t stray too far of course until it becomes something that too expensive to change.

Changing Direction Isn’t Failure

After receiving the commissioners valuable feedback, I made a difficult decision.

I decided to stop on the path I was on and take the time to dramatically simplify the plan for SimLeaguesPro.

The focus has now shifted toward solving one meaningful problem commissioners tell me they want solved instead of telling the community what I think they need. It’s a necessary step to correctly align the end product from the beginning to correctly meet the needs of the people its intended to be used by.

Some people might see that as changing direction. I see it as finally pointing in the right direction. That’s not failure. That’s progress.

The Wright brothers didn’t start by trying to build a commercial airliner. They started by proving flight itself was possible.

And that’s what I now plan to do with my project. Not because the software has to become smaller. Because my understanding of what the end user wants is much clearer now.don’t stray too far of course until it becomes something that too expensive to change.

The Bigger Lesson

Although this story comes from software development, I don’t think it’s really just about software.

• It’s about owning of our assumptions.
• It’s about communication with our stakeholders.
• It’s about being humble and honest about out abilities, and blond spots.
• It’s about recognizing that every one of us—including experienced developers, architects, executives, and entrepreneurs—is capable of falling in love with our own ideas. Sometimes to a fault.

The solution therefore isn’t to become less ambitious. It’s to invite reality into the room as early and often as possible.

So what has this experience reinforced for me?

• Talk to customers.
• Give the product to the people who will use it early and often.
• Challenge assumptions.
• Ask uncomfortable questions.
• State goals for many to hear and challenge, if necessary.

And most importantly, listen carefully when the answers don’t match your expectations.

Some of the best decisions you’ll ever make won’t come from writing another line of code. They’ll come from stopping, thinking, and changing your mind.

Final Thoughts

I’ll be honest. Getting feedback contrary to what I was hoping for wasn’t easy.

I’d invested over a year into the project. Numerous hours. Literally thousands of lines of code. More early morning and late nights coding and testing than I care to share. I can’t think of anyone who’d enjoy hearing that their work may be solving the wrong problem or making the problem their trying to solve even worse.

But once I had time to reflect, I realized it was exactly the feedback I needed. He thought he was reviewing a website. In reality, he reminded me of one of the most important lessons of my career.

Technology is at its best when it begins with curiosity instead of certainty.

And the farther we build from the people we’re trying to help, the greater the chance we’ll build something they didn’t ask for. No matter how elegant the code is, building the wrong thing well is still building the wrong thing.

Looking back, I don’t regret the hours I spent building SimLeaguesPro. I don’t regret the features that now won’t ship. I don’t even regret taking the wrong path for a while.

Because every one of those hours led me to a lesson that’s far more valuable than the software itself.

Technology doesn’t exist to prove how clever we are.

It exists to improve someone else’s day.

And people have a habit of telling us exactly what they need…if we’re willing to stop building long enough to listen.

Because great software isn’t built in a vacuum. It’s built with conversation and cooperation.

What Do You Think?

Have you ever spent time building something before realizing your assumptions were wrong? Or have you been on the receiving end of software that clearly wasn’t designed with its target users in mind?

I’d love to hear your experiences in the comments, on LinkedIn or Reddit.

Those conversations don’t just make products better.

They make all of us better builders.

Thanks for reading. And until next time keep building…but don’t forget who you’re building for.