Product Owner: How to handle product delivery in time?

I don't think the problem is with delays. I think the problem is with making unrealistic promises of delivery.  A product could be launched at any point in time if it was providing value to the consumer.  It may not provide all of the value that is desired but as long as there is some value, it could be delivered.  Then using feedback from the users, the product will be adapted.  That is how an agile software delivery takes place. 

In your post you and Gartner are assuming that all software will be delivered in its entirety on specific dates. You are also assume that not meeting a specific date is indicative of failure.  I wonder how well the users accepted the 45% of the products that were delivered on a specifically communicated date.  How much had to be changed after that date to facilitate what the actual users wanted? 

I believe that the reason dates are missed is because that new information is gained while building a product.  In Project Management, a project plan is made based upon incomplete knowledge.  That forecast turns into a committed date.  However, when the work begins you will discover information that was not known at the time the project plan was made.  If the company is smart, they will adjust their plans based upon this new information.  That is why most agile companies will do incremental delivery and course correct using the feedback obtained.  In the end, it might take you longer to "launch" but what you do "launch" will be something that the users need at that time.  

Because they are trying to launch on schedule. The world is generally complex and it is better to inspect & adapt, managing not by schedule, but by the incremental and empirical release of value.

I don't have any hard numbers, but I can tell you what I've seen in the software world.

In efforts managed using traditional project management methods, the team tends to work in very big batches of requirements, translated into designs and implemented, tested, and then demonstrated or delivered. However, when the customers and users actually get the software, it's not what they want or need and isn't usable. They come back with a list of changes that need to happen for the software system to be useful and usable. The team then takes on that list, designs, implements, tests, and gets feedback. Sometimes the second iteration works. Sometimes the project is no longer viable - the deadline for needing the software has passed, the cost for continuing work exceeds the value. Sometimes the team tries a third time.

Agile methods, like Scrum, are designed to handle this. The team builds very small slices of the software system and gets feedback in time windows measured in weeks, months at the longest. The stakeholders - customers and users - can provide feedback and help the team adjust. Sometimes, the system under development can be used before it's "finished". Even if the customer or user had a big list of requirements in mind, a demonstration or delivery of a slice may reveal that starting to actually use the product now can help them achieve their goals. In some cases, they may even realize that they didn't actually need that big list of requirements and can end the development before the big list is fully implemented and delivered.

The biggest delay is trying to do too much work at once. Short iterations and feedback loops of small slices of functionality and usable product goes a long way to mitigating that risk. It also forces the team to address other risks earlier in the process.

According to Gartner, only 55% of all product launches take place on schedule. If so many products fail

How it is taken that schedule slippages are product failures?. I hope the report would have shown just the survey results and not a conclusion like that.