On interacting and learning from users in support

For every cre­ator, pub­lish­ing your work for the masses is both ex­hil­a­rat­ing and mor­ti­fy­ing. For a startup, you’re dy­ing for feed­back and us­age, in or­der to boost your met­rics, and if you’re charg­ing money, it even be­comes more se­ri­ous. In one way or an­other, you’re in for in­ter­act­ing with users/​cus­tomers (I’ll use the for­mer term in this post).

How I work

In my early work in Lookback, I re­mem­ber the tin­gling doubt and fear in­volved in talk­ing to users through our sup­port sys­tem (we use Intercom). We were just four, in­clud­ing me, when I came on, so there were no des­ig­nated sup­port per­son what­so­ever (still is­n’t in Lookback). That meant all of us dealt with cus­tomer sup­port tick­ets by ei­ther by as­sign­ing to oth­ers or solv­ing them.

While I was and still am very con­fi­dent in writ­ten and oral com­mu­ni­ca­tion, I felt I’d mess things up with users by

  • promis­ing too much
  • mak­ing them dis­ap­pointed
  • pro­vid­ing them with false in­for­ma­tion
  • or some­how mak­ing an ass out of my­self in front of a stranger (we all know how that is on the in­ter­net, right?)

This was the first time I was en­gaged with real peo­ple us­ing stuff that I was di­rectly or in­di­rectly re­spon­si­ble for.

Two and a half years later, I’ve learnt so much in do­ing sup­port — talk­ing to our users — that I’d rec­om­mend it to any­one — whether you’re an en­gi­neer or de­signer or prod­uct man­ager.

It’s easy to as­so­ci­ate sup­port with end­less hours of trou­bleshoot­ing, ex­plain­ing, guid­ing, and turn­ing peo­ple down. These are all signs that some­where, some­how, your prod­uct is flawed. That’s the harsh­est truth, which is why you ac­tu­ally have cus­tomer sup­port — to re­mind you of not be­ing so god­dammned cocky and to stay hum­ble. Nothing’s ever fin­ished. Not you, and nor your work.

There is al­ways room for im­prove­ment, you just haven’t ex­pe­ri­enced it yet, since you don’t have the fresh, un­soiled eyes of a first-time user.

View every con­fused user in sup­port as an op­por­tu­nity to im­prove, whether it is in your copy­writ­ing, value propo­si­tion, mar­ket­ing ma­te­r­ial, guides or FAQ, or any other facet of your pro­duc­t’s ar­se­nal. Every user writ­ing in to you — with ei­ther pos­i­tive or neg­a­tive words — has ac­tu­ally taken time to do so, which to me is worth ap­pre­ci­at­ing and ho­n­our­ing.

You can form very valu­able bonds with key users through do­ing great sup­port, by find­ing hard core fans or im­por­tant com­pa­nies worth tar­get­ing. By us­ing fea­tures like Intercom’s tag­ging sys­tem, you can triage bugs of fea­ture re­quests in or­der to make well in­formed de­ci­sions at your standup meet­ing, or when plan­ning long term roadmaps.

Support will also yield the fruits of your hard work: user ap­pre­ci­a­tion. It’s one of the chan­nels where you see the joy from real peo­ple trickle through, and it re­minds you of why you’re build­ing prod­ucts at all — to (hopefully) help peo­ple. I swear that talk­ing with users on the front lines will give you a fuzzy feel­ing when they tell you things like:

Oh, I un­der­stand — that’s okay! I love your prod­uct so much, keep it up!


Thanks for the heads up! This is so dope, can’t wait to be­gin us­ing it.

Support is a price­less as­set in giv­ing you a morale boost when the go­ing gets tough (which of­ten is the case in a startup). Don’t throw this chance away.

Another thing I’ve de­vel­oped in since start­ing do­ing sup­port is the flu­id­ity and level of for­mal­ity of my con­ver­sa­tions. In the be­gin­ning, I used to be as for­mal as one can be on­line (I did­n’t call peo­ple sir” or madame” though). Now, I use a pro­fes­sional but ca­sual tone, which strength­ens the bonds with the user on the other side of the wire, since they gets re­minded of that I too is a hu­man be­ing (this is help­ful in both pos­i­tive and neg­a­tive sup­port con­vos).

By giv­ing a damn, putting in en­ergy ex­plain­ing and ed­u­cat­ing users, and hav­ing a po­lite but play­ful lan­guage, I’ve started en­joy­ing do­ing prod­uct sup­port.

How Lookback works

Today in Lookback, we’ve landed on a sup­port setup which I think is pretty sweet. Roughly, we are in our third it­er­a­tion of our sup­port flow:

  1. The first one was a bit wild west: it was up to any team mem­ber to pick tick­ets from the unas­signed in­box in Intercom, and take on them­selves or re-as­sign.
  2. The sec­ond form was based on us hav­ing a des­ig­nated sup­port per­son that dealt with the low hang­ing fruits, or as­signed and fol­lowed up on tick­ets he needed an en­gi­neer’s as­sis­tance with.
  3. The third it­er­a­tion was based upon that each team mem­ber had one or two days of sup­port, mean­ing they dealt with all in­com­ing tick­ets dur­ing that day — what­ever the sub­ject of them was.
  4. Our fourth and cur­rent it­er­a­tion is based upon ar­eas and teams (more be­low).

As with most an­ar­chies, 1) fell through as the range and load of tick­ets in­creased.

  1. was every en­gi­neer’s dream, since they could write code with­out hav­ing to deal with pesky users com­plain­ing about their al­ready per­fect soft­ware, ex­cept for the sup­port per­son shoot­ing them a ques­tion once in a while, and per­haps do­ing some trou­bleshoot­ing.

When our sup­port per­son quit, we quickly mo­bilised the team to take on the sup­port to­gether, with 3). This was like com­mu­nism, polygamy, and hover boards: nice in the­ory but pretty un­prac­ti­cal in re­al­ity. It was di­vided equally, but day-to-day work was, for me, se­verely bogged down by the bur­den of do­ing all sup­port dur­ing a full day. The core stress mo­ment was hav­ing to take care of tick­ets out­side my area of ex­per­tise, and thus hav­ing to con­sult oth­ers about those is­sues all the time.

Our cur­rent sys­tem re­solves around teams. This is an­other ar­ti­cle, but in short: all eleven mem­bers of Lookback are be­long­ing to a team. Only one. We’ve got three teams: Find Product Market Fit, Increase Revenue, and Reliability & Performance (I’m in Product..). All our work is done in these teams. So why not di­vide the in­com­ing sup­port tick­ets around these ar­eas?

  • All things prod­uct, like fea­ture re­quests, guid­ance, roadmap ques­tions, and more are taken on by the PMF team.
  • Sales, ac­count, se­cu­rity and pri­vacy, and big cus­tomers” are as­signed to Revenue.
  • Processing er­rors, ob­vi­ous back­end bugs, crashes, and per­for­mance is­sues are in Reliability’s area.

Throughout the day, some of us goes through the Intercom in­box and as­signs to suit­able team. We’re for­tu­nate enough to be a dis­trib­uted team, so we’ve got U.S. west, U.S. east, and Europe cov­ered in terms of time­zones.

Support is very much about em­pa­thy. Being able to em­pathise with your users’ needs and woes is some­thing I think every­body agrees upon be­ing im­por­tant.

When I as a de­vel­oper hear or see a user strug­gle with my new, shiny fea­ture, it might hit me hard at first, be­fore I re­alise Right, this is a great chance of pro­vid­ing nice sup­port for her, and thus cre­at­ing a strong brand, as well as im­prov­ing the fea­ture for the fu­ture.”. We’re not per­fect, and prod­ucts are never fin­ished.

Empathy and care in prod­uct de­vel­op­ment is very in­ter­est­ing to me: how we with lan­guage, in­ter­ac­tion de­sign, and new tech­nolo­gies can cre­ate prod­ucts peo­ple love. But still don’t un­der­stand fully.