Tag Archives: product development

Speaking of India: Five Lessons on India-Based Product Development

One of the interesting new challenges I faced when I joined Host Analytics about 5 years ago was working with an offshore development team in India.  Host was originally co-founded in both the US and India, so literally from inception we had employees in both places.  While this has proven to be a huge advantage for us in the market, I learned a few important lessons along the way that I thought I’d share in this post.

Lesson 1:  Read Speaking of India.

When I lived abroad in France for 5 years (which I’ve written a bit about, here), my team discovered a book, French or Foe, that we gave to every new expat when they arrived.  The book explained many important basics of language and culture that we referred to frequently as we tried to make sense of our day-to-day experiences.

Consequently, the first thing I did in approaching India was to search for a book to help me.  I found a great one, Speaking of India, which is all about communications (and how they go wrong) between people from US and Indian work cultures.

For example, see this excerpt which demonstrates “the Indian no” (i.e., the absence of saying yes) in action.

MARIAN: I’m fine, thanks. I was wondering, Kumar, what you would think if we decided to move up the date for the systems test?

KUMAR: Move it up?

MARIAN: Just by a week, at the most.

KUMAR: I see. Do you think it’s possible?

MARIAN: Should be. But what do you think?

KUMAR: Me? I guess you don’t see any problems?

MARIAN: Not really. My people can be ready at this end if your people can be up to speed by then.

KUMAR: I see.

Kumar is basically screaming no here while Marian might very well be hearing yes.

These kinds of misunderstandings are common and if you teach yourself listen appropriately then you can actually hear what is, or in this case, is not being said.

You’ll learn this — and much more — in the Speaking of India.  And you can learn some unique Indian-English words/expressions (e.g., a fresher) as well.

Lesson 2:  Show Up.

It’s hard to get to India.  From San Francisco, it’s 16 hours to Dubai and then 3.5 to Hyderabad (or 14 hours to Hong Kong and then 6 hours to Hyderabad). It takes me a full week to get about 3.5 days of actual work time there.  And let’s not even talk about the 12.5 to 13.5 hour time difference.

But that’s the point.  Because it’s hard, too many people don’t do it, preferring conference calls at odd hours over noisy telephone lines.  If you are serious about your India development center and the people in it, then you need your top executives to show up — at least a few times per year — to get to really know the people and the work environment.

I go three to four times per year with a agenda that typically looks like:

  • A large number of 1-1 meetings
  • Attendance at a few regular group/team meetings
  • A few special, topical meetings
  • An all-hands meeting at the end where I report back on what I’ve learned
  • A few dinner / drinks meetings along the way

Remember the old Woody Allen quote, 80% of success is showing up.  It’s a great rule to follow when thinking of your India development team.

Lesson 3:  Think of Product Management as a Giraffe.

I first came up with the giraffe analogy when I was at Business Objects in Paris.  While our development team (the body) was in France, we needed to have our eyes and ears in the US market if we wanted to be globally competitive.  Hence, product management needed to be the long neck that connected the two.

Concretely, this means you need to staff product managers in both locations, typically putting a greater number of more specialized product managers (PMs) in the USA and a lesser number of more generalized PMs in India. This means your PM investment might be higher than it would be with a co-located model, but it’s worth it.

Some people believe you should call the US-based staff product managers and the India-based staff product owners (POs), but I prefer to call them all product managers.  The reality is the job will inherently be different as a function of location — the USA PMs more customer-facing and the India PMs more engineering-facing — but in the end they are all product managers in my view.

Lesson 4:  Do Real Work.

The fact that we build our core SaaS offering in Hyderabad is a big attraction for talent.  Too many companies use India to do only lower-value work (e.g., porting, localization) which sets up a self-fulfilling prophecy of getting lower-quality talent.  We have found that when you do real work in India — core, critical stuff — that you will have a much easier time attracting talent to do it.

Lesson 5:  Do More Than Development.

Finally, we’ve increasingly been leveraging our footprint to do additional work — such as customer support, customer success, professional services, and even some marketing — which helps transform the environment from purely a “development center” to a generalized satellite office.   This is great because it provides developers and product managers with more direct access to the business — because people in other customer-facing functions are working right across the hall.   Practically, this helps with 24×7 operations (e.g., techops, customer support) as well, where we can provide customers with round-the-clock monitoring and services without having to ask too many people to work the graveyard shift.

I hope you’ve learned something from my journey.  Please feel free to share lessons from yours.