10 Apr 2017
This year I had the chance to close up on FourLeaf, a startup I’ve been working on since early 2015. Yes, I say a chance intentionally because I do believe it is an opportunity both to start and to shutdown a startup. While noone would fight to fail, failure is always the best of teachers.
I’m writing this in some parts for those of you interested in doing your own startup, but also as an opportunity to reflect on two of the biggest problems we encountered and brainstorm ways we may have potentially avoided these issues.
A product you love vs. a product that will engage a meaningful base of users. Every startup’s endless battle.
When I joined the team, we were working on FourLeaf, a networking platform for musicians… something like a cross between IMDb and LinkedIn speficially designed for musicians. As a musician myself, the idea was wonderful and I was excited to work on something that could potentially solve some of the problems I had encountered myself. We gained a little bit of traction in the LA songwriting community before quickly starting to realize all the hurdles that were in place that we likely would not be able to navigate (i.e. IMDb was unable to become a networking platform for filmmakers until it had already gained significant success as a fan driven platform)
So we pivoted. We decided we would start working on, literally, the IMDb of music. Something more for fans than explicitly for music professionals. Whoa, we quickly realized there are way too many songs for us to know how to handle. Quick pivot… we decided to focus on one corner of the market that we have some greater access to (KPop, since my cofounders had both worked in the industry). So we built out an entirely new, more KPop-fan friendly version of the site, only to discover that the more granular aspects of the site were less interesting to the average fan. They mostly wanted content that surrounded the major stars. We pivoted again to a KPop version of The Player’s Tribune, or like ESPN if you’re not familiar with TPT. We started to pickup a decent amount of traffic but then started to discover the hurdles of turning something like this into a sustainable business. Native ads?
But by this point we had pivoted so far from our original idea that it placed us firmly in a territory that none of us were that personally excited about. We went in circles a bit in this space until finally, we burned out.
I don’t think there’s a tried and true way of solving this problem, but I do think early discussions of problem scope are necessary. If you think of product ideas as a circle, there are 360 degrees of options. Pivots are inevitable, but if early on you can narrow the window to a smaller portion of that circle, I think it makes ultimately for better decision making (even if it might lead to failing faster). Our ideas pivoted in too wide of a space taking us places where ultimately in the end we realized we were unwilling to be in. Rather than pivoting 180 degrees in your ideas, just pivot 10 or 20 degrees so that your product, while it may be different, still remains within a similar scope. We justified our decisions as logical compromises, but ultimately the truth is likely that we were just settling.
Excellence vs experimentation. The neverending battle between building something you’re proud of vs throwing something out into the universe.
With our FourLeaf (IMDB for music) product, we spent a considerable amount of time (months) talking to people and developing the requirements for our product. To be brutally honest, some of the slow down was due to me being completely new to working in the webstack, but a lot of time was spent just figuring out what our product was… we even spent a whole day outside as an exercise in discovering our brand. We went through multiple iterations of design ideas before even attempting to design the site….. etc., etc. If it isn’t already apparent, we likely wasted a lot of time during this approach.
By the time we were working on MusicMind, the KPop focused product, we were operating considerably more efficiently. We’d throw out a new product, a new piece to the site, destroy it, put up a new version, all within the span of a month or two. However, what we started to see was a loss of identity and cohesiveness to the things we were doing.
A lot of people take really different approaches towards the beginning of a startup. Some of it is product dependent (i.e. some ideas are easily executable, some take forever no matter who you are), but for the nebulous space imbetween it’s ultimately kind of arbitrary as to how you decide to roll out your product. We swung both ways during the lifespan of our company and it’s hard to say which was worse to be honest. One was far too slow, the other was too aimless.
Spend time developing the ideas that are necessary. Some core components to your brand and company are in fact worth spending some time on. If you don’t know who you are as a company, once you throw your product into the wind you will definitely blow right along with it. Build the foundation slowly, but then move quick to build/break/re-make everything else.
22 Mar 2017
The parallels between the dating world and startup ideation are striking. Everyone is looking for that unicorn but noone really knows how to find it, and those that have found it ultimately just stumbled into it no matter how much they can justify their decision making.
09 Jul 2015
Over the past year we’ve had to juggle a number of different priorities in order to figure out how to hire developers. Here are a few of the important things I’ve internalized throughout this year:
Priority zero: I didn’t include this on my five tips, but have a tech co-founder BEFORE you think about hiring developers. You best bet you need a tech co-founder (unless you have a stream of endless money to hire developers from the get go). I know the mantra everyone spouts these days is “everyone can code”, and for the most part I agree with that, but the mantra also ought to include a little star next to it that says “everyone can code *if you have a ton of time to learn it”. I studied computer engineering in college, continued programming at my former workplace, and it still took me a few months to adapt to the web stack. I have to give some eprops to Ian and Tommy for trying to learn programming before looking for a tech co-founder though :)
Here we go!
Hire for “soft-skills” and culture fit first, closely followed by a willingness and desire to learn. Communication and people skills paired with teachability and passion for learning trumps a perfectly matching skill-set 100% of the time. Programming languages can be very different, but good programmers pick up new ones as necessary. Remember that at the end of the day you’re hiring someone who you might be spending inordinate amounts of time working with. Personality clashes are much more killer than someone not happening to know everything about a certain piece of technology. Also, the CS world is constantly shifting and changing. Even the best of us has to continue to learn more. The only outlandish cases where I’d say you really need to favor hiring an expert who matches your needs precisely are in development of highly specialized technologies, in which case I’d say that person should probably be your tech co-founder already :)
Outsourcing is not for the faint of heart. Unless the product you’re trying to develop is really really simple, you’re going to struggle to develop a solid product by outsourcing your tech needs overseas. This is not because overseas engineers are not talented or ill-equipped to develop a solid product, but because, again, communication skills trump all. If you can’t properly communicate your product to your engineers, your engineer will not build the product you’re dreaming of.
Be cautious with coding bootcamps. Not all bootcamps are the same, so do some research and ask around as to what kind of students a bootcamp is producing. Bootcamps are pretty dynamic businesses right now since they are a relatively new concept. Case in point: you better believe that Kaplan’s acquiring of Dev Bootcamp last year will have tangible impact on it’s quality, whether good or bad. Be fearful of bootcamps that claim to teach students everything. Typically, an engineer that’s really good at one thing can more quickly adapt to a second technology than an engineer who knows a little about many things.
Enthusiasm for your product. Sometimes people have a tendency to de-humanize engineers a bit because they like to work on robots and sometimes even think like them too. But even the most robot-like engineers are still passion-driven people, and engineers that have an interest in working for a startup even more so. They are taking a risk (and probably a pay cut) so make sure the situation is a win-win. We went out of our way to look for engineers that had a special interest in working on music products. While that made it a lot harder to find people, it made it a lot easier to know that whoever we ended up working with would be motivated.
Work on something together. Not everyone has a willingness to do this, but if your potential hire is willing, do a small project together. Regardless if the project is tied to your product or not, getting 1 week… even 1 day of experience working together is more meaningful than anything that comes out of the resume or interviews.
07 Jul 2015
My name is Chris. I am the tech co-founder of FourLeaf, and I am also first and foremost a musician. I joined FourLeaf with the hope and desire to build something that will not only help to transform elements of a broken music industry but also really add value to the countless struggling musicians in the world.
I’ll explain more about myself in future posts, but onto the nerd stuff!
What kind of web framework are you using to build FourLeaf and why?
The down side to ruby-on-rails is what I like to call the magic. That is, ruby on rails does so much for you, that it often takes a lot of googling and debugging to figure out what exactly happens when you are executing a certain line of code. Also, tied to this issue, is that customization is at times confusing because rails has a strong sense of convention over configuration. For instance, you have to be extremely careful about creating models and classes with names that mold to the rails scheme (plural, singular, etc.).