I came across an interesting line while I was reading The Geography of Bliss – Search For The Happiest Places In The World. The section was talking about Icelander’s admiration for failure, and it ends with, “We Americans like to think that we, too, embrace failure, and it’s true, up to a point. We love a good failure story as long as it ends with success.”

For a couple of days after, I kept coming back to it while I was doing unrelated things. Yes, it is hard. Even though I have decided a long time ago to dedicate myself to a life-long of learning, it is still hard to acknowledge the reality when I fail.

So here goes some learning from my failures.

The idea is mainly:

Forget about coding. Seriously.

As a developer, it is natural to consider every problem a technical problem. And it is super easy to fall into this trap because in our day-to-day job, almost all the problems we encounter are technical. So it is unintuitive for us to see that the technical part is just one puzzle piece in the picture, and that picture is called: solving someone else’s problem.

But when we are running a one-man-band of a business, we are no longer the developer. We are the technical department, the marketing department and the sales department. When we join a company, the idea or product has already been validated against the demand of customers, so we didn’t have to think about it. Our new-born project has not.

Even knowing all this beforehand, I still managed to build multiple MVPs without actually testing them against any real human beings, just because, “this will work, I knew it”. Or more like, “I so wish that this works that I’m going to ignore the proof part of the work”.

From what I see everywhere, chances are that whoever you are, you probably won’t listen to me either, until you did it a couple of times yourself and actually felt the pain of it… At least, remember that you can come back and reread the rest of this post after you hit a wall. Or a couple of walls.

Anyhow, that’s how I found myself finally messaging plenty of humans about the next brilliant idea in my list and asking for opinions. For talking to people, I recommend the book The Mom Test. The idea is that you shouldn’t ask your mom whether your business is a good idea, because she loves you and will lie to you. But with the right questions, you can even talk to your mom and get useful and truthful answers out of the conversation.

The above is the one approach where you design a solution to a problem, and find out if people actually want it. The other way is the opposite: create an audience by providing useful content, then find out what problems they need solving.

Welcome to:

Content marketing.

On Indie Hackers, the majority of small businesses that go anywhere substantial has one thing in common: by the time they released their product, they already had an audience waiting eagerly. But when someone reads a retro story like this, their mind might just go “yeah, that lucky bastard”, instead of “hmm, I wonder if they built their audience base deliberately over months, or even years”.

Either way, we can learn from them and produce good contents. People gravitate toward them.

Good content can be either of the following [1]:

• Useful blog posts that are still valid after years
• Useful free tools

It pays well (pun not intended) to write well. Paul Graham wrote that, “I think it’s far more important to write well than most people realize. Writing doesn’t just communicate ideas; it generates them. If you’re bad at writing and don’t like to do it, you’ll miss out on most of the ideas writing would have generated. [2]”

The only downside is that: it does take an incredible amount of time and effort to build an audience.

We’ll see where it goes.

 

[mc4wp_form id=”1683″]