There are lots of examples of startups that failed due to moving too slowly. The problem is that you probably won't know about them because they often don't get multiple rounds of financing (and hence don't make the news). Uncountable numbers of startups fail all the time in relative obscurity.
Your question is hard to answer, though, because it depends on where your funding is coming from. Part of your pitch for your business probably included an exit plan (if it didn't, then you should probably figure it out now). You need to get your business to wherever it needs to be to deliver that exit plan. Now you work backwards. What conditions need to be met to make that exit work? For a business that is built mostly on technology, what do you need to have in place to meet those conditions. Then you need to allow time to iterate your development because I can pretty much guarantee you that whatever you think you need now is almost certainly wrong. So you need to deliver early enough to allow yourself time to figure out what is wrong about it and what you need to do to make it right.
I've been in this industry long enough (and been with enough startups) to say that most founders don't understand what they are doing to the extent that they can make a coherent plan. Therefore they simply push to move as fast as possible and "pump out features". This is not necessarily a bad strategy if you are good at reacting to failure and adjusting your plan accordingly. The faster you fail, the more time you will have to discover what will succeed.
This strategy will only work for so long, though, and you need to be able to change your strategy at the correct time. This is very difficult and my experience tells me that most people get it very, very wrong. Sometimes even if the founder can do it, the people they hire to search the solution space (by banging out features one after another) are incapable of building a coherent product. To off-set this problem some startups adopt a demo-only strategy. Their goal is to build a disruptive demo and get bought out by one of the big boys (and probably buried). They have no intention of actually building a viable product. This can actually work well, depending on the prevailing economic environment and how scary you can make your demo.
If you want to build a sustainable business, though, my suggestions is to avoid the "pump out features" track (and the developers who are good at only doing that). Instead build more slowly with very strategic experiments and a very flexible code base (along with programmers who have experience building real products this way). If you can find the programmers who are able to do it, then you should have a higher rate of success. The "if you can find the programmers who are able to do it" part may be limiting, though. You may be forced to go the "bang out features and react to failures" route.