On interacting and learning from users in support

About 5 min reading time

For every creator, publishing your work for the masses is both exhilarating and mortifying. For a startup, you’re dying for feedback and usage, in order to boost your metrics, and if you’re charging money, it even becomes more serious. In one way or another, you’re in for interacting with users/customers (I’ll use the former term in this post).

How I work

In my early work in Lookback, I remember the tingling doubt and fear involved in talking to users through our support system (we use Intercom). We were just four, including me, when I came on, so there were no designated support person whatsoever (still isn’t in Lookback). That meant all of us dealt with customer support tickets by either by assigning to others or solving them.

While I was and still am very confident in written and oral communication, I felt I’d mess things up with users by

  • promising too much
  • making them disappointed
  • providing them with false information
  • or somehow making an ass out of myself in front of a stranger (we all know how that is on the internet, right?)

This was the first time I was engaged with real people using stuff that I was directly or indirectly responsible for.

Two and a half years later, I’ve learnt so much in doing support — talking to our users — that I’d recommend it to anyone — whether you’re an engineer or designer or product manager.

It’s easy to associate support with endless hours of troubleshooting, explaining, guiding, and turning people down. These are all signs that somewhere, somehow, your product is flawed. That’s the harshest truth, which is why you actually have customer support — to remind you of not being so goddammned cocky and to stay humble. Nothing’s ever finished. Not you, and nor your work.

There is always room for improvement, you just haven’t experienced it yet, since you don’t have the fresh, unsoiled eyes of a first-time user.

View every confused user in support as an opportunity to improve, whether it is in your copywriting, value proposition, marketing material, guides or FAQ, or any other facet of your product’s arsenal. Every user writing in to you — with either positive or negative words — has actually taken time to do so, which to me is worth appreciating and honouring.

You can form very valuable bonds with key users through doing great support, by finding hard core fans or important companies worth targeting. By using features like Intercom’s tagging system, you can triage bugs of feature requests in order to make well informed decisions at your standup meeting, or when planning long term roadmaps.

Support will also yield the fruits of your hard work: user appreciation. It’s one of the channels where you see the joy from real people trickle through, and it reminds you of why you’re building products at all — to (hopefully) help people. I swear that talking with users on the front lines will give you a fuzzy feeling when they tell you things like:

Oh, I understand — that’s okay! I love your product so much, keep it up!


Thanks for the heads up! This is so dope, can’t wait to begin using it.

Support is a priceless asset in giving you a morale boost when the going gets tough (which often is the case in a startup). Don’t throw this chance away.

Another thing I’ve developed in since starting doing support is the fluidity and level of formality of my conversations. In the beginning, I used to be as formal as one can be online (I didn’t call people “sir” or “madame” though). Now, I use a professional but casual tone, which strengthens the bonds with the user on the other side of the wire, since they gets reminded of that I too is a human being (this is helpful in both positive and negative support convos).

By giving a damn, putting in energy explaining and educating users, and having a polite but playful language, I’ve started enjoying doing product support.

How Lookback works

Today in Lookback, we’ve landed on a support setup which I think is pretty sweet. Roughly, we are in our third iteration of our support flow:

  1. The first one was a bit wild west: it was up to any team member to pick tickets from the unassigned inbox in Intercom, and take on themselves or re-assign.
  2. The second form was based on us having a designated support person that dealt with the low hanging fruits, or assigned and followed up on tickets he needed an engineer’s assistance with.
  3. The third iteration was based upon that each team member had one or two days of support, meaning they dealt with all incoming tickets during that day — whatever the subject of them was.
  4. Our fourth and current iteration is based upon areas and teams (more below).

As with most anarchies, 1) fell through as the range and load of tickets increased.

  1. was every engineer’s dream, since they could write code without having to deal with pesky users complaining about their already perfect software, except for the support person shooting them a question once in a while, and perhaps doing some troubleshooting.

When our support person quit, we quickly mobilised the team to take on the support together, with 3). This was like communism, polygamy, and hover boards: nice in theory but pretty unpractical in reality. It was divided equally, but day-to-day work was, for me, severely bogged down by the burden of doing all support during a full day. The core stress moment was having to take care of tickets outside my area of expertise, and thus having to consult others about those issues all the time.

Our current system resolves around teams. This is another article, but in short: all eleven members of Lookback are belonging 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 divide the incoming support tickets around these areas?

  • All things product, like feature requests, guidance, roadmap questions, and more are taken on by the PMF team.
  • Sales, account, security and privacy, and “big customers” are assigned to Revenue.
  • Processing errors, obvious backend bugs, crashes, and performance issues are in Reliability’s area.

Throughout the day, some of us goes through the Intercom inbox and assigns to suitable team. We’re fortunate enough to be a distributed team, so we’ve got U.S. west, U.S. east, and Europe covered in terms of timezones.

Support is very much about empathy. Being able to empathise with your users’ needs and woes is something I think everybody agrees upon being important.

When I as a developer hear or see a user struggle with my new, shiny feature, it might hit me hard at first, before I realise “Right, this is a great chance of providing nice support for her, and thus creating a strong brand, as well as improving the feature for the future.”. We’re not perfect, and products are never finished.

Empathy and care in product development is very interesting to me: how we with language, interaction design, and new technologies can create products people love. But still don’t understand fully.