Ten years ago, I was working at a small web development firm across the street from Arizona State University. We worked with several startup customers attempting to follow their dreams, create something amazing, and make lots of money! Some of my favorite times at Synapse Studios involved sitting down with new customers in our initial consultations to get an understanding of what it was that they wanted our help in creating. Sometimes, the ideas that were pitched sounded terrible, and instead of being a bunch of money-grabbing yes-men, we had to deliver the bad news: “Sure, we can absolutely build something like that, but we don’t think it’s going to be worth your money.”

This can be hard news to hear and accept for eager entrepreneurs. Often excitement and/or pride blinds us to the reality that only a small minority of startups succeed, especially those run by first-time entrepreneurs. For those that do, most of them have to pivot—often multiple times—from their original ideas and plans. I can’t imagine the devastation for those who put many thousands of dollars into their dream, only to watch it fail. And the kind of failure that stings the most is not due to technical limitations, bad business practices, or intense competition, it’s being overlooked or ignored.

There is a famous quote, “If you build it, they will come,” from the classic, baseball-related U.S. film: Field of Dreams. Despite the line being quoted out of context and incorrectly—it’s actually “he”, not “they”—it has stuck around and found itself inevitably intertwined with naïve ideas about the “American Dream” and entrepreneurship, in general. Unfortunately, the harsh reality is that you can build something, even something really amazing, and they might not come.

This disheartening truth is not just a precedent for the startup scene. I spent about four years in Seattle working at Amazon Web Services in a department known Developer Resources. My team created the SDKs that programmers use to interact with the AWS service APIs from their favorite programming languages. It was there I that I really started getting into open source, as the AWS SDK for PHP was presented as an open source library to customers. Also, I spent time contributing to other projects like Guzzle and PSR standards.

Part of our time at work was spent responding to support requests, forum posts, GitHub issues, and Stack Overflow posts in order to help customers using AWS services through our tools. I found the most frustrating moments were those in which customers asked about things that could have been easily solved with code and documentation that we had already published. “I already built this, why aren’t they using it?” I would say to myself.

Creating something is not the same as advertising or marketing it. Not all published works are automatically broadcast into every human brain. We cannot assume that just because something exists, that everyone knows where it is, has seen it, and understands it completely. Especially when we are the creator, we should not expect everyone to have the same level of intimate knowledge about our creation as we do or the same amount of passion or interest.

Although it may be tempting to respond with the impatient and insulting “RTFM”, doing so is not only disrespectful, it is also a great disservice to ourselves for at least two reasons. First, it robs us of the opportunity of making a human connection. It turned out for me that supporting the software I was writing was a great way to network, make friends, and make people smile. Secondly, questions about our creations can help us gain different perspectives about them. New features, new content, and new ideas come from listening to our clients, customers, and competitors, and discovering better ways to help and serve others. Even when detractors say things that upset us, we can still look for truth behind the emotions that we can use to improve.

It’s also hard to face rejection when we attempt to contribute to someone else’s creation. Contributing to others’ open source projects can be frustrating when they do not accept or use our contributions. When this happens, we should not assume ill intent. In most cases, open source maintainers have decided to do something in a slightly different way or timeline or may have just overlooked something.

It can happen at work too. I’ve built things—really cool things—in my current position at McGraw Hill that have gone unused. Sometimes, this is because the direction of the technologies or priorities has shifted, based on new business requirements. Other times, it’s just because people are busy. Yes, sometimes other people are just too busy to care about every little thing we do. If I didn’t make it convenient enough for them to inject it into their busy schedule, it’s not necessarily their fault.

It’s also often the case that our invitations are more narrowly-scoped that we might initially think. Just because it’s in the company wiki, does not mean everyone has read it or can even find it. Not everyone will notice our posts in Slack (or Twitter). We will need to explicitly invite others. Sometimes we’ll need to sit down with people one-on-one or in small groups. Sometimes we may need to present something to the CTO and get their help to create a top-down initiative. Sometimes we’ll need to pay for advertising. Overcoming the “they might not come” phase may require even more work than the “if you build it” phase.

When our creations don’t get the attention we want or expect, we must let go of the negative emotions that often arise. We cannot give into the temptation to blame others, complain, or proclaim, “That’s not fair!” However, it doesn’t mean we should give up on ourselves or our creations. When we strip away our self-centered feelings of entitlement, we must replace it with empathy towards others, not apathy.

When we build anything, we should be approaching solutions from the perspective of our customers. Fields like marketing, technical evangelism, and user experience (UX) design have all come about to help creators better connect to their customers. When we give people what they truly want or need, and they give us money, recognition, or satisfaction in return, that’s a win-win. We just can’t expect to always get it right, especially the first time, with our own limited perspectives.

Let’s move past the frustration of failure and rejection and keep learning and building. Let’s move forward with an understanding that even though we might build something, they might not come. Let’s try and meet them where they are instead. Let’s listen to and empathize with them, and they might stay with us a while. Let’s truly be agile.