Category Archives: Communications

“You Don’t Want That!” — A Rant from Lance Walter on Product Management Communications

Posted on June 3, 2022 | 2 comments

While I don’t normally entertain guest posts, once in a rare while I hear an old friend ranting about something and the rant’s so good that I offer up Kellblog to help share it.  Today’s rant comes from Lance Walter, who recently finished up a four-year gig as CMO of high-flying Neo4j, and who I know from previous stints working together at Host Analytics and Business Objects. Lance has run marketing at six startups (Pentaho, Aria, Host, Datameer, Capriza, and Neo4j) and led product (and/or product line) marketing at three before that (Hyperion, Siebel, Business Objects).  Trivia point:  like me, Lance started what would be a successful marketing career not in sales or marketing, but in technical support.  This might also explain why he, as we’ll see, gets so excited about a product FAQ.  

One day, not long ago, Lance was trying to send a scheduled email (i.e., send-later) from his preferred email service — which we’ll call CoolMail  — and he couldn’t do it.  Ever the former product manager, he endeavored to figure out why.  He found this in a FAQ. 

Q: Why Doesn’t CoolMail Offer Send-Later / Email Scheduling?

PM Answer:  A client-side Send-Later implementation does not work reliably since the device may not be powered on or have connectivity at the scheduled time, or the app may have been force-quit by the user.

As a result, most apps that offer Send-Later / Email Scheduling opt for a server-side implementation where the scheduled email is stored on a 3rd party server till it is sent at the scheduled time.

Obviously this has privacy / security implications since not only do scheduled emails need to be stored on the 3rd party server, but said server also needs to be able to access the user’s email server via SMTP in order to send the emails.

While similar security / privacy considerations also apply to Push vs Fetch notifications, in our view the need to be informed of new incoming emails promptly and reliably justifies a server-side implementation in that case, while email scheduling, although nice to have, is not as critical.

Let’s say this, for lack of a better word, triggered Lance.  Keep reading to learn why and learn how to avoid some undesirable patterns in technical, product-related communications.

Over to you, Lance → 

When I saw this in the FAQ, I had to stop and read it twice.  How did I, as a user, feel when I read this?

  • I’ve annoyed them by asking for a feature.
  • I don’t deserve a real explanation, or maybe they think I’m too dumb to understand it.
  • I should be thankful they’re adding other features.

Basically, they’re telling me I’m wrong to want this feature because the scarlet widgetator can only do schmumble muck.  Not only did they tell me that I’m not getting the feature I wanted, but that I really shouldn’t have asked for it.

So do I think this is good product-oriented communications?  No.  In this post, we’ll analyze why and, more importantly, try to provide some tips for what to do instead.  

Let’s start with some empathy for the Product Managers (PMs) out there. It’s a hard, cross-functional job and situations like this, where you can’t give every user what they want are the norm, not the exception. Whether birthing new products or shepherding established ones, PMs never have enough time or resources to deliver what companies and customers ask of them.

A good PM has to be able to say “no” to their stakeholders while maintaining relationships.  That’s never easy, and sometimes PMs fall into one of three patterns that they really should avoid:

1) “Yeah, but if we implement this feature terribly, you won’t be happy.” The CoolMail PM makes this argument, in this case about implementing email scheduling as a client-side feature. Except that people don’t ask for client-side scheduling, which would be a dumb way to do it, as the PM explains. Note that the PM is also communicating like they’re in an internal meeting, presuming the requestor has an understanding of the meaning and implications of “client-side” and “server-side.”

2) “That would only work with an asynchronous widgetator and ours is synchronous.” The PM, going technical-ish, uses a few acronyms a user may or may not understand, but doesn’t provide a real technical explanation other than “this raises security issues.” The requestor likely hears something akin to, “this is complex, you wouldn’t understand it, and I don’t feel like actually explaining it.”  Dismissed.

3) “We didn’t put in a steering wheel because we care about safety and we view brakes as more important.”  Notice the not-so-subtle false choice here and at the end of the FAQ answer.  The PM explains why push notifications are more important, but the requester didn’t argue that email scheduling was more important.   All the requestor did was ask for something else.  And mentioning “other server-side features” isn’t relevant to this request.

So how can PMs communicate better than this, especially when dealing with skeptical prospects, stressed-out presales engineers, eager and urgent community leaders, or even angry customers?

1) Don’t just let them talk, listen. Nobody accepts a “no” when they don’t feel heard. Being fully-present, and paraphrasing back a feature request (in the requestor’s language, not your company’s feature-speak), will start to build trust and confidence before you’ve had to commit to anything. Bonus points if you can add/playback the context as well. “So Lance, you’re saying you want email scheduling so you can do emails at any time of day, but not bother your coworkers off-hours?” “YES!” says the I-just-felt-HEARD user!

2) Stay intellectually honest. The PM explains how a poor implementation of the feature would be bad. You’re the product manager.  You’re right, I wouldn’t be happy with a bad implementation — how about you make me a good one then?  PMs don’t have to unpack all their thinking for the audience, but they will lose the confidence of the audience (regarding potentially both their transparency and technical skills) if they throw out rhetorical strawmen like this.  The false dichotomy at the end is another example.  The user just asked for a feature, they didn’t argue its relative importance.  (Nor should the PM cherrypick sacred features against which to compare.)  A feature request can simultaneously be valid, valuable, and low-priority relative to others — all at the same time. 

3) Be transparent, even when it hurts. Just don’t surprise your partners or salespeople. Honesty is essential for trust in all relationships, and if you’re a PM and want stakeholders to trust you, be transparent about your constraints and high-level prioritization. Not, “they stole half my engineering team in Q2 to fix bugs in another product” transparent, but clear about having constraints. The answer to your customer is most-typically “not yet” at best, and “not ever” at worst, so make sure you’ve talked to whomever owns the relationship with that partner, customer, or prospect and is aligned (not just informed) on what you’re going to say. But once that’s done, it’s actually liberating to say things like:

  • “We’re planning multiple upgrades to the Shmumble Console expected next Fall, so you won’t get this yet, but it’s on the list, targeted for late this year.” You’re telling the stakeholder that their request fits the strategy but isn’t coming yet.
  • “Our strategy is horizontal for now, so I understand why this matters to regulated process manufacturers in Germany like you and I’ve documented it well, but for now it’s not making the cut for the next two releases and I can’t promise it will after that.”
  • “This likely won’t be in our product roadmap because for now, this is a rare use-case, and rather than string you along waiting for this feature, I’d recommend you work with our services team, partner, open source community to create a manageable workaround.” In this and the prior comment, you’re telling your stakeholder that the request doesn’t fit the current, and likely future, strategy and that they need to take another approach. Granted, telling a customer “we’re not going to deliver that feature,” isn’t pleasant, but it’s more pleasant than if they feel like you’re telling them they shouldn’t want the feature in the first place. And it gives them productive options and a feeling of control since they now know that “saying nightly roadmap prayers” for another year won’t solve their problem.

4) Under-promise, over-deliver. If you didn’t already know this one, turn in your PM badge because you may not make it to the next GA.  ;-)

 Of course, there are also ways to be a much more collaborative and effective feature requestor. Maybe I’ll explore that in another post.

 What do other product leaders out there see that doesn’t and does work?

 # # #

Notes

  • Thanks again to Lance for contributing this rant!
  • I made a few edits to Lance’s portion of the post.  Mistakes are likely mine.

2 Comments

Posted in Communications, Product, Startups

Communications Lessons from Mayor Pete

Posted on June 3, 2019 | Leave a comment

Whenever I have the chance to watch a big league politician at work, I always try to study their communications skills in an effort to learn from the best.  In a previous post, I presented what I learned watching Congresswoman Jackie Speier work a room, a pretty amazing sight, in The Introvert’s Guide to Glad-Handing.

Yesterday, I had the chance to watch Mayor Pete in action at a gathering in Palo Alto.  Political views aside [1], the man is a simply outstanding public speaker.  In this post, I’ll share what I learned from watching him work.

  • Don’t be afraid of Q&A.  I’d say Pete spent 1/3rd of his time on his stump speech, and left 2/3rds to “make it a conversation.”  It works.  It engages the crowd.  In tech, I feel like many companies — after one too many embarrassing episodes — now avoid Town Hall formats at employee All Hands meetings, Kickoffs, or User Conferences.  Yes, I’ve heard of [2] and seen [3] a few disasters in my day, but we shouldn’t throw the baby out with the bathwater.  Town Hall format is simply more engaging than a speech.  Moreover, I’d guess that when employees observe leaders who habitually avoid Q&A, they perceive them as afraid to do so.
  • Engage the person who asked the question.  I’ve gotten this one wrong my whole career and it took a politician to teach me.  I’ve always said “answer the question to the audience” (not the person who asked) as a way to avoid getting caught in a bad dialog [4], but I now realize I was wrong.  If you’re a politician you want everyone’s vote, so let’s not dismiss that person/voter too quickly.  Pete inserts a step — engage the person.  Student:  “What are you planning to do if you get bullied by another candidate?”  Pete:  “Well, what do you do at school when someone tries to bully you?”  Student:  “Well, I try to walk away, but sometimes I want to yell back.”  Pete:  “And you seem pretty level-headed to me.”
  • Answer the question for the audience, ideally building off the engagement.  Pete:  “That’s it, isn’t it?  You know you should walk away but you want to yell back.  That’s why it’s so hard.  That’s why it takes discipline.  That’s why I’m thankful that during my service in the Armed Forces that I learned the difference between a real emergency and a political emergency.  Instead of yelling back at the bully you need to …”  Note that when he finishes, he does not look back at the questioner but instead says “next question” and looks to the audience [5].
  • Squat down when addressing children [6].  There were a lot of kids at the event and Pete, somewhat surprisingly, took numerous questions from them.  There were two benefits of this:  (a) the kids tended to ask simple clear questions (e.g., “why are you going to beat rival X”) and (b) the kids introduced a good bit of humor both in their questions and delivery (e.g., “what are the names and the sizes of your dogs?”or “when will there be a ‘girl’ president?”).  I always considered the squat-to-address-children as Princess Diana’s signature move, but this article now credits it to her son, Prince William.  Either way, it’s an empathetic move and helps level the playing field between adult and child.

img_0234.jpg

  • Embrace humor.  Pete seems to be a naturally funny guy, so perhaps it’s not difficult for him, but adding some humor — and flowing with funny situations when they happen — makes the event more engaging and fun.  Child:  “Can I have an even bigger bunny?”  Pete:  “Well how big is your bunny now? [7]  Child:  [sticks arms over head].  Pete:  “That big.  Well.  Uh.  [Pauses.]  Sure.  [Applause and laughter.]  You know there’s always at least one question that you didn’t see coming.” [More laughter.]
  • Use normal diction (i.e., words) [8].  Public speaking, especially in politics, is not the time to show off your vocabulary.  Pete went to Harvard and was a Rhodes Scholar at Oxford.  I’m sure he has a banging vocabulary.  But you’re not trying to prove you’re the smartest person in the room at a Town Hall meeting; you’re trying to get people to like you.  That means no talking down to people and not using fancy words when simple ones will do.  On a few occasions, I heard Pete auto-correcting to a simpler word, after starting a more complex one.
  • No free air-time.  He generally didn’t say the words Trump or Biden.  But he did say things like “we don’t want to go back to the Democratic era of the 1990s just like we don’t want to go back to the current administration’s era of the 1950s.  We want to go forward, …”  He used words like “White House,” “current administration,” or even “current President.”  But he didn’t say Trump.
  • Make it real.  A key part of Pete’s message is that we shouldn’t look at political decisions as some distant, academic, theoretical policy discussion.  We should stay focused on how they affect peoples’ lives.  Pete:  “When we think of climate change, we see imagery of a polar bear or a glacier melting.  I want to change the dialog so we think about floods that are only supposed to happen every 100 years happening only 2 years apart.”  Ditto for a conversation about healthcare where he talked about its impact on his family.  Ditto for a conversion about his marriage that wouldn’t have been possible but for a single supreme court justice’s vote.
  • Tell stories.  Given all the attention story-telling has gotten of late, this one probably goes without saying, but always remember that human beings love stories and that information communicated within the context of a story is much more likely to heard, understood, and remembered than information simply communicated as a set of facts.  Great speakers always communicate and/or reinforce their key messages via a series of stories.  Pete is a highly effectively story-teller and communicated many of his key messages through personal stories.

# # #

Notes

[1]  See my FAQ for my social media policy.  In short, because my Twitter feed is a curated version of everything I read, I tweet on a broad array of subjects which, in the current era, includes politics.  However, I try to keep my blog free from any political content — with one exception:  since politicians are generally highly skilled in marketing communications, I try to learn from them and apply what they can teach us in high-tech. Towards that end, by the way, I always recommend following two people:  Alan Kelly, a high-tech PR maven (the PR guy who put Oracle on the map) who decided to take his game to the big leagues by taking his system to DC and opening a communications firm there and Frank Luntz, a market researcher, pollster, and author of Words that Work.

[2] On “there’s always some engineer not afraid to ask anything” theory, I have heard the story of an All Hands where an engineer asked the CEO what he thought about the VP of Sales having an affair with the VP of Marketing.  OK, that’s awkward for the person who suggested the Town Hall format.

[3] Where at a User Conference when asked why so few women were in Engineering leadership, the VP responded that the company had many women on the team but they tended to work in the “more arts and crafts positions,” which made everyone in the crowd wonder if they were cutting paper flowers with scissors or building software.

[4] “So did that answer your question?”  Response:  “No.  Not at all.  And I have three more.”

[5] If you do, you are silently seeking confirmation (“did that answer your question?”) and potentially inviting the questioner to ask a follow-up question.  If you’re trying to work a room, you want to engage as many different people as possible.

[6] Or those, as you can see in the Princess Diana link, otherwise unable to get up.

[7] Applying the “engage the person” rule.

[8] Yes, that was a touch of deliberate snark.  :-)

Leave a comment

Posted in Communications, Marketing, Uncategorized

Reacting to Feedback as CEO

Posted on April 26, 2019 | 4 comments

The other day I saw this tweet from my friend Nick Mehta, CEO of GainSight, and it got me thinking.

feedback

It turns out that in addition to making fun music videos for company events, that Nick and I have another thing in common:  we both wrestle with finding the right balance in listening to feedback.  Since this is a topic I’ve pondered quite a bit over my 12+ years as a startup CEO, I thought I’d share those thoughts in this post.

First, you don’t get to be CEO of a startup by not caring.  You want your company to be great, you want your customers to be delighted, and you want your employees to be happy working at your company.  So I think most CEOs will have that same natural tendency towards immediate action that Nick mentions.

But CEOs who overreact both irritate employees (“so you’ve heard one side of this and it sounds like you’ve already made up your mind”) and, more dangerously, are easily manipulated.  If you find 3 people outside your office before a big meeting, each hoping to the last one to talk to you before it begins, then I’d view that as flashing yellow sign that you might be an overreactor.

On the flip side, there is some chance that the feedback is an outlier, and that reacting to it would be a mistake, particularly in terms of the opportunity cost of not having focused on something more generally important.

Finding that balance in the middle is indeed the hard part.  On one hand, CEOs are action-oriented and if they hear something plausible, they want to immediately dispatch someone to fix it.  On the other, CEOs get lots of feedback and it’s a little too easy to create a platitude shield around yourself that rationalizes feedback before it gets through — e.g., salespeople are never happy with their comp plans, employees generally don’t like their bosses, and customers always want more for their services dollar.  If you gave me 30 minutes I think I could generate about ten platitudes that would screen out 90% of feedback.  And that’s not good either.

So what should you do to find this balance?  Here are some tips:

  • Listen to everyone, all the time.  Ask open-ended questions.  For example:  “how’s your experience been working here”, “what are we like to work with as a customer”,  or “what do you think we can do better.”  Rule 1 is you’re not listening if you’re talking, so speak little and listen a lot.  Try to set up meetings as listening or feedback sessions as opposed to the default that “our CEO wants to come in and talk to you.”  Reframe it:  “our CEO wants to come in and listen to you, hear about your project, etc.”  The more feedback you get the harder it is to overreact to any one piece.
  • Remember that people have good days and bad days so do not overreact to any one incident.  (If someone really unloads on you, listen politely, take notes, and set up a follow-up call in a week or two to check back in.)
  • Listen no matter what you’re hearing.  You might hear things that are factually wrong.  You might hear things you find offensive.  You might hear things you immediately want to explain.  Recognize these as defensive reactions (even if they are appropriate defensive reactions) and remember Rule 2:  defensiveness kills communications.  Shut up, let the other person keep talking, take notes about any points you want to clarify, and discuss them at the end of the conversation.
  • Ask the “dead moose” question.  Is there any issue so big and glaring that we’re afraid to talk about and it’s like a giant dead moose in the middle of the conference room table that we’re all ignoring as we converse?  This gives people permission to put the big, often obvious, but potentially dangerous issues on the table — and get the moose off it)
  • Remember that people sometimes have agendas that shape their feedback.  Not all feedback is “pure” or unbiased in the sense that it’s a neutral voice wanting what it perceives as best for the company.  Maybe a customer is in the middle of negotiating a big contract.  Maybe an employee is angry about having missed a promotion.  Maybe a manager is trying to reorganize a department.  There’s nothing wrong with having an agenda, but it helps to know what it is when processing feedback.  Ask:  is there any bigger picture item that’s shaping this feedback overall?
  • When it comes to employee incidents, remember there are three sides to every story:  yours, mine, and what actually happened.  If you react to the first person you hear, then you’ll be teeing up a race to your office after every dispute because (as with patents) the first one to the office wins.  When faced with interpersonal disputes, remember my friend Martin Cooke’s favorite question:  “so what did Joe say when you spoke to him about this?”  If they’ve not spoken yet, then send them off to do so.
  • Beware hearsay.  It’s not allowed in court, so perhaps it shouldn’t be allowed in your office.  I don’t want to spend time with Pete saying he heard Paula say something offensive to Joe.  Tell Joe to come see me.  Or go find Joe yourself.  But we’ve all played the telephone game and know what happens to messages as they told and re-told through layers of people.
  • Remember that “not reacting now” is not the same as “not reacting.”  This is very important because “not reacting now” is probably the right answer 90% of the time.  Write it down.  Think about it.  Schedule a meeting.  But resist — and I know it’s hard — any action-oriented tendency to “do something” right now.  Once you get a reputation for going off half-cocked it’s pretty hard to shake — and very easy to get manipulated.  Time is usually your friend.
  • Remember, the plural of anecdote is not data.  Hearing the same story or opinion two to three times doesn’t automatically turn it into data.  Use surveys to gather data and use all your feedback conversations to guide topical questioning in those surveys.
  • Go get data.  You should already be running quarterly customer surveys and bi-annual or quarterly employee surveys.  Study the data in them.  Use what you’ve heard listening to people to drive special, topical lines of questioning within them.  Or, if indicated, do a special topic survey.  Once you’ve done the survey, call an optional Town Hall meeting to discuss the results.
  • Remember that 80% of an employee’s experience at your company is shaped by their manager (and, as a corollary that 80% of a customer’s experience is shaped by their account manager).  Ask specific questions about both in your surveys and when hot spots light up, go dig into them (i.e, why are so many of Joe’s employees rating him poorly on management).  Most companies are small enough that the digging can be done by live 1-1 meetings or phone calls.
  • View external data with a skeptical eye.  You can’t ignore the fact that product and company review sites exist.  All review sites have limitations — competitors can launch coordinated attacks to decrease your scores while HR can launch proactive programs to increase your scores.  My controversial advice for CEOs is to ignore these sites yourself and put your VP of Marketing in charge of product review sites and your VP of People on company review sites.  If you start to personally and immediately respond to these public posts, you are basically incenting employees to raise gripes in a public forum, as opposed to a private one such as your employee survey or coming to you directly.

Let me thank Nick for putting an important question on the table.  If you have other tips on how to answer it, please share them here.

4 Comments

Posted in Communications, Leadership, Management, Startups, Uncategorized

The Introvert’s Guide to Glad-Handing

Posted on March 24, 2019 | 9 comments

One day back at MarkLogic, we invited our local congresswoman, Jackie Speier, to visit our offices.  Regardless of what you may think of her politics, she’s an impressive person with an fascinating background including, for those with long memories, that she was the congressional aide shot five times and left for dead on the runway in Guyana when Congressman Leo Ryan went to investigate Jonestown.  I was looking forward to meeting her.

She arrived — early of course — with a few handlers.  We exchanged the usual greetings and took a few pictures.  Then, she said, “would you mind if I went around and met a few people before the presentation?”  “No, no — not at all,” I said.  Leaving the handlers behind, off she went into the sea of cubicles.

Affordable Care Act

What I saw next blew me away.

Cube by cube she proceeded, “Hi, I’m Jackie — what’s your name?”  “Great, what do you do here?”  “Oh, I see [from the picture on your desk] you have a son, what’s his name?’  “How old is he?”  “Oh, [insert something in common here].”  More chatter.  A few laughs.  “Are there any questions I can answer for you today?”

There are extroverted people.  There are gregarious people.  There are charismatic people.  And then there are politicians.  She was the best room-worker I had ever seen in my life and she did it as effortlessly as she did naturally.

“This,” I thought, ” is why you’re not a politician, Dave. You have no skills.”

But leading the troops is a key part of the job of a startup CEO.  While such glad-handing often comes naturally to sales-oriented CEOs, it usually does not for more product-oriented ones.  A sales-oriented CEO is typically an extrovert; a product-oriented one an introvert.  So what’s a poor introvert to do?

First, Run A Normal Communications Program
All CEOs should run some sort of baseline company communications program.  This could look something like:

  • Bi-annual kickoffs where the company is brought together to hear about progress, learn about new initiatives, and recognize achievement.  Think:  educate, decorate, inebriate.
  • Post-quarter all hands calls/meetings after the off-quarters to discuss company performance, progress on quarterly goals, and go-forward priorities.
  • Topical all-hands emails and follow-up live calls/meeting to announce breaking news and provide commentary.
  • Separate and/or built-in “town hall” sessions with open employee Q&A to the CEO and the exec team.

This is baseline.  If you’re not doing this and you’re over about 20 people you need to start doing aspects of it.  If you’re over 150-200 people you should be doing all of this and quite possibly more.

For most CEOs — even the introverts — this isn’t hard.  It’s structured.  There are presentations.  Most of the questions in Q&A can be anticipated, if not solicited in advance.

Management by Walking Around
Let’s say you’ve set up such a program and are getting good feedback on it.  But nevertheless you’re still getting feedback like:

“You’re in your office and in meetings too much.  People want to see more of you.  The answer isn’t more all hands meetings.  Those are fine.  But people want to see you in a more informal and/or 1-1 way.  I know, you need to do more MBWA — management by walking around.  You’ll be great at it!”

“No, I won’t,” thinks the highly self-aware introvert CEO, imaging a nightmare that goes something like this:

CEO:  “Hey, Bro-dy!” [Struggling to choose between Bro and Buddy.]
Employee:  “Did you just call me grody?  What the –“
CEO:  “No, Buddy, no,  I called you Bro, Pal.”
CEO:  “So, how’s my Buddy doing?”  [Slaps his back.]
Employee:  “Ow!  I just had shoulder surgery.”
CEO:  “Whoops, sorry about that.”
Employee:  “No problem.”
CEO:  [Notices wedding picture on desk.]  “Hey, how’s that lovely wife?”
Employee:  “We split up three months ago.”
CEO:  [Thinking: “I bet this never happens to Jackie Speier, I bet this never happens to … “]

Sure, the CEO thinks, let’s try some more MBWA.  Or maybe not.

Find Your Way
The problem here is simple — it’s a classic, in this case “reverse,” delegation mistake.  The well-intentioned feedback-giver isn’t just telling you what needs to be done (i.e., help people get to know you better through more individualized interaction),  they’re telling you how to do it (i.e., management by walking around).  So the solution is simple:  listen to the what and find your own way of how.  If you’re not a natural grip-and-grin type, them MBWA isn’t going to work for you.  What might?  Here are some ideas:

  • Every Friday morning do three, half-hour 1-1s with employees across the organization.  This will play to your introvert strength in 1-1 meetings and and your desire to have substantial, not superficial, interactions with people.  If you’re disciplined, you’ll get to know 156 people/year this year.
  • Management by sitting in the way (MBSITW).  Pick a busy spot — e.g., the coffee room or the cafeteria — and camp out there for a few hours every week.  Work on your laptop when no one’s around but when someone walks in, say hi, and engage in a 1-1 chat.
  • Small-group town hall Q&A sessions.  Attend one department’s group meeting and do a one-hour town hall Q&A.  It’s not quite 1-1, but it’s definitionally a smaller forum which will provide more intimacy.
  • Thursday lunches.  Every Thursday have lunch with 3-4 people chosen at semi-random so as to help you build relationships across the organisation.

So, the next time someone tells you that you need to do more MBWA, thank them for input, and then go find your way of solving the underlying problem.

9 Comments

Posted in Communications, Culture, Leadership, Management, Silicon Valley, Uncategorized

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

Posted on January 16, 2018 | 5 comments

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 video conferences at odd hours.  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.

5 Comments

Posted in Communications, Uncategorized