If you are remotely interested in the Venture Capital industry, “Venture Capital and the Finance of Innovation” by Andrew Metric is a must read. The first three parts of the book are fantastic and cover a broad range of topics directly applicable to those working in the field. Some of the key topics include the history of VC, structuring VC partnerships, term sheet details, preferred stock, and later round investments (series b or c). Definitely check it out.

I’ve been meaning to pickup Founders at Work for quite a while, but just haven’t had a chance. Well, I finally did yesterday and can’t put the book down. It’s a collection of interviews with founders from tons of companies such as Hotmail, Adobe, Apple, PayPal, Blogger, TripAdvisor and the list goes on and on. Interviews are really nothing out of the ordinary. The book is compelling because it takes you back to the early days of these companies and exposes the reader to decisions that entrepreneurs had to make. It also humanizes the process of starting a company and inspires would-be entrepreneurs to plunge into the unknown.

After reading numerous interviews, commonalities started sticking out. Almost every company had no idea what they doing when they first started. In fact, most teams were nervous about figuring out what would work, but they all were either lucky or smart enough to recognize that early on and adjusted as necessary. We are talking major (e.g. Flickr halting all development on core game product and focusing on photo sharing) changes not incremental. Most startups also struggled with scaling and performance. This isn’t a big surprise. The products and services were usually thrown together quickly and haphazardly just to see what works. Once successful, it was now time to scale. The problem is that your codebase isn’t scalable so it needs to be re-written and hardware must be added. All of this while your site is bouncing up and down from exponential growth. Here’s the catch. If the startup would have designed a scalable infrastructure from the beginning they might not have been successful. Why? Well, it would have taken much longer to roll out the product, thereby increasing their chance of failure. The cost of change is much higher since you’ve invested a great deal of resources to scale the infrastructure. The time you spent focusing on designing and building the infrastructure is time away from customer feedback and market dynamics. Scaling is an important problem that must be solved, but not necessarily in the beginning. First, get something out there, get feedback, iterate and pay attention to the market.

This book is a must-have for any entrepreneur. Check it out.

I just finished “Made to Stick” by brothers Chip Heath and Dan Heath. The book talks about why some ideas “stick” with us and others don’t. Ever heard of the story about someone who woke up in a ice-filled bathtub after getting their kidneys stolen or about Jared from Subway or the catchphrase from the Clinton campaign “Its the economy, stupid”? These are all examples of sticky ideas that we somehow seem to remember. The brothers come up with 6 key characteristics of sticky ideas (SUCCES) – simple, unexpected, concrete, credible, emotional and story (to tell a story). These characteristics are important to all companies marketing products to consumers, and especially to startups. In fact, most tech startups are started by a few tech founders who have a very narrow view of the world. We (myself included) assume everyone can navigate this website or install our software without a hitch. We forget what it’s like to be in someone else’s shoes – who hasn’t been using a computer since they were 6 years old! The book refers to this as the “curse of knowledge”. It’s very important to understand your target market, put yourself in your customers’ shoes and stay focused. Without any of these things you won’t be able to even deliver a valuable product – let alone build a marketing plan. Remember, it’s easy to lose focus and get off course. Actually, the CEO’s job is to keep everyone focused and marching ahead to the same tune, but that’s topic for another post.

Lastly, Guy Kawaski has a good interview with the authors. Check it out here.

I just started reading a new book called Designing Interactions by Bill Moggridge (one of the founders of IDEO). I have to say the book is a bit daunting – hardcover and huge, but is definitely worth it. It contains tons of background on “interaction design” and many detailed interviews with the innovators behind products such as Mac OS X, Palm, the first laptop and Google. I particularly enjoyed the interview with Cordell Ratzlaff. He headed the Human Interface Group at Apple for a number of years and was responsible for creating the Aqua UI behind Mac OS X. Definitely check it out. Thanks to my bro for sending me this book.

I’m not much of a fiction reader, but I recently read “The Traveler” by John Twelve Hawks and loved it. What a great book. Action packed with a nice mix of technology and conspiracy. The story is very similar to the Matrix. It revolves around a Harlequin named Maya. Not to get to much into the story, but Harlequins are protectors of Travelers. They are raised to fight and are experts at everything from guns to martial arts to knives. Maya is definitely a badass. Read the book. You won’t be disappointed.

I’m about half-way through Al Gore’s book called Inconvenient Truth. So, far I’m enjoying it and learning something along the way. I’m not your typical “save the world” enironmentalist, but I think it’s important to understand how are actions as a species affect the earth. That being said, I don’t buy totally into Al Gore’s mantra and moral values argument. Just give me the cold hard facts. At the same time, it’s really nice to see someone put their heart and soul into a cause. In life, we all strive to find out why we are here and make the most of the time we have. That’s why family, friends and doing what you love matters so much. Clearly, Al Gore has find his. Hopefully, I’ll find mine.

Getting Real

I just finished a book called “Getting Real – The smarter, faster, easier way to build a successful web application” by the folks over at 37 signals. The book is mostly a collection of best practices that the team has built up over the years delivering products such as Ta-da List, Backpack and others. I highly recommend this book to anyone building a web application – especially those using RoR. There are some great takeaways for entrepreneurs and software developers out there. Here are the ones that I found most insightful.

• Stay small and agile.
• Iterate on your product and keep your cost of change low
• If you can, fund yourself. Don’t take outside money. Be creative.
• Keep your code simple as possible. Remember, you are going to change it many times. So, the simpler the code the easier it will be to change.
• Build the product with core features only. Anything that is not essential – remove.
• Meetings are toxic. Yes, it’s true! I used to work at a Fortune 500 financial services company and had meeting after meeting all day long. In fact, any work I did was before 9am and after 5pm. It was ridiculous.
• Build the UI first. Sketch it out on paper then do the HTML. Don’t write any code. This is a tough principle to follow, but don’t waste time writing code. Build the pages and let people see them. Get feedback and repeat until you have a clear picture of where you are going.
• Beware of the bloat monster!
• Forget functional specs and other useless documentation. Yeahhhhh!
• Promote your product pre-launch. Use blogs and become active in the online community early.
• Make developers do customer support. This is a good rule to follow b/c it lets developers get feedback from the people using their software, but is tough given there are only 24 hours in the day. If you have a few developers allocate the calls between them.
• Execution is everything. You can read all of the books in the world and know everything there is to know about starting a company, but in the end you still need to execute.
• By and far, people are the most important ingredient in building a successful product and company. I’ve been saying this for quite sometime.

Joel Spolsky published an article a few years ago called “The Iceberg Secret, Revealed” that focused on how software is similar to an iceberg. You know how an iceberg is 90% underwater? Basically, the premise is that the same holds true for software – 90% of the programming is unseen or “backend” and 10% is the user interface (actually less if you take bug fixes into account). The secret is that non-programmers don’t know or understand this. I can’t agree with this more. Most users will look at your wireframe or prototype and assume you are almost done, when in fact you probably just quickly threw it together in a matter of hours.

The reason this is so “near and dear” to me is that I’ve been on both sides of the fence. I grew up without a computer and actually didn’t have one until my junior year in college. I only went into CS b/c I needed to get a job and my younger brother was always into computers as a kid. So, in that sense I’m not a traditional hacker or techie – although in undergrad I was hardcore into C / nix programming and I do have a master’s in CS. Go figure. My first few years in a fortune 500 company I spent working towards gaining end-user and business exposure – basically away from pure technology. I was always the guy who could translate the technology to management and users. Whether that be estimating tasks, production support issues, requirements analysis or actual development status. I really enjoyed this aspect of technology, but always found it extremely challenging when trying to figure out what users actually want or need. In most cases, they have no idea and neither does anyone else. The only way to really help these users is for you to understand their domain and day-to-day job function. You need to put yourself in their shoes! The important point here is not what they think the problem is. I have seen many times and been on many development teams where the users or BAs drive the technology solution. This should never happen. The BAs are responsible for figuring out the business requirements – not the design. And forget about the users. They don’t even know what the want. This problem is compounded even further with corporate procedures and politics. Let’s save that for another post.