According to Seth Godin, the proven way to add value is to "do extremely difficult work." I agree with the sentiment, and in software development, teams are regularly asked to develop features they have never created before. The work is complex and requires some learning. I've written before about using spikes for learning, and Johanna Rothman wrote a very nice article on the same topic. I love that she goes on to explain what should happen to the code written during the spike:
You can throw out the code. You can use the code as a basis for real development. Or you can refactor the code to get to something reasonable. It all depends on where you start. Any of those will change the estimate of how long the rest of the work will take.
The team is ultimately responsible for quality. If the team needs to do some upfront learning, then use a spike. Just don't be fooled into using that code afterwards if it's not the right thing to do.