One from my recent history: allowed sales traction to divert attention from poor user adoption. Compounded the problem by spending a couple quarters building features that increased sales traction while doing nothing for user adoption.
One mistake I've seen is over-committing to a given technology stack. From languages to frameworks to libraries to tools, what's popular/hot today may fall out of favor in the future - better solutions come out, developer communities move on and code is no longer maintained. Regardless of the technology you decide to use today, my advice would be to always keep an eye towards the future and think about how you could modularize your system in a way that allows you to swap out out pieces and easily adapt to changing (and often yet-unknown) needs.
Another piece of advice would be to sit down every 6 months with your engineering team and say, "based on what we've learned to date, if we were to build this again from scratch, how would you approach it"? In some cases, you may be able to start implementing some of these ideas into your current solution, and at the very least begin laying the groundwork for a fresh v2. We can all agree there's a big difference between building something new (fun!) and maintaining existing/legacy code (not fun!) :)
Avoid technical fads; be conservative in your technology and platform choices - no oddball languages or open source stuff that is coolness for its own sake. Stay in the safe zone of Java, C++, or C# and their stable infrastructure. Don't make unforced errors that drain energy and distract from product value. Here's the story my use of Tcl http://robertvbinder.com/what-i-learned-building-a-software-product-with-tcl/ that illustrates the point.