How Our Remote Team Constantly Improves

As a fully remote team, it was hard at first to make sure we didn't get complacent and stop innovating and improving. Our projects were running well enough with the occasional issue here and there, but the issues that arose were never big enough to force us to change.

However, staying "good enough" wasn't what we set out to be. We wanted to change the world of software development, and that can't happen if we settled for what we had.

The biggest change for us was placing a heavy emphasis on Pain Points, to the extent that pain points became a KPI for every single team member.

Why We Emphasize Pain Points

Some time earlier in our journey, we heard the famous quote "fall in love with the problem, not the solution." Read more about the meaning behind this quote, here. This concept was extremely relevant to us, since we started our company because of the problem that we discovered with how people outsource software development.

Over the years, we've come up with a solution that includes our proprietary project management platform, our custom-tailored development process, and the role of our Strategist who ensures a smooth relationship. But we didn't always have these aspects of our offering.

When we started, all we had was a vague idea of the problem with outsourcing software development, and lots of free time. We built our initial solution, which primarily involved only a vetted software firm and a jumbled mess of Trello boards, Airtable bases, and Slack channels.

With our early projects (bless those clients), we experienced a LOT of fires. I'm talking being up at 3am frantically trying to bring a server back online, delivering projects weeks late because we didn't plan properly, and much, much worse.

With each of these painful experiences, we wrote postmortems to try and understand what went wrong, and how we could improve. Through these postmortems, we began to see patterns of issues that arose across multiple projects.

This was our first foray into tracking what we now call pain points. Eventually we decided to maintain a master list of pain points. Patterns would emerge where many clients shared some pain points, which would inform us how severe they were. Based on the number of clients impacted, we could prioritize our innovation efforts to try and solve our clients' pain points.

When a pain point was addressed, we saw immediate improvement in our clients' experiences. By taking client feedback, complaints, and issues and tracking them diligently, we were able to identify opportunities for improvement. In fact, many of our most innovative efforts evolved directly from repeated pain points, such as our audit process and a native notification system for our platform.

Pain points transformed from negative client feedback into huge value adds, and helped build our moat.

Our obsession with addressing pain points helped build our moat

How We Track Pain Points

We maintain master list of pain points where we track the issue, which client(s) it affected, any potential solutions, what area of our business was affected, and what (if any) was the eventual implemented solution. This way, when we roll out a new feature or improve our development process, we can quantitatively track the impact it has.

In 2020 alone, we logged 244 new pain points. Part of this is thanks to the fact that each team member has a weekly KPI of logging at least 3 client or vendor pain points (I'm really bad at hitting this KPI, sorry Christian).

Each pain point is tagged by the area of our business it impacts, such as client relations, vendor relations, platform efficiency, development process, etc. On our weekly calls about each of these areas, we'll go over the pain points that belong to that area and create an action item for each pain point or group of pain points

We then prioritize the action items based on the number of clients affected or the severity of the disruption. This gives us an actionable, prioritized list of ways that we can improve our offerings. We've found it to be way more effective than keeping a vague list of client complaints with no actionable outcome.

Why You Should Start Tracking Pain Points

Whether you're a B2B or B2C company, it's important to prioritize what your customers actually want. If you have the same obsession we do with pain points, you'll immediately start to see patterns of the same feedback being brought up by multiple customers. When you're planning your roadmap, a list of pain points and the customer(s) it impacts will help you figure out how important features are.

You can even take this one step further and use a tool like Canny to track your pain points and add specific people as "voters" on each feature request. That way, if you add their emails, your customers will get notified when a feature they requested is placed on your roadmap or implemented on your platform.

When customers see their feedback is valued and directly informs your company decisions, they will fall in love with you even more. I can't count the number of times we've received excited emails from clients who see us implement a feature they specifically asked for.

You don't necessarily have to be as obsessed as we are with pain points and start making them a KPI for every team member, but start tracking your pain points today and we'd be shocked if you didn't see the value within several weeks of this exercise.

We truly believe diligently tracking your pain points will help your team never become complacent and continue to build a solution that your customers will value. If you have any questions, think Christian should punish me for not hitting my pain points KPI (please no), or just want to chat—hit us up at resources@aloa.co or start a website chat!

The views expressed in this post are the writer's and do not necessarily reflect the views of Aloa or AloaLabs, LLC.

Ready to learn more?

Running a business is hard,
Software development shouldn't be ✌️

or call  (615) 505 4255