Archive for the ‘Product’ Category

For the Single Founder Who Can’t Code


This post originally appeared on TechCrunch as a guest post.

Last summer when I started working on Undrip, I was in a tough spot. I grew up doing web and graphic design so I was a pretty good front-end developer and designer. But I knew nothing about back-end web development — loops, branches, dictionaries or functions were all foreign concepts to me. I was a single founder who couldn’t code.

Against the Odds

Every week I get emails from entrepreneurs seeking my advice asking how I did it before, and how I’m doing it now. They find themselves in similar situations in that they’re looking to build a tech startup with little to no technical skills. They’re frustrated by their inability to make forward progress and they usually either give up and fail, or outsource if they have some extra cash (which usually leads to failure).

If you’re a single founder who can’t code, your chances for startup success are near zero. However, there’s still a chance.

And a chance is all you need.

diceInspire or Die

There’s only one skill in the world that can make up for your lack of design or dev skills. It’s a skill you have to learn and learn to do well: You must learn to inspire.

Your survival will hinge on your ability to inspire, persuade, and convince makers that they should join you on this adventure. It’s the only chance you have. You know you can’t do this alone. You shouldn’t do this alone. And you won’t do this alone.

Easier Said Than Done

Some non-technical entrepreneurs are so incredibly charismatic, persuasive and charming that all they need is a clean napkin and a wide smile to sell the vison and get people excited. They’re able to attract talent with no problem. If that’s you, congrats. Run with it. As long as you have creators, makers and builders on your team, you’re in the game and able to fight. Give them the equity they deserve (a lot!). Make them owners not mercenaries. Your idea is worthless without them — accept that now and nobody gets hurt.

As for the rest of us, we’ve got more convincing to do.

When I was recruiting people to help build Undrip, I could have just dazzled people with designs. For many folks, that’s all you need to help inspire. But I wanted to take things up a notch. I wanted to personally build something that potential teammates could see, feel, touch and play with. I wanted to share a fully functional product that I would muscle together with my bare hands — Chuck Norris style. So I had to learn to code.

Becoming a Builder

I spent all last summer learning how to code [0]. I practically lived on StackOverflow, Github, IRC channels, and Google… soaking it all in like a sponge and working on a real product that would force me to learn. I had a few friends who answered my dumb questions and guided me through some snags. In the end, I built the first version of Undrip almost all on my own. It was perhaps one of the greatest accomplishments of my life. At the end of last summer, I felt like I could I do anything. It was an incredible experience [1].

It was never about learning to code so that I could be a one-man army. And it certainly wasn’t about creating a large-scale, production-ready web app that millions could use. In fact, not even a dozen people could use it [2]. It was all about inspiration — putting more arrows in my quiver so that I could get out and inspire people to join me. I wanted to demonstrate that I could dig in and learn, and that Undrip was a product worth fighting for.

8539414758_8fe3517993Handshakes & Smiles

As much as networking sucks, it’s a necessary evil when you need builders. You can’t inspire people if you don’t know anybody to inspire. I’d much rather be working, designing and getting stuff done.

Throughout the summer of me learning how to code, I did everything I could to meet engineers. I would go to python meetups and other hacker gatherings. I would search directories, github and twitter lists for python engineers in the Bay Area who I could meet with in person. It was never about asking them to work with me — that’s the wrong approach. it was always about cultivating the relationship and learning from them as I was doing my best to speak their language (python/django). They felt like they were “giving back” and helping a n00b. I remember meeting Mike Malone, Kenneth Love and so many others at Coffee Shops in the Bay Area. I drove to a small town in the East Bay to meet Kenneth at a local Starbucks. I was immersing myself into their world and building as many relationships as I could. Inspiration always starts with a relationship.

Money Can’t Buy Everything

When you can’t inspire people to join you, it’s very tempting to use that cash in your piggybank to hire a contractor/freelancer. You wanna pay to play.

That rarely works.

I was a design freelancer in college. I would ask for as much money as possible, and I would try to spend as little time on it as possible. That was the name of the game. Contractors just aren’t invested in the long-term success of your product. They’re gypsies moving from one thing to the next. The lack of ownership and commitment will cost you more money, more time and more heart ache in the long run.

What happens when your freelancer is “done”? We all know products are never done. So soon you find yourself back at square one, having to pay someone to fix bugs, tweak features, etc. That hole in your pocket gets larger and larger.

For most that’s just not sustainable. Sooner or later you’re gonna need to inspire people to join you. You’re gonna need partners, owners, motivated team members. A little contract work is never bad when you’ve got people who can maintain, manage, and build the product where it leaves off.

Only One Way Out

In the end, you’ve got just one path ahead. There’s no other way around it. *You have to inspire.* You can learn to code. You can learn to design. You can learn to hustle. You can learn to do a lot of things. But all of them should be mere tactics to your end goal: inspiring others to believe in you, your vision and your product. That inspiration needs to be so strong that they leave everything they’re doing to jump on that life raft with you to start paddling.

It’s insanely hard. It’s insanely crazy. And it’s insanely rare.

But it’s possible. May the odds be ever in your favor.


[0] I started off with the Head First Programming book. I then moved on to Google’s Python Class and MIT’s OpenCourseWare class. I also used Think Python, Learn Python the Hard Way, and Dive Into Python as additional resources. Most importantly, I used friends and the interwebz to get through snags.

[1] It’s not like riding a bike where once you know it, you’re done. I have a good foundation of understanding to work from… but I still have so much more to learn. I’m confident in my ability to learn and progress though. Something special about having ideas and also being able to execute on those ideas.

[2] The entire app would crash when more than just a few people would use it. It was incredibly unstable and shaky. We’ve since had to rewrite and gut the entire thing now that we have experienced engineers — which explains why we’re still in private beta. Nonetheless, I’m still contributing and love it.

The Other Reason For Launching Early


Reid Hoffman once said, “If you aren’t embarrassed by what you launched with, you waited too long to launch.”

We all know the obvious reasons why: the sooner you launch, the sooner you can get feedback from real users. The sooner you get feedback from real users, the quicker you can iterate, evolve and optimize the product. The faster you optimize, the closer you get to creating a product that people actually want. No matter how many focus groups or customer surveys you’ve done, there’s only one real way to know that you’ve created something people actually care about: get it in their hands.

Those are the obvious reasons — build the Minimum Viable Product and quickly iterate until you find the product-market fit. It’s a lot easier said than done, but that’s for another post.

Based on recent experiences, I think there’s another, underrated reason for shipping early, even when the product isn’t quite ready.

Development speed.

Your product is your baby. You love it. You care for it. You want it to be great and pretty and polished and wonderful.

But when an embarrassment of a product is out there and users aren’t happy, a kitten dies for every second that goes by — that’s how you feel. You almost don’t even wanna put your name on the product. It eats at you. It makes you cringe. You can’t sleep. You can’t eat. You can’t do anything at all until your product is cleaned up and right.

You work your tail off and stuff gets done quickly. It happens much faster than had you decided to not launch. There’s a healthy pressure that happens when your baby is out there and either users just don’t care or they’re unhappy. It forces you to move swiftly. You hate to wake up everyday to the embarrassment, just staring at you in the face.

Launch early. It’s okay to be a little embarrassed. You’ll get to the feedback loop sooner but also you’ll work a lot faster. Double whammy. Booyah.