How do you....?

Replicating the effectiveness of an onsite team is hard, very hard. So when someone who's been burnt by outsourced research and product development (or has heard horror stories) asks how we surmount this problem, it gets my juices flowing.

1. There is no substitute for sitting across the table and discussing stuff. There just isn't -- no amount of video conferencing and detailed specification is an effective substitute. So we bite the bullet and spend the face time with our customers. And we take on the responsibility to document and communicate with and visit our team.
   Our approach has some unexpected benefits for our clients.The luxury of an onsite team is sometimes used as an excuse to flounder with requirements - if you can walk over to the dev guys and change your mind on a whim, there's no incentive for rigor, is there? When you translate that to the time your expensive local resources spend thrashing, the cost equation just isn't pretty
2. Your best vendor is someone who's been a customer sometime in their lifetime. I've outsourced product dev to India multiple times. Some experiences were mildly satisfactory, others plain horrible. And the difference between a great experience and an awful one are in the little things you do - not rocket science. Those little things -- we pay a lot of attention to them.
3. Most management tools suck for outsourced dev.  We've used Jira/Atlassian, Basecamp, Trello, you name it. They were nice, and passable, and we still use some of them with some of our customers. Our most effective tool? - a homegrown kitchen sink webapp that provides a single consistent interface to email, sprints + deliverables, documents, statuses and messaging. Our teams have three things they deal with - the tools/IDE's that they use for dev and testing, the whiteboards around them -- we've covered all available wallspace in our office with them, and the aforementioned webapp. Simple, effective, not confusing. And for our customers - instant visibility.
4. Each project has a rhythm. We run agile with a very simple goal - put something in the hands of the user with clockwork regularity. The operative word is clockwork. The decision whether or not to deliver once a week, once every two weeks and so on makes a big difference to the outcome. Determining said frequency is a craft, and one that we've honed over time.

There are, of course, many other things that we do - hiring great people, our approach to problem solving and so on, but from a process perspective, this is what we do to ensure success.