Have you ever done a stint in customer service?

Many of us checked that box long ago, waiting tables or, in my case, spending 20-plus years in improv. (If you don’t think that’s all about customer service, you’ve clearly never tried it.)

But customer service experience isn’t just important in the abstract; it’s contextual. You don’t need to know that customers complain; you need to know what they complain about, and why.

I learned that firsthand at TeamSnap, where I was part of the founding team and the original DevOps engineer, eventually working my way up to Chief Technology Officer. The company eventually became an industry leader in the sports management space, but when we started, we had our work cut out for us, growing and iterating and adapting to create something our customers wanted and needed to buy.

In those early days, we were a small team, mostly developers and designers. We had one customer support person, and as we became a fully fledged business, she got more than a little overworked.

To ease her pain, we instituted rotating shifts for customer support, and we all had to do our part. One day, our customers may have reached TeamSnap’s CEO with a support request. The next day, it may have been a developer answering your email. The following day, one of the chief product architects would pick up the phone.

It wasn’t long before we realized this was more than a stop gap. It was a critical part of the growth and success of our company.

For our developers, it was a very different experience to hear about a problem live, compared to reading about it on a support ticket. When it’s just a ticket, it’s impersonal and, as a result, easy to write off as something we’ll get to when we can. On the other hand, when you’re on the front lines for support, fielding requests in real time, those nameless, faceless tickets come to life. You begin to understand that they come from real people having real issues, and you feel a little extra push to get those problems solved. After all, even if you have good intentions, there’s a big difference between being told someone has a problem and having someone describe that problem directly to you.

As a result, our developers began to fix issues faster and write better software because they understood how our customers thought. More than that, everyone in the company — technical and non-technical — became perfectly aligned around the mission and our users. We built a reputation for our commitment to our customers. We established a voice and a brand around being friendly and personable. And it paid off.

That customer-first philosophy became my personal standard, too. Even after I left TeamSnap, I gravitated toward companies that prioritize customer communication and support. It’s a big part of what drew me here, to Dualboot Partners.

Dualboot puts these same principles into action every day. We don’t believe in middle men. Instead, we set up dedicated slack channels that put everyone in the same room and on the same page — project managers, developers and customers. We establish regular meetings to touch base and ensure that what we’re building and designing is what our customers want and what their users need. This is not about tasks on a Jira board. It’s about engaging with real people to determine what and how we build.

Now, in our new normal, experts are hailing a customer-focused approach as a business imperative. If you ask me, it always has been. And if your company doesn’t do this, you should find a way to build the connection between your people and your customers. Try it for six months, and I’m pretty sure you will build a better product, your customers will be happier and your employees will be more engaged.

It doesn’t get much better than that.