When was the last time you did a Proof-of-Concept (POC) ? Not sure - well let me pose another question...When was the last time you embarked on a technical project/task that had a considerable degree of risk in it?
IMHO one of the primary responsibilities of the project stakeholder is to mitigate the risk associated with the technical components of the business. Let's think about that for a minute. What risks are there, and how do you mitigate them? Well apart from the obvious and well documented issues like high availability, application scalability, disaster recovery, data loss, security breaches, project overrun, etc one risk that impacts on the engineering team is the occasional, or often, reliance on 3rd parties for significant components of your technical offering.
Sure, your engineering team might by LAMP/.Net/RoR domain experts and are very comfortable working in an agile environment with AJAX-y interfaces and all the bells and whistles of modern "web 2.0" applications, but as time-to-market is important and in a world where open APIs and SaaS are becoming more prevalent, invariably you'll eventually want to integrate with other service providers.
Building in this dependency on an outside party inherently poses a risk that you want to assess before making a commitment to go that route. In some cases the risk is easily assessed by reviewing the subjective feedback and experience of others. In other cases the risk is harder to quantify. e.g does the operating system and firmware of smart phone W from telco X enable you to do feature Y using language Z ? A java/brew/symbian domain expert may know the capabilities of the language/platform but it's unlikely that they will be familiar with the latest offering from Nokia or Apple, and the restrictions (if any) placed on the phones by a given carrier.
Regardless of the domain expertise you think you have in-house, it's often prudent to commit to a POC to mitigate the risks introduced. When you think about it, the POC is really the first step in any project that involved dependency on unproven technical components. If it's not, then be aware that the risk you are exposed to is carried much later in the development cycle and therefore becomes more expensive, or impossible, or mitigate late in the cycle.