Lesson #3: Keep It Simple
You have probably heard this so many times in different contexts. For me the lesson was about building way more than you need well before you need it. We built and built and built. We created lots of infrastructure and lots of integrations. The funny thing was that we were fighting off lots of people in the organization that wanted us to create many more and deeper enterprise systems. This is what my CEO called "getting out over our skis".
In the product we built a ton in a very short period of time and we built so much that it was hard to show the value and how it all worked. The lead engineer and I have talked about this lots of times, and if we could do it all over we would would have built half as much functionality (or less) and put the effort into user experience. This would have allowed us to get a version out and in the hands of users sooner. This is is something that Guy Kawasaki talks about in his books like Rules for Revolutionaries. Get the product out in the hands of users as soon as possible. This gets you feedback quickly so that you can rev it and get the next version out.
This was not just a product issue. We had this thought that we could sell this product online. So we built an online store with an integration into our licensing systems and community. If we had the keep it simple mentality we would have had people doing thing manually and touching every customer. If you can't scale then that is a good problem to have. This also allows you to focus on what is important at the beginning.
A great book that I read recently on this subject is Getting Real: The smarter, faster, easier way to build a successful web application from the group over at 37 Signals. If you keep it simple it allows you to do the important things really well. This is really tough. It is so easy to be in the middle of the storm and want to do more and more because you think it will make you better. You have to be constantly forcing yourself to asses this. When you think you have it simple then try and cut the complexity in half. That is a simple question that will really push you to see if you can reduce the complexity.