Many projects and products fail before they even start to deliver. They are setup to fail. They make promises, up front, that rely on faith and finger crossing, and so, sometimes they fail. That's simple statistics.
Some don't.
1 - A couple of days ago Google announced a few very minor functional improvements to gmail* and the media went crazy. Today Apple is going to do something new with their iphone - the media has been going crazy with anticipation and will no doubt go daft for another week or so after the announcement.
Both of these companies are making a different type of promise: they're promising to WOW you every so often, but they're not being specific about how. That promise leaves them plenty of wiggle room - neithor the press nor their customers can say "but they failed because they said it would be red, but they only delivered black"; they can drop or delay entire features (entire products, even) as it suits them, so long as they deliver on their bigger promise to WOW! you.
It's far easier to WOW! if you have wiggle room.
2 - Last year I worked with product company which consistently disappointed their customers by making firm commitments, way in advance, about what they would deliver ... but then never kept those promises. Their customers weren't silly and they took the promises with a grain of salt never expecting anything to arrive on time or in the form promised. The customers had learned that it was safer for them to have very low expectations, to always be a little disappointed, rather than a lot disappointed.
They never expected to be wowed! They always expected to be just a little disappointed.
3 - I failed in that company. I briefly managed one of their releases (for about 3 weeks, as a favour) while they were recruiting someone to Project Manage it. During that time I helped the project's owner to see that making firm, detailed and confident sounding promises to his customers, that still required everyone to cross their fingers was worse for his customers than making less firm, less detailed, promises that they customer could still plan around.
I helped him to rewrite the standard "pre-release notice" which went out to his customers so that it unambiguously promised the project would prioritise the work-packages and would only include the lower priority features if there was time. He bought in to the idea, but by the time the release notes had travelled around a number of internal departments, the the language had been watered down so that the promise was once again very firm and detailed, but it had an ambiguously written "get out" clause.
So I failed. If I'd done a better job then I would have helped him to argue his case better, but I didn't. I was disappointed at the time but, in retrospect, the only person I failed was me. I'd promised myself that I'd wow! the guy but all he really wanted was someone to baby sit his project for a few weeks. In the end that release came in very late, just like the one before it, and the one before that. The customers got what they expected and they were only a little disappointed.
And you know what? My solution wouldn't have worked anyway. One of the highest priority features, which was about one third of the total effort, took roughly 4 times more effort than estimated. They need a slightly different model for that. It's closer to, but more transparent than, the model Google and Apple use. It's something closer to what, say, air traffic controllers might use. I shall write that up one day.
* It's true that the functional improvements in GMail were minor, but the whole lab concept is very clever because it allows them to conduct experiments without making commitments; they get very fast feedback (ten zillion people disabled the xyz feature today - why?) which allow them to make better decisions; if they decide to retire a failed idea (a hypothesis, I suppose) then no one is surprised.