In my 9 long years of being a working adult, one of my favorite roles has to be serving as a support specialist in HubSpot under the leadership of Joseph Ting.

It might be strange that someone would say support was their favorite role. I'm not going to lie — the memes and media of irate customers screaming incoherently to a support staff are real. However, what I value most in a role is what I can learn from it and in this job, I learned a lot. The company and its culture definitely played a role. My colleagues and managers — 100%. They helped me through the challenges of this role and set me up for success, not only within the role, but beyond.

If you don't trust me, trust my customers:

Without further ado, the three most valuable things I learned:

• Managing expectations is half the battle won.

• Clarify the requirements.

• Genuine empathy helps with everything.

These principles have carried me throughout every job I had after, especially in product management.

Managing expectations is half the battle won

When I started, I often told customers to trust me, that we could get what they needed sorted. I thought this was to give them reassurance, especially if they were in a critical situation.

However, I realized even if I knew what I was doing, it doesn't mean I could get them where they wanted to be. There were many situations outside my control:

• The product could have an update that would benefit most users but adversely affected the one on the call.

• There could be a critsit (i.e. critical situation where all users are affected) — S/N: I was the first reporter of 2 critsits in my 10 months as a support specialist.

• The user's colleagues could have done something to their HubSpot instance that I can't undo without the consent of their colleagues.

Because of this, I had to adjust my mindset. Instead of reassuring customers with the assumption I could do the work, I often had to be hyper-realistic and conscious of any assumptions I'm making in my communication. I realized by being realistic and laying out facts, customers actually became more comfortable with me. Instead, when you make promises without knowing the full story and whether you can deliver, your counterparty can feel it and grow uneasy.

Case in point, this was initially a complicated case and I came out of with a partial solution that met their minimum requirements. However, knowing the hurdles we had to cross to get to the solution, this is what the customer shared:

Clarify the requirements

When someone tells you they want something, they often don't really want what they are asking for.

For example, a user once told me that he dove deep into his CSS sheet, looking at code that affect line spacing in different blocks. He was frustrated with the whole process, blamed the product for not performing, and asked me to identify and update all the line spacing so they were the same.

Instead of doing what he wanted, this is what happened:

• Casper: "Why are you specifying CSS related to line spacing?"

• Customer: "I've been seeing that the line spacing isn't consistent in my site."

• Casper: "So you want the spacing on your site to be consistent?"

• Customer: "Yes! *angry huff* And currently, there are not. I've been seeing odd spaces here and there."

• Casper: "Could you show me some examples?"

While not happy with my line of questioning, he showed me some examples. I thanked him, put him on hold, and investigated.

Instead of looking into his CSS as he mentioned, I looked at the specific pages and blog posts he showed me.

After 5 minutes, I showed him his pages and he thanked me for fixing his CSS. I informed him the truth: I did not fix his CSS. Instead, I found that his copywriter had been inconsistent, adding empty lines with small font to create more space, instead of relying on the code to give consistent spacing. I had identified these lines by updating the font to a consistent size and removing them.

If I had gone through the CSS, I was sure that the line spacing was different for different classes — and probably for good reason. If I changed all that, it would not have solved his problem. However, now, he can inform his copywriter not to add these line breaks and it would solve the problems going forward.

Someone might have done a lot of work based on their assumptions and thought they determined what they want. However, you should go back to the start — find out their aims and clarify what they need. Only then you would be able to solve the problem under the problem.

Genuine empathy helps.

Product managers often talk of empathy.

However, I've met product managers who never had to once support their users. While user interviews may seem like a close simulacrum of a support call, there's no substitute to hearing an absolutely frustrated user. Why is this so?

When you finally get a user to come for an interview, they usually like your product enough to do you this favor or they are invested enough in the product that they want it to work better.

This is different from a support call. In a support call, the user usually has exhausted all that they know. They come to you wearily. They come to you unhappy. They come to you frustrated. They don't want to use your product but they don't have a choice.

It is through speaking with such users that your heart can actually grow. This is when learned empathy becomes genuine empathy. There's no substitute to this. All the support calls I had with customers made me feel for them. There's nothing more painful than facing a customer who really wanted to make it work but can't. There's nothing more rewarding than a customer having that light bulb moment after you led them there.

If you're looking for your first job

Because of this role, as a product manager now:

• I know how to manage the expectations of every stakeholder, from management to developer.

• I find it easy to identify with customers, even if I'm building something different.

• I can clarify and discover user requirements during user interviews or even when I'm supporting them as a PM.

I strongly recommend starting off by being a support specialist.

Of course, reading this post, you can still learn these principles above, but you'll truly absorb these lessons through support. I'll even go further to say that as a PM, you should at least rotate and do support work at least once a year. Once you've grown that genuine empathy, it motivates you to help users to the best of your ability, whatever your role is.

In the end, it's just people connecting to solve a pain point. And isn't that every kind of job?