Face it. If your working on a large side project that you hope to be profitable, you’re going to run into moments when you can’t stand the stench of anything related to your project. You’ve run into a whale of a problem and there’s no tiptoe’ing around it.
If you’re a human being like me, this usually leads to a lot of abandoned, half-baked projects. They could have been profitable, but your subconscious convinced you that “there was no way that you could get over that [insert random hurdle here], so why even bother continuing?
Quitting is the only decision that your mind can rationally justify. Hell, a week later, you’ll feel much better about the fact that you just tossed another project into the metaphorical gutter of unfinished work.
Clearly, your mind has forgotten, or simply doesn’t care about all the rationalizations you’ve made why starting this project would be worth it in the first place. You have entered the Quitting zone. You’ve been here before and you will be here again.
There is only one rule about getting passed the Quitting Zone: Do not under any circumstances listen to yourself. You feel overwhelmed, paralyzed, unable to continue, and ready to submit to the quitting gods.
Go do something else for a few days, and really think about your problem. It’s NOT AS BAD AS IT SEEMS. Talk to some other people, the solution might even be you need to seek other people interested in working with you.
No emotions last forever. The feeling will disappear and you’ll be all happy again ( Science! ). This is when you get back to work.
You didn’t start your product to “build skills”, you started in hopes of building a profitable product. Shipping is a skillset in itself, and mastering the Quitting Zone is a whopping part of it.
My game-in-progress requires a clever character design: A few characters are the main part of the game and I’d rather they didn’t look like the work of a toddler. I can handle some design, but I had never tried building characters. Yesterday I gave it a shot.
No single iteration of the details was anything I was looking for. I grew stressed and ready to quit. How can I build a great game if I don’t have one of the most important skills needed?
Easy. Work and perfect the things I CAN do well. My game has plenty of programming, writing, and interface design — all of which I know I can do well. Character Design is frustrating, but I can learn or find other who’d love to trick out some sweet personalities.
Conclusion: Working on things you suck at is not a good idea if you value your motivation and stress levels. Learn as much as you can about them and wait to do them last unless you absolutely can’t.
When I hear “Project” from someone, that means to me that you’re building something that will help you fill out your resume and skillset. Usually projects aren’t meant to be monetized, and often times my assumptions are correct.
I’m not a fan of working on side projects for the sole reason of increasing your intrinsic value for potential employers or clients. Hear me out.
I am not one of those people, but the mindset isn’t hard to understand: working on side projects increases your skills at your craft, therefore you are increasing your monetary value to those who are in need of your abilities.
Certainly a respectable pursuit, but I think you should work on products instead of projects. Products are a better investment of your time, and you should understand why:
Products offer a possible return on investment. A lot of time is put into projects, and while the time isn’t worthless, it could be better valued as a product. It’s possible you won’t make a cent, but without shipping a product you’re not even giving yourself a shot.
Products will teach you other useful skills you’d never learn with a project. Marketing, programming, design, even music can all be valuable parts of launching a good product. Maybe you don’t have the time to learn the extra skills. That’s fine because:
Products can teach you to network with other talented producers. You certainly don’t have to do everything on your own, and you shouldn’t be surprised that their are plenty of others who are looking for great people to make products with.
Make sure you find someone you have chemistry with though. Working with bad partners will become a nightmare fast.
There are plenty of places to meet other producers online like builditwith.me , meetup.com, cofounder2be.com and even reddit or hacker news if you’re patient enough.
What if you are the employee type? You have no interest in your own product and you just want to work for someone else’s large company. That’s fine, but my point stands because:
Understanding the entire production cycle of a product will make you a better employee. Even if I’m simply programming, I’ve taught myself to understand how my programming is going to affect all other aspects of the product. If I take everything into consideration, it makes designing and marketing around it much more fluid.
Personally I’d rather work on my own product than other people’s products, and you probably do, too. Your chances of doing this are much more likely if you turn every side project into a product.
Last week I wrote a piece about what I thought would be an excellent plan to keep my motivation high for working on personal projects.
I messed up a bit.
Staying orthogonal, gettings others involved, and especially not overworking myself remain to be solid words of advice from my past self. What I want to reevaluate is breaking my project up into many mini projects.
I wouldn’t say that it was a bad idea, but I don’t think I was specific enough. Breaking your project down is the what, but after a week of trial I realize I need to focus on the how.
My current project is a iOS game I’m calling Mini Margin. Think Storage Wars with a few adjustments. Certainly a game that a focused, motivated individual should be able to pull off.
My first mini project was to create all the needed Views and build each transitions (segues) between each screen. I quickly became bored of this so I broke my mini project rule and started designing, a project I wasn’t supposed to indulge for awhile. This bored me quickly, too.
Motivation was waning. I had to change the way I was approaching my project.
If you’ve watched Storage Wars, you’d know that the primary events of the show are the bidding and the haggling. Without these two primary components, the drama and the delight I get from seeing how well each character faired afterwards are nonexistent.
I should have started the project building the algorithms needed for bidding and haggling. If these two algorithms themselves work very well, the game could be fun even with a shit design. They are the two most important cogs in the wheel.
Motivation has been abundant since I switched to building these algorithms. I’ll have a great foundation for building the rest of my game once these two algorithms are complete, and I’m very excited to keep working.
I’m not into saying that it will work for everyone, but if your a product guy like me, who designs and develops most of all his projects, consider starting with the hard parts, because most likely those are the biggest selling points of your product.
I’ve found giving up on my projects to be really easy, or at least hard to not do. I’m about to start another ‘big’ one and I have some thoughts about how I can maintain focus that you may find useful.
Not staying orthogonal has really made any big project a nightmare. Once your codebase is massive, small changes can have big, annoying consequences if you do not keep each system independent from others. Apple tries it’s hard to inject the idea of a Model-View controller into your head, and I get the point.
The human mind loves being rewarded and I’ve previously done a poor job of giving myself little rewards as I continually progress through my project. My last project I spread my attention and never focused on finishing a single part of it — I got zero reward from actually finishing even one screen from the game.
Not getting any validation or feeling of rewards sucked, but I also worked with people I did not enjoy working with. Be picky about partnerships with others, you might find yourself wasting a massive amount of time working with people you have little chemistry with.
I hate stressful, failed projects (duh), so I’ve really been thinking about how I can follow through with the next one. Here’s some of my hypothesis:
Separate the project into several mini projects. There are a lot of challenges ahead, so I’ve broken them down into related areas and plan on tackling them one by one. I want to keep my head focused on the mini project itself, so my mind isn’t caught dwelling on the size of the large project. This also forces me to be orthogonal. One project at the end will be dedicated to polishing and connecting all the elements together.
I’m not going to overwork myself. I’ve tried the 10 hour a day, everyday approach, and I felt like this cramped my creativity and turned me more into a obsessive, unproductive nervous wreck. I’m keeping my hours limited and I’m not going to shy away from other hobbies.
I’m not going to be shy about getting others involved. Don’t hide your project if you want to finish it. I know the fear of rejection is powerful but if you don’t get it out there then you aren’t getting any ideas from other amazingly creative people. Now that being said:
I’m not going to let just anyone work on the project just because they want to. I’ve seen plenty of people, including myself, throw themselves onto a team, making assumptions that everyone is driven, dedicated, fun and creative as you only to be severely disappointed.
I’m certainly not going to turn away everyone, but instead of approaching people to jump into a project, why not just ask to chat with them, get to know them a bit, discuss random topics, then see how you like em and go with it then?
These are my hypothesis. I start my project tomorrow, it’s a iOS game and I will share neat things I learn and make along the way.