Reading the Signals

​​​The difference between real signals and noise

It can be easy to get into a "squeaky wheel gets the most grease" situation. An important prospect demands a new feature before they are willing to sign. A high-touch client is complaining about a data integration. But it's the pattern that matters, not the one-off request. Some of the things to look for include:

​​

• Clients keep asking for the same few things, over and over. Not scattered feature requests, but the same handful of asks repeated across different clients.
   

• The asks are about reliability, not novelty. Things like SSO, uptime, data availability, integration stability. Not "can you add X," but "can you make what already exists work every time."
   

• Support tickets cluster around the same root issues. That kind of clustering tells you something structural is broken.
   

• Churn conversations mention the same complaints. When you talk to clients who are considering leaving, or who already left, the same reasons keep coming up.

 

Choosing stability over speed

Here's where it starts to get difficult. Seeing the signals isn't the same thing as taking action. The easy road is bowing to pressure and greasing the wheel. And honestly, sometimes it's the right call. There are key clients to land, either for visibility or contract size. A single loud client surfacing a complaint can often be the doorway to spotting an opportunity that improves the user experience in general.

​

But it's important to weigh the single urgent ask against a pattern of complaints or needs. Trust your intuition and experience, and consider the big picture. What supports the business goals? What moves the bottom line the most? What supports engineering's need for easy maintenance through building good infrastructure?

​

The choice isn't always clean and easy. In fact, it rarely is. Each option in front of you might lead somewhere reasonable, but resources are limited so priorities have to be set. I wish that I could give definitive answers here, but obviously every situation is unique. I can say, though, that when the base is shaky, the entire structure tends to eventually collapse.

 

A few things to consider:

• According to Forbes, it can cost 4 or 5 times more to earn a new SaaS customer than to retain one

• Losing clients now doesn't just cost this year's revenue. It can also cost referrals and reputation

• Skipping the work on underlying systems often means redoing it later anyway, at a higher cost

• Stability work reduces context swapping for engineering, which can produce better work through deeper focus

• Being known for reliability can become a competitive advantage​

​

It's also important to note that this decision isn't permanent, nor does it need to be an all-or-nothing call. Perhaps you want to alternate foundation work with new features across your roadmap. Maybe you want to allocate a certain amount of time to stability fixes, and you'll just do as much as you can in that timeframe. Or perhaps you simply want to re-evaluate where everything stands in a few months with an option for changing at that point.

​

The trade-offs

​​​​​​​​There are real consequences that come from choosing stability over new features, and it's important to take those into consideration before making final decisions.

 

A lack of new features can hit hard in the marketplace, depending on your competitive landscape and customer base. Competitors may be shipping visible new features, and you may be falling short with new prospects when they are doing side-by-side comparisons. This can result in lost deals, can affect the bottom line, and can even genuinely hurt your overall market position if someone takes advantage of your comparative quiet in the marketplace to gain dominance. 

​

There is also an internal price to pay. You might suffer reputational harm if leadership perceives your choice as "playing it safe" instead of launching into bold new territory. You might see internal morale fall because it tends to just simply be more fun to work on something new and flashy, and that can lead to lower quality or even resignations. And you are almost certainly going to face internal friction with sales, who are always looking to boost their commission through new things to sell. This is going to mean some tough conversations, and possibly even complaints to leadership.​

​​

Making the case

Once you've made the call, how you communicate it is important. Convincing leadership is rarely a single pitch. Instead, it's usually a campaign of conversations, starting small and working your way up.

​

Start by getting some allies. Reach out to the people around the company who are most frustrated with the current state of affairs, or who are the most affected by churn. This might include customer success or support or even sales, especially if there is commission tied to renewals. Walk these allies through the plan, collect feedback, and iterate as necessary until both your presentation and your case feel solid.

 

Back up your proposal with data. Pull together your case with transcripts of churn conversations, engineering feedback, support tickets, and whatever else you have to show the impact that core stability issues are having on your customers.

​

What happens if you do nothing? Loss aversion can be a much more powerful force for persuasion than the appeal of gaining something. Make the risk of inaction concrete through projections.

​

Bring a plan, not just a warning. Close the case with an actual proposed approach and rough timeline, so leadership has something to say yes to, not just a problem to worry about.

​

Keep visible work moving in parallel. The reality is that your roadmap will rarely be allowed to be nothing but foundation work. Reduce the risks for everyone, including you, by keeping something more visible in the pipeline and moving forward. Pick small wins with low effort while the majority of the work is focused in the background.​​​