Creating a great product
They say most great projects originated from simple itch-scrathing. I think that is true - if you are not in the domain you are trying to disrupt, you are probably in the wrong direction.
An old piano teacher of mine told me that at one point, he had taken the 100 most successful songs of all time, and analyzed them mathematically, to try and find out a “law of success” that would allow one to write predictably successful songs.
Well, turns out nobody has found one yet. Similarly, there is no science to building a great product. Of course there is common sense, and there are best practices, much like in programming.
Initial success is way easy. I mean, fresh out of YC, how many start-ups look convincing? A lot. Three years later, how much are left that can keep up with the customer influx, deal with the codebase growing in complexity and with the occasional PR disaster? Not many.
Fostering such success requires a lot of different skills - that you can most often not cram into a single CEO, even if he is zen-buddhist. So how do you cut it anyway? I am still too fresh to tell that it worked for me, but here is something I feel strongly about.
Hire people who bug you
You want people that praise you in your bedroom, and people that are not afraid to point out things in your office.
Perfectionism has this tendency to wear out as soon as you start cashing in money. Ideals erode, because you suddenly realize you are in a situation where keeping your current income is not so hard.
In the early phase, you get to have direct contact with adopters, but two years in, who still has the time to do that? What you can have instead, however, are employees who are in contact with users, and more importantly, who are users themselves.
You want the kind of people who would rather get fired for being honest, than being silently ashamed of something fundamental in your product. Because while that may not be the best self-esteem boost, most design flaws are shallow when you have a few well-chosen eyeballs.
Job titles mean nothing
In my rather short professional career so far, I have held titles such as “Assistant Student” at EPFL, “Community Development Engineer”, and now “Head of R&D”, officially “ofmlabs team member” on my contract.
What does that mean? Almost nothing. Because every assistant I have worked with at EPFL was unique in their own way. Some were uniquely lazy and clearly contributed to the misconception people have about state workers. Others were passionate about the course, and did unpaid overtime to help students and set up projects.
There are many reasons to hire people. Some people are just plain simply very, very talented developers. I hear there is a 20x productivity factor between the best engineers and the average engineers (not the worst, the average!). Some others are just damn good designers.
Some just have this faculty to get shit done. It might not need some cleaning up, but as long as you check regularly, it keeps the wheel rolling. A start-up needs energy to run, beyond the initial rush.
Beyond competence, attitude matters - I think it is reasonable to hire someone based on attitude. With enough determination and patience, one can learn pretty much anything. You are probably better off with a motivated enthusiast than with a lazy genius.