Back to resources

Strategic Ways to Stop Losing Customers

Alignment
Innovation / Experiment
Product
Dev Processes
Convincing
Tech Debt
Prioritization

13 October, 2021

Mary Fisher
Mary Fisher

Software Engineering Manager at Curative

Mary Fisher, Software Engineering Manager at DrChrono, shares how diligently she worked with teams within her organization to retain customers.

Problem

I have helped with implementing quarterly planning and bug prioritization in an organization. In the process, I managed a large team of client integration engineers, where we had about 18 - 19 of them. I realized that our customers were very dissatisfied when talking with the client integration engineers and all the supporting teams, such as the account managers, PMs, and technical product managers. They were not happy about the new features and issues not being addressed on time. They were starting to look at switching to our competitors and starting to leave us.

The other challenge that revolved around this was that I was also losing client integration engineers left and right. The engineering department was also losing software engineers because of obvious reasons. It can be very demoralizing when we feel that we are not addressing our customers' concerns, and customers are yelling at our employees each week on why we have not been addressing their needs. It was a big challenge.

Actions taken

I noticed that they did not really have a customer prioritization process or roadmap planning process. I began by implementing that. I worked with the professional services department and the engineering teams and immediately formed a group with the TPMs over the engineering teams. We met on a weekly basis to determine how we were going to tackle the problem.

I also met with the account managers to help put a prioritization process, or SLAs, in place by identifying the customers and their MMR. I started closely working with the client integration engineers, where I figured out the categories of features that multiple customers were asking for. Since they were the ones hearing all the pain points and feedback, they helped us categorize these features.

For example, about 5 customers who were of high revenue were asking for "ABC" features, but we could not deliver. I passed that on to the engineering team, and they would finally work on it. I created an Excel sheet of features that customers put pressure on, and we rated those heavily to determine their importance. On top of that, we had a timeframe based on the customers' needs; some even had specific deadlines.

Once we had that all in one place, we met on a bi-weekly basis to see the progress of each feature and sometimes, we even broke it down into smaller parts. If the feature was too big, they would not be able to work on it with the number of available resources. We worked on what the customer mainly needed and iterated to work on that specifically. Because we had the processes in place that started to work really well, we started to see what we were actually delivering what our customers needed.

I also did the same for bug prioritization. Every week, during the meeting with my client integration engineers, I would hear about all the bugs and pain points only to help them prioritize those using the same framework. Looking at the MMR and the number of customers who were facing the bugs, we would check in on how to tackle our burning issues.

We also sometimes noticed trends. For example, some of the packages were outdated, and we would have to bump up that tech debt since it was impacting the ability to implement some of the features that our customers needed and would plan that work as a release.

Lessons learned

  • Build relationships with your peers. There was a time when I felt as if a Development Manager was upset with us for putting pressure on them. Getting them to understand my team's pain points, the customer's problems, and how we were losing customers got through to them. I needed to build relationships with those individuals from scratch to get them onboard. Eventually, we started bonding and they became much more supportive of the process, even bringing their own ideas on how to improve the process or deliver the necessary features faster.
  • When other teams feel your wins, they will keep wanting to support you. Keep sharing how different groups have impacted your success; they would feel welcome to bring in more solutions.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

Mindsets of High Performance team

14 October

Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.

Innovation / Experiment
Mission / Vision / Charter
Building A Team
Productivity
Feedback
Motivation
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan