A YouTube clip I routinely come back to is Steve Jobs responding to a developer at the 1997 WWDC conference:

It's a great lesson in how, as developers and technologists, we can blind ourselves to the greater point of what it is that we're doing. We get so caught up in how cool the tech is that we forget we're making something for the person on the other side of the screen.

"You've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to try to sell it."

— Steve Jobs

The point of this clip is that the fellow taunting Jobs was focused on the technology, and ultimately, himself. What's more, Jobs response tells you everything you need to know about Apple's success (and how to find your own): he made a point to focus on how customer's experienced the end result.

Jobs wasn't oblivious to the technology, but realized that the tech wasn't what people were buying: they were buying what the technology enabled them to do that they couldn't before.

Why Your Technology Can (And Should) Be Flexible

An easy place to get trapped is in thinking that, especially when building the first version of your product: your technology will make or break you.

While there are certainly "right" and "wrong" technology choices depending on your idea, the point is to not place too much importance on technology. It's easy to spend weeks—if not months—pining over which technology to use without building a single feature.

That's not progress; just motion. It's like saying "I'm going to get in shape as soon as I find the right pair of sneakers."

Use What You Know

An easy way to decide which tech to build with is do you understand it? And more importantly, are you already productive with it?

The reason why is that building a product is hard. Learning new languages, tools, etc. at a level where you can build a stable product with them is equally hard.

That doesn't mean you can't or shouldn't ever build a product using something new—doing so is a wonderful way to learn a new set up—but that doing so should be reserved for the express purpose of learning; not building something customers will depend on.

The Cold Truth: Your Customers Don't Care

If you're shaking your fist at the screen shouting "you're wrong, damn it!" consider this: when is the last time you asked "I wonder what stack they're using?" when it came to your cell phone making and receiving calls? How about when you used GrubHub to order food or Lyft to grab a ride?

Chances are high that you couldn't have cared less as long as your call went through, your food showed up on time, or you got to where you were going.

Customers—specifically, people who give you money to use or consume your product—are concerned about themselves. They're giving you money because they think your product can improve some aspect of their life. Your job is to produce that result at the highest possible level using any means necessary.

If the means is JavaScript? Brilliant. If it's COBOL? God bless, but go nuts.

What is "The Customer Experience?"

Think about the last time you got frustrated by a product or service. You paid money to get an end result and the end result was decidedly clunky or didn't live up to what it promised.

How did that make you feel? Did that make you want to give money to that business again? Did it make you want to tell others to go give that business money?

That's the customer experience.

How you felt was how you experienced the product. That experience created a memory in your mind which will promptly surface the next time you need or want what that business offers.

And guess what? Your product is no different. How well you deliver on what you promise dictates how well-received your product will be by customers. It doesn't matter how beautiful your code is if it can't deliver satisfaction to the customer.

Use the Customer Focus to Drive Decision Making

Saying "focus on the customer experience" is one of those easy to say but hard to do things. It's a matter of taste. A matter of "culture" (even if you're a soloist).

It begins by asking "will this decision make the product better for the customer?" You have to ask this around every turn.

Will spending a few extra hours on this as opposed to rushing to get it out the door make it better for the customers? Spend the extra time.

Will eliminating this cool animation that I love make it easier for people to use my product's interface? Kill it.

Is it worth spending the time to optimize my bad code to ensure that it's not clunky when a customer first takes it for a spin? You bet your sweet cheeks it is.

It's About Balance

The point here isn't perfection or excessive self-sacrifice. There will come a time when certain things will have to be "good enough." The point is to invert your decision making process so that the "good enough" decisions are less frequent than the "extra mile" decisions.

The 80/20 rule here is golden. Do enough so that you're both proud of what you ship and confident that it will work well for customers. Realize that a product is never finished. You can constantly iterate on it. Your first version is just the beginning.

By putting a constant emphasis on improving the customer experience, over time, you'll find that what you're ultimately after—money, notoriety, etc.—will come naturally.

Shift the focus away from yourself and the tech onto the customer experience; it's guaranteed to pay handsomely.