It's been a while, but back when I was doing a series of summer internships at Netscape, the project was struggling to ship a browser (Netscape 6, and then better releases after it) based on the Gecko layout engine. One of the lessons I learned during that process is that having the people working on a product actually use it is a huge help getting that product to ship. We tend to call this dogfooding, based, I think, on the idea that dogs aren't known as picky eaters, and the idea is that someone who's dogfooding a product is using (eating) something that's barely usable (dogfood), because that's what moves the product towards being more usable.

Dogfooding is not a way to get people not previously involved in a project working on it.

Dogfooding is a way to make the team building the product more informed about what's important. It means that decision makers (those doing bug triage and those making higher-level decisions) can understand from their own experience what is or isn't a serious problem in the product: which problems need to be fixed for the first release versus which can be fixed later. It means that engineers who are working on a product will notice the easy-to-fix but noticeable problems in the code that they're working on, and just include those fixes when they happen to be working on that code. And it means that the people making decisions about whether the product is ready to ship have an idea what using the product is like.

Perhaps most importantly, dogfooding is a way to shift the development cycle away from the (often endless) task of building items on abstract requirement lists and instead focus on fixing the things that are needed to make the product usable for real users.

People working on a mature, existing, product often take it for granted that they understand what it's like to use the product they work on. Dogfooding is the somewhat painful path of getting a product that isn't yet broadly usable into that state.