What are things you've learned from your failed projects?

Either from failed projects or mistakes/failures I made which nearly killed successful projects. Not an exhaustive list and in no particular order:

• Before building, talk to potential customers about the problem. Never use words like "the app", "the website" etc...
• Ask for money - or a firm commitment to pay money - before building. "Sure, I'd pay for that" isn't worth the paper it's (not) written on.
• If you take on investors/employees, make sure you sell them on the problem you're solving, not the product you're building. The problem will stay the same, however your approach to solving it may change. So better to have people onboard who are motivated to solve the problem not build that current iteration of the product.
• Raise your prices.
• Raise your prices.
• Increase the amount of money you charge customers for your product.
• Prioritise the important over the urgent. It's amazing how much of the urgent stuff didn't actually need to be done at all.
• Set quantifiable, weekly (or shorter) goals and act on them. Whenever you start working on something, ask yourself "is this the most impactful task I could be doing right now to reach goal X?"
• If it isn't, do that more impactful task and come back to the other one later.
• Be kind to people
• listen
• Get enough sleep and exercise
• Don't eat junk food
• It's ok to say "no" to people/meetings etc
• A lot of things which feel like productive work, actually aren't. Be very careful of this.

Might come back and add some more later.

There's a lot to be learned from @richclominson's failory.com

My first true side project was called "Founders" and it was an ebook that interviewed 18 startup founders from around the world. I wouldn't necessarily call it a complete failure but I definitely learned a lot from launching this little interview project.

Here are some of the main things I looked back on in the first few weeks after releasing the book back in 2013.

Deadlines come quick.

Don’t rely on one source for traffic.

Let people see what they’re buying.

Listen to feedback.

Most of these probably seem obvious but when caught up in the whirlwind of creating and launching your first product some of the most simple things can get lost in the shuffle.

https://medium.com/@_ryangilbert/launching-my-first-product-bcc8145f90f8

Really interesting way of thinking about the competition! Thanks for sharing.

For me, what has held me back the most is thinking that my ideas had to be earth shattering, and falling into the mental trap of the terrible VC oriented advice of "go big or go home". Now, I always make a point to try to find the simplest, smallest, most indie friendly way I can bring an idea to fruition. If I can't find a way to scale down the idea or implementation, I move on.

After failing 4 projects, the golden lesson for me was: Start earning from Day 1.

When I employ people as advisors, I will occasionally listen to their advice .

I will never build a sentient computer smarter than I am.

I will not ignore the messenger that stumbles in exhausted and obviously agitated until my personal grooming or current entertainment is finished. It might actually be important.

I will classify my lieutenants in three categories: untrusted, trusted, and completely trusted.
Promotion to the third category will be awarded posthumously.

I will not use any plan in which the final step is horribly complicated, e.g. "Align the 12 Stones of Power on the sacred altar then activate the medallion at the moment of total eclipse."

Instead it will be more along the lines of "Push the button."

1. It's said a lot but it's still sooo hard for me even now: validate the idea before building it. If you spend 3 months in a closet building an app and you release it, even if the idea is really good and people need it, they won't know about it.

I'm trying it this time the exact opposite - don't even worry about the product yet, build an audience first of people who I want to help. Then figure out products they would buy based on what they ask for.

1. Having a community around you helps so much in unexpected ways. The first several years of trying to make products I was basically a loner. Now I'm a part of a private freelancer community, I hang out around Indie Hackers and organize the meetup in Chicago, and have several friends here who are doing similar things. Just being able to chat about ideas and get feedback on things helps minimize my many blind spots.

2. Being good at code does not in any way predict being good at business. The book The E-Myth states that a successful company needs three types of skill - Entrepreneurial, Managerial, and Technical. Sometimes that is in 1 person, but not usually by default. If you've been an employee your whole career you may find it hard to sell things.

Spending some time learning How To Business TM will go a huge way. This is also why I like the path of 1. Become a freelancer, deliver the service manually -> Create info products, write about how you deliver the service -> Then and only then automate the process by writing software. Each step in that progression is hard enough and the later steps can build on the former. And you build your audience the whole time through.

If you're good at PR and bad at engineering, don't overcompensate on engineering. Shit fails if there're no eyeballs.

Get Eyeballs.

The lesson that comes up time and time again is stretching myself to thin and attempting to reinvent the wheel. Opposed to paying a monthly fee fur some service I potentially need, I would attempt to make a simplified version instead because it would be "free" but, my cost is always paid in time.

Now I just pay for whatever I need within reason. I hate it because it feels like I'm burning through my budget, but I get results and get them quicker. Maybe this is just the plight of an engineer.

Don't let being nice and friendly with clients and employees, be construed as you wanting them for a friend. As much as you can keep things professional. I once got too close to a colleague and ended up in a very awkward situation where the person expected more out of me than the others, all because I wasn't careful.

1. Build a high-fidelity prototype and test it with your target users. Iterate it to decide on the MVP. This will also help you fail fast.
2. Launch and iterate based on users' feedback.
3. Let users drive your product, not competitors.

Create a funnel that shows your conversion, always track it from beginning so you can see where you're dropping off.

Try to somehow hack and create a funnel on your system if you can't find an analytics system that can help you or else you will be blind.

Also likely friends and family are too kind to you, try going for products which random people are looking for using keyword searches on Google or Apple Appstore.

Learn from competitors if need to, nothing wrong with some necessary copying.

Don't strive for way too many features because you won't do a good job for it.

Always be slow in implementing features and implement features only if you know there is already big usage building on it, don't build and then wait for usage. Build because there is already big usage in a way that people are already using your product.

The map is not the territory. How you think you will feel during the journey and how you actually feel during the journey can be a pretty big delta.

Just because your co-founder is a domain expert and user of the product doesn't mean anyone else will want to use it. I spent a year on a project no one wanted. Then my co-founder stopped using the app.

Ship as soon as you have something better than the existing market offering.

Charge if you want to find out if anyone values your product.
Offer it for free if you are scared of rejection. Once you work up the nerve, charge money and face reality.

Listen to experience and suggestions. It was earned. Be wary of "unearned advice."