Eastcoast Startup Week was packed with great events. I’ve been to 20 Mentor minutes last week where I met some amazing and bright people and had a lot of interesting discussions. Startup Weekend, although we didn’t manage to place top 3, was a very good experience and I would recommend participating in such an event to everyone who has even the slightest interest in the whole startup/entrepreneurial thing. The week started with some really cool talks by Tim Burke of 26ones, Dan Martell - Serial Entrepeneur, Ben Yoskovitz of GoInstant and githubber Zach Holman.
@t1mburkes 26ones is all about really rapid idea execution. The problem isn’t to get a new idea for a product. Products solve problem and as an engineer that’s basically what you do all day long anyway. Analyze your environment and look for solutions on how to make life easier. The problem is more about validating those idea. Is it worth investing more resources in an idea or should you just scrap it and start working on something different. You want to come to a decision pretty fast, as every minute you work on a dead end project is better spent working on something which has a future. The way they do it is to start out with some basic market research. Are there to many well funded competitors? Are there already 15 companies working with a very small revenue margin? Back off, on to the next product. And don’t be afraid to kill your idea. A better one will come along.
Does it seem like you actually stumbled upon something here which is worth executing? Are there competitors in the space with obvious shortcomings you can address? Proceed to the next stage where you fake the whole product, front to back. Register a domain and get your designer to build a full blown website for your product, which at this point, is vaporware. Your task is now to gain traction with your fake. If you manage to get 10 Sign-Ups, Preorders, Calls, whatever, you might be on to something. You now have unique opportunity now to talk with potential customers who want your product without having written a single line of code. Talk to them, explain that you are faking it, ask them for their input. Usually they are excited to help; Excited they can contribute to form the product to fit to their needs. What do they want? What is it they expect from the future product?. Only now you would start to implement and invest more man hours into it.
Life is to short to build stuff people won’t buy.
I found this approach to product building to be the most interesting part of the talk. He also mentioned a few rules such as Don’t be afraid of competition and Scratch your own itch but you probably heard this a thousand times already. If not, have a look at the 37signals Rework book. If you have one free afternoon ahead - read it. It shouldn’t take much longer than that to get through the book and there are quite a few interesting points being made.
@danmartells presentation wasn’t so much about technicalities but more about the wisdom you get when you are in the startup business for quite some time. Some of the more notable rules would be:
Make no small plans.
Yeah…just don’t! Dream Big. And then fail big! Because…
If you are not failing on a daily basis you are not playing a big enough game.
Probably the most used metaphor during the whole week to describe entrepreneurship was that of a roller coaster. As much cliché as this may sound, there has to be some truth to it if a bunch of very experienced people throw it at you again and again.
Really understand who your customers are.
This ties in nicely with what @t1mburke said. Do your customer validation, and do it properly. There is absolutley no excuse if you fail in this department.
Hustle to help
This one i found really nice. Whenever in the future you have a conversation goind along the lines of Hey. How’s it going. What are you working on? …. your very next question should be
How can I help?
He met his fiancé this way (after some detour) which is undoubtedly one of the cooler outcomes. And if this doesn’t happen, the worst thing that will happen to you is that you meet new people and learn new stuff.
The world would probably be a much nicer place if this would be a universal thing.
You are the average of the five people around you
This could perhaps be filed under the bitter truths section. Just look around you, with what kind of people are you surrounding yourself. If you are the most aspiring one, just watch out that you aren’t held back.
@byosko is the author of the Lean Analytics Book (you can get it here at O’Reily) so it isn’t surprising that most of his talk centered around the topic of analytics and finding useful metrics for your startup. You want to know when it’s useful to just hack something out and when it’s time to scale, i.e. spend money. When you are using a lean approach you are zig-zagging towards your goal. Besides just providing the core value, your MVP also helps you to learn and understand the problem you are trying to solve a lot better. Once you have the feeling you learned enough you might consider to pivot. Which is usually the right thing to do. But the one thing you want to stay away from is, what he calls, the lazy pivot. Don’t go the easy way or pivot to what you think might be the best solution. Focus! You have a business goal and analytics help you to move towards this goal. You just need to learn to set them up and read them properly.
Commonly tracked metrics, “Likes”, “Followers”, “Page Hits” you are probably using? Yeah sorry, they are bad. They are Vanity Metrics. Do you actually have a goal with them or is more just better? Draw a line in the sand so you can actually make a statement if you were successful or not. Change your actions according to those metrics.
A metric which doesn’t change the way you behave is a bad metric.
Track everything but focus on one thing. And then A/B test the shit out of things.
You can distinguish between leading and lagging indicators. The number of complaints for example is a leading indicator. If they go up, churn will inevitably follow if you can’t remedy the root cause for your customers discontent.
The last talk and also the one I was looking the most forward to was by @holman
He talked about the working environment you can find at Github. As since they were founded, not one person has left Github (though a couple were left) they have to do something right. The key is to work asynchronously. Work on what, you want, where you want, when you want. This is pretty easy to do when starting out but as you grow gets harder and harder. If you build your company around this principle, not only is this a very good tool to keep employee satisfaction high but it also makes hiring a lot easier. Easy to see as you aren’t bound by geography when you make your hiring decisions. There are a couple of tools to make this work. Perhaps one of the most important is to make all information accessible. Put it in a wiki, build your own stuff, just find a way to keep everyone updated on whats going on. Github for example uses a lot of chatrooms for the communication between individual employees. A nice side effect of this is that you don’t get pulled out of the zone constantly as it may happen when working in an office. To code is a creative endeavor and you can’t enforce creativity. Oh, and it helps you to avoid meetings. No one likes those, right?
If tapping someone on the shoulder instantly makes you a jerk, having a meeting is probably a crime.
To avoid lock in of knowledge into teams you want the repositories to be as permissive as possible. Of course, teams will center around certain features but if someone wants to contribute to something different is is certainly allowed to do so by sending a pull request. Internally, almost everything works by sending pull requests.
Another thing is the side-project culture, which is valued very highly. While google, as far as I remember, mostly abandoned it’s 20% project, at Github you are very welcome to work on stuff you are interested in. A lot of the tools they are using right now started out as someones side project. Smartphone-lockable doors? Check. Distributed Music Playlist for the office? Check.
Of course this whole approach doesn’t work for everyone. There is a huge amount of responsibility for every developer to structure his own work and his day. For that reason, if a team feels it is understaffed, it goes about hiring reinforcement by itself. Obviously they know the requirements for the open position the best and chances are, they have someone fitting this profile in their circle of friends and acquaintances.
A big tech company, run by the engineers and techies without all the administrative overhead to many managers would bring with them - probably every engineers wet dream - seems to scale remarkably well. Even now, with over 150 Employees Github does a pretty good job at keeping being as awesome as always.
By the way: Holman blogged about this exact topic, it’s a pretty interesting post and you should definitely hear it from the source. You can find his post here.