Commercial Failure, Experiential Success

I know what you did last summer. Well, ok: that’s not true. But I do know what I did last summer: I tried my hand at a software startup, fell on my face, and learned a ton. Here’s the story:

It is January 2011. I am in Durham, NC, on co-op at Digitalsmiths, pretending to attend Duke University. In the cocktail hour before an entrepreneurial speaker at a campus event, I meet Kirill Klimuk, a freshman computer science major. Standing over a big bowl of chips and guacamole, acting as a scout for .406 Ventures looking for hotshot hackers I ask Kirill what he’s up to. He proceeds to explain what sounds like one of the craziest ideas I have ever heard: concocting some sort of web of information, making it easier for people or organize and share data online, and a whole bunch of other jargon. I have no idea what the heck he’s talking about. However, something tells me he’s special. So after the event I track him down and send an email inviting him to dinner.

We meet at 6pm on a Sunday evening at Panda Express on Duke’s campus. We end up sitting in that restaurant for 6 hours straight.We talk about everything from our childhoods, to our obsession with Legos, and the intricacies of this very clever idea Kirill had. The basic premise of the idea is that there is a lot of information content online (news articles, blog posts, etc) and we’d filter out the uninteresting stuff and only show people the content that they actually care about. At around midnight we leave, shaking hands as business partners in this new venture. 

Now, we weren’t signing contracts or NDAs: we were just two students working on a project. So we meet every Friday, Saturday, and Sunday night while everyone else was out partying. We would sit in front of whiteboards from 5pm to midnight putting together the components of our product to make it work like a well-oiled machine. Working was glorious intoxication: we loved it and couldn’t get enough of it. We had a mission: to be a destination website where people could go to discover every topic from technology to mountain biking. One night we stayed up until 3am, filling the room with diagrams, outlines and mockups of our baby, which we called Quiree, after inquiry (a search leading to discovery). It couldn’t have been any more fun.

We did this all semester and all through spring break. At the end of the semester Kirill’s classes ended and so did my job, so we decided to walk away from high paying tech internships and work on this crazy idea full time, all summer. We decided we were really serious about the company and incorporated it to protect the IP, working with a great startup lawyer in Chapel Hill, NC. My parents, as crazy as they are, agreed to let us both live in their house in NY. So sure enough, I came back from co-op with a Duke student to live in my parents’ house in mid-May. 

We settled in and made a rigorous schedule. We started work around 9:45am and ended work around 11:00pm every day, with a couple of breaks for lunch, dinner and sanity. We did this 7 days a week.It was madness. As the weeks turned it to months, it became more and more challenging to keep up our insane work ethic. No going to the beach, no enjoying summer, or being kids. We were crafting code, graphics, and layouts like gears churning in a engine, without an off switch.

It was finally the beginning of August, and we had finished our website. It was amazing: we built it! Everything functioned just as we had drawn it out on the white boards months ago. It was still a minimum viable product (in our eyes at least), but, man was there a lot to it. Bells, whistles, the works. Features stacked up like a skyscraper and the instruction manual thickened with guidelines of how to use the product. We started sending the link out to our friends and colleagues to try out. They gladly signed up, looked around for about 60 seconds, left and never came back. 

“Oh, crap” we said. Realizing that there were a ton of flaws that we could quickly identify and repair, we set out to iterate and create the next version to release again in a week. We cranked it out during the week and sure enough pushed a new version out. It was a big improvement, butusers still did not seem to understand it or want to use it. Maybe it wasn’t social enough? So we added more Facebook and Twitter integration, more opportunities for users to interact and discuss topics they were interested in and comment on news content. But again, people tried it and left, not really giving it a chance or understanding what it could do for them.

At this point it was mid-August. School was going to start soon, and the project looked like it needed to a major pivot that would require massive re-coding. Kirill and I were so tired that we could barely lift a finger. Our spirits were down, our energy depleted, our enthusiasm at an all time low. Suddenly, going to class didn’t seem so bad at all. At that point we made a choice to put our product on the shelf, and so ended the story of Quiree.

What did we learn?

1. Simplicity

Products MUST be simple. The best software product is a button that does one thing the same way every time. Our product had 50 buttons that were color coded and felt like an airplane cockpit command center to most of our users. On top of that, the interface was so busy that users didn’t understand what they were looking at. You need to be able to sum up in one sentence what your product is, and it needs to be in clear, simple language. Ex: “My product is a software program where you can voice and video chat with your friends.” - Skype. Or, “My product is a website that teaches you how to code.” - Codecademy. Simple, simple, simple. 

Here’s a guideline to simplify your product. Dream it up, write down all of the features you believe are necessary. Now, ditch half of them. I mean it, ditch them right now. And now, cut the amount of features left in half. There: that is your minimum viable product. Seriously. It needs to be MINIMUM, the absolute bare essentials. 

2. The user is LAZY

One of our biggest mistake was overestimating our average user. My partner and I are technical guys. We build software and understand its intricacies. But the average user doesn’t always realize the most basic aspects of navigation on the web, like the issues of using the browser’s back button from within a web application. Your product must be so EASY to use and so OBVIOUS that the user does not have to exert energy trying to figure it out, because I assure you that they will not. Instead, they will simply walk away from the product.

3. Design and User Experience (UX) are key

Neither my partner nor I were great designers. It showed: our product was ugly. There are some really beautiful products out there that place a great emphasis on design, like Zaarly. Do yourself a favor: have a design co-founder on your team or hire a top notch firm like Bionic Hippo to consult on UI/UX. If your product is not appealing to the eye and warming to the soul, people won’t want it. 

4. Pivot quickly

If a software product takes 4 months to code, you are probably doing something wrong. Get something out quickly (i.e. in weeks), get user feedback, and test again. We spent way too much time on our first iteration. Adapt to what your customers want and be willing to completely change your product or business model to suit the needs of your customers. There is zero room for stubbornness in web software startups, especially targeting mass consumer markets.

5. Partners will fight

You start out your business loving your partner. You are best friends; all is sweet in the world, etc. I promise that at some point in your career, you will fantasize about smashing your partner’s head into a telephone pole. It is ok; it is normal. Remember, you are all people. You have your own opinions, desires, and agendas. You need to learn when to give each other space, when to compromise, when to take a stand, and when to back down. Most importantly, you need to act like a decent human being, otherwise nobody will care how smart or skilled you are, and they won’t work with you.

6. Cost control is good

My partner and I lived for free in my parent’s house (and ate their food). Luckily we were young enough to be able to play that card. At the end of this adventure, we lost very little money. We spent a lot of time, but we also learned a lot. Our costs were incredibly low. Position yourself the same way.

7. Code, code, code

We learned a ton about coding through this experience, and anyone who tries to attack a similar venture will too. I became comfortable with JavaScript and my partner had PHP shooting out of his fingers. 

8. Product management

It is really easy to get picky on details of the product. Don’t do that - it is not important in the beginning. Whether the icon is blue or orange doesn’t freakin’ matter. What is important:do people understand your product? Is it easy to use? Does the basic functionality work properly? Can you easily scale it when the time comes?

So, that is the story. It was a magnificent summer and I learned a huge amount. I’m very glad I took the plunge to make our crazy idea a reality and despite it being a commercial failure, it was certainly an experiential success.

Thanks to Kirill Klimuk for his input on this post.

10 Ways to Identify Great Developers

“Developers, developers, developers, developers.”

We all know the quote from Steve Ballmer and the classic video of him showing his support for Microsoft engineers.

Ballmer’s quote holds especially true today as startups and Fortune 500’s alike viciously compete to acquire the top programming talent. This means that identifying and recruiting world class software developers is not only crucial for tech companies, but also more difficult than it has ever been. 

Throughout my experience as a web developer, entrepreneur, and Student Fellow at .406 Ventures, I’ve met amazing software developers. Here is my short list for finding the great ones: 

1. Ability and willingness to learn

I don’t care how much you know right now. Instead, I care how fast you are able to learn new technologies, adapt, and implement them. My partner last summer came into the venture as a PHP novice. The code he wrote the first month was clunky. However, he loved learning to improve the code, absorbing pages of the PHP manual like a sponge. Within months, he became a sharp PHP wiz, re-building the old code in hours even though it took him days to first write it.

2. Passion for problem solving

Writing software is all about solving a problem. Any great programmer must have that innate passion for solving problems, boldly taking on challenges and ultimately conquering the unknown.

Maybe they solve the 6 Rubix cubes on their desk in under a minute or they spend every morning manipulating a Soduku puzzle. Either way, having a knack for problem solving in an efficient, salable, and manipulable way is paramount.

3. Logical and mathematical thinking

At a very basic level, any software program is a series of commands (logic) that goes through situations and takes some sort of action based on the situation. For example: IF it is raining THEN I’ll take an umbrella ELSE I won’t take an umbrella.

Great developers will many times think, speak and act in similar ways that they program. If I videotaped some of the arguments my CTO and I had, I bet we could easily transcribe them into basic logic arguments and turn them into a web app. Look for people that love math and logic, those skills translate well into development.

4. Flexibility

If a developer seems married to one programming language or stack, run away. It might be Ruby on Rails today, Python and Django tomorrow and picking apart some Node.js or Scala next month. Once you understand the fundamentals of Object Oriented Programming (OOP), it is fairly simple to go in between these different languages. You want someone that is flexible, a jack-of-all-trades in the programming world. They don’t have to start out this way, but must have the willingness to learn and explore at a rapid pace.

5. Readiness to re-code

When I was was first learning to program, it drove me nuts that I had to constantly re-do work. But that is the nature of the beast: as you learn and get better, it is essential that you optimize whatever code you are working with to function at its best, and unfortunately that usually means scrapping old code and starting from line 1. Any experienced developer knows this, and they need to be ready and willing to re-code when necessary without grumbling about it. I was a grumbler, and I learned fast the error of my ways.

6. Being a team player

Every engineering team is just that, a team. There are multiple developers working towards the same goals and writing different parts of the same application.

That means you want someone who doesn’t mind picking up where someone else left off, deciphering someone else’s code or comments and ultimately working in a collaborative environment. Developers that go with the attitude of “mine mine mine!” are probably not going to be a good fit.

Make sure they take this very seriously, even if it’s a team of 1 right now. 

7. Playing well with non-techies

Any strong startup team is not just made up of developers. There are designers, business people, and investors, just to name a few. The engineering team must be comfortable working with other stakeholders in a cross disciplinary environment. There will be project managers and product folks suggesting ideas for the product, which at times might be unfeasible or simply wrong.

I want to hire the engineer that doesn’t criticize or shrug off a flawed proposal, but instead takes the time to explain the problem to decision makers that might not have a technical background.

8. Code formatting

When most developers start out, their code looks like crap. Nothing is indented, views mix with business logic, and the madness goes on. A good developer quickly learns that formatting code well so it is readable and properly commented is very important. When responsibilities shift, it makes a world of difference for engineers to be able to look at code and understand exactly what it does and what other pieces of code it interacts with.

9. Emphasis on documentation

In addition to clean formatting of code, having proper documentation can make everyone’s lives a lot easier when code needs to be reviewed or edited down the road. Keeping a log of every function (along with its parameters), file, and database table is a great habit to get into. It is not as annoying as it sounds, and the consequence for not doing it is a guaranteed headache when you have to sort through 50 files to figure out what 5 little lines of code do.

10. A fun, hardworking, good person to be around

I follow the golden rule of “do not work with assholes.” I don’t care how much of a code master you are, if you’re not nice to other people in the company, if you put others down, or don’t respect authority, then you won’t work with me. I’d much rather train a hard-working, smart, and fun new developer then a self-labeled expert that is rude or arrogant. Choose your team with this rule, hire slowly and fire quickly when there is a culture problem.

If you need to figure out how someone’s going to treat the other people in your company, take them out to a meal or two. When you get a chance before you order, take the waiter/waitress aside and ask them to bring out the food either late or slightly incorrect. Then, see how the engineer reacts to the situation. Do they complain or talk beyond the server’s back? Or do they politely communicate the problem like a nice, understanding human being?

Every startup is going to have ups and downs, and if someone loses their cool at a minor issue in a restaurant, you might not want to be rely on that person when it’s crunch time and you’re a month away from running out of money. 

Are you ready to become a great developer? Awesome! Here’s what you should do:

• Get on Codecademy: It is the hands down best place on the Internet to learn how to code, co-founded by my friend Zach Sims.
• Get some books: I recommend ones like the PHP Cookbook that walk you through every key area of the language and provide a ton of real world examples (with real code) to play around with.
• Start hacking: Play around with code. Make up an idea for a mini application and hack it together piece by piece. It’s going to be clunky - that’s ok, you’re learning!

Good luck!

Thanks to Kirill Klimuk and Drew D’Agostino for their input on this post.

How to Choose a Great Startup Lawyer

As you are venturing into uncharted territory building a startup, having the proper legal protection and organization is not at the forefront of every entrepreneur’s mind. But after all of the building and planning and coding, making sure that your IP, partners and company are protected is absolutely paramount to ensure smooth sailing when you hit it big.

As you are seeking out a firm / lawyer to work with to form your corporation and initial IP protection documents, consider the following:

• Does the lawyer specialize in startups? 
• Does the lawyer have a strong track record in representing successful entrepreneurs?
• How involved are they in the entrepreneurial community?
• Have they ever started a company themselves or been deeply involved in a startup?
• Are they willing to defer fees until you raise capital?

Additionally, you need to consider how a lawyer is going to treat you. Do they have tons of clients that will get more attention than you?

For my last startup, I worked with Glen Caplan and John Fogg of Robinson Bradshaw in Chapel Hill, NC. They hit the nail on the head with every point I described above. I knew I was in good hands based on the following:

• Prompt responses: when I emailed Glen or John, I get a response back generally within an hour. 
• Insightful responses: when I asked a question, I didn’t get back a bunch of legal jargon. Instead I received detailed, insightful responses in language that I could understand.
• Culture fit: these were guys I would invite over to a BBQ… genuinely nice people that are a pleasure to work with.

Ultimately, you need to find a lawyer that is competent, values you as a client, and is someone that you can trust. And remember, it’s much cheaper to get it right the first time as opposed to cleaning up a legal mess later!