The terms "proof of concept" and "prototype" are so similar that you should probably ask your managers what each of them means in the context of your company.
I've worked in a few places where proofs-of-concept, prototypes or whatever you want to call them are used, for different reasons:
- to understand a technical risk, such as the performance of a product or its ability to integrate with external systems.
- to evaluate different technology options for later selection e.g. choice of web server or database
- to demonstrate how the product might work with a view to informing UX, design and business decisions over its features.
Notice that in each case there's a clear done-ness to the work: you have useful performance numbers. You have a justified choice of database technology. You have a usable prototype. That means that work on the prototypes or proofs-of-concept is bounded. It's usually also time-boxed (matching with the concept of a research spike in iterative development) so you agree what the problem is you're trying to solve and how long you've got to explore the solution.
Typically the PoC is "one to throw away"; it's built such that you can get something working quickly on your box to show that it can be done but it's not actually going to be part of the finished product. You might use the code to guide your production implementation[*], or you might just take what you learned and build it again from scratch.
[*] Where I'm using the proof of concept to learn about an API, I sometimes take the things I learn from the PoC and write them as unit tests. Those tests can be part of the real product's test suite without copying PoC code into production.
- you quickly learn whether what you want to do is achievable
- you quickly learn whether what you want to do is desirable
- it can be hard to argue that what you're doing adds value when it isn't going into production
- seeing the PoC functioning, even if it's smoke and mirrors, can lead to a false illusion of progress when you demo it to other people.