What We Did to Cultivate SaaS User Loyalty and Reduced Churn

Savio’s origin story starts ten years ago at the CrossFit gym where I met my business partner, Ryan Stocker. (There’s something about suffering together that creates connection.)

We clicked, and we discovered we had a lot in common: we were both product leaders who had worked at big companies like Microsoft and ESPN and both had backgrounds in dev. We were also both at the point in our careers where we were ready for a bit of risk and to build something for ourselves.

So we did what any reasonable CrossFit buddies would do: we started a SaaS business together.

Ten years later, Savio is the third business we’ve built together (we successfully sold the last two). While we’re both proud of our previous work, we both agree that Savio is different. 

We’ve built something truly special—it’s a frigging great piece of software. 

I say that not in an arrogant or self-congratulatory way (we’re too humbly Canadian for that). I simply recognize that we’ve built something that effectively solves our customers’ problems. We know it is good because that’s the feedback we consistently get and because we maintain super-low churn rates (we’re talking…). 

Our product isn’t good by accident. We’ve both been building software for 20 years, and we’ve used our (many) past mistakes to hone a system for building software that customers find valuable. 

Here, I want to share how we did that with Savio. I’ll explain the specific decisions we made and why (along with practical examples and screenshots), so you can apply them to make your own software better.

Giddyup.

1. Decided to be customer-centric and product-led

The real seed of our success was a decision to be committed to our customers. We built our process around the idea that we would be dedicated to their experience. It’s our core value—we are passionately product-led. 

It’s a founder’s expanded take on that old Kevin Costner Field of Dreams moment: If you build it—and it’s good, and you make sure it solves an important problem, and you get your marketing right—they will come. 

What we did: We started by having hundreds of conversations with product leaders. We wanted to fully understand their problem and took pages and pages of notes. 

Because of our research, we didn’t build Savio in 2015 when we thought of it. At that time product leaders had the problem that Savio solved, but they didn’t recognize it—so we knew they wouldn’t be searching for a tool like Savio. Instead, we waited until 2019 when our research revealed that, yes, now they recognize the problem it solved. 

Then, as we built Savio, we created a dynamic system to collect and analyze product feedback. It involved asking for feedback during sign-up, in the app, and even directly to customers via Zoom. Then we used our own product to track that feedback and use it to build our roadmap. And then, we have consistently been careful in closing the loop. 

The result: The product we built solves a problem that we know product leaders, customer success teams, salespeople, and support teams have. And we consistently improve it by building the features we know our customer base is asking for, creating extraordinary customer satisfaction.

2. Tweaked our sign-up flow to get the right information about our customers.

In the first version of our onboarding process, we sent a welcome email to new free trial sign-ups. In that email, we asked them what problem they were trying to solve. 

[Screenshot of email]

It was useful for a few reasons:

1. It helped us learn about what the product needed to do, our users’ goals, and how we could help them be successful. 

2. It got us into conversations with prospects. When someone responded to the emails, it meant they were engaged. It allowed us to reach out and start a conversation to go deeper on their needs. That conversation helped us better show them the value of Savio, which helped our trial-to-paid conversion rate. 

3. It let us segment them by the problem they were trying to solve. 

But our response rate was fairly low. [Do we know how low, approximately?]

What we did: So we in version two, we decided to add a screen on signup that asks two questions:

1. What team are you on?

1. What the main goal of the user is

We used those questions to segment users into different onboarding flows.  

• If users said they wanted to organize feedback from a support tool or CRM, we give them an onboarding flow that helps them set their tool up. 

• If users want to set up a public voting board, we give them an onboarding flow that walks them through publishing a voting board. 

• If they click, “Something else” we ask what, and then take them to a more general onboarding flow. 

Why this helped: This change in the information we asked for during sign-up was extraordinarily helpful. For every person that signed up, we learned—at a coarse level—what they were trying to do and what problem they were trying to solve.

That had two big impacts.

First, it meant we could serve targeted onboarding. That helped get our customers to their “Aha! Moment” so that they could see the value of Savio. Once they saw the value, they were less likely to churn. 

Second, it also helped us understand who our main customer was. And that turned out to be a big deal… 

3. Dug until we understand our ideal customer profile

Ryan and I are product managers, and we built Savio to basically be the tool that we were always searching for. Because we had ourselves in mind as the target user, we assumed that our main customers would be other PMs like ourselves. 

What we did: But, we’re data-driven and curious, and we knew how useful it is to have a clear profile of your ideal customers. 

We should mention here that when you’re building software, SaaS customer personas based on demographics or other characteristics aren’t very useful. We believe a much more useful framework is the “Jobs to be Done” which focuses on the goals of the user as the best way to define, categorize, capture, and organize your understanding of your customers’ needs.

In other words, figure out what your customers are trying to do with your software and use that to segment them.

The result: In fact, we found out that customer success teams were the ones really interested in the tool. While PMs were the ultimate consumers of feedback that Savio tracks, it’s customer success and support who talk to customers and are the experts in the needs of customers. They’re also incentivized to have the Voice of the Customer make it onto the roadmap. 

We learned:

1. Customer success and support teams were typically the ones looking for an easy way to collect, centralize, and organize feedback. They’re often who seek out a tool like Savio and who test it.

2. PMs consume the information and can be blockers—they often decide whether to choose Savio or another tool. It’s important that we make clear the utility of the tool to this group. 

3. Sales teams and professional service teams also use the tools. Some marketers do too, but to a lesser extent.  

We used that information to ensure that our content marketing strategy and website copy is relevant for customer success teams and PMs, while ensuring that other customer-facing teams also see their needs represented. 

4. Investigated (and disproved) our own hypotheses about our product

Building software is an art, but it’s also a science. We play into the science side by building hypotheses into every major project or initiative. Then we make sure we collect the data to provide evidence either for or against that hypothesis. 

Understanding our ideal customer profile was a good example of this. We started with the hypothesis that the main customers for our tool would be product managers, like us. But, in fact, when we looked at the data, it was customer success team members who were mostly signing up for the product. We ended up disproving our theory—or at least adding some significant nuance. 

What we did: More generally, we built the scientific process (a small version of it) into our work. When someone on the team has an idea that would require significant resources, we ask them to create a short proposal document—basically, they need to articulate the problem, their proposed solution, the resources it would take, and so on. We also ask them to specify their hypothesis, as well as relevant metrics. That way, when we try something new, we have a framework for evaluating it. 

The result: Embedding a framework to be explicit about our expectations and seeking evidence for a hypothesis gives us an objective way of evaluating the success of our experiments. It provides us with data to help us make better strategic decisions—like who should be the primary audience for our marketing messages.

5. Tracked our feedback

We started Savio because we didn’t find an alternative that really solved the problem of tracking product feedback and feature requests in a way that really helped you quickly see the high-impact features to build next. 

What we did: We’re all about eating our own dog food. We use Savio to track all our customer feedback and feature requests, and collect them in one place. We regularly run our product meetings using Savio, and then follow features through the development process using the Shortcut integration. When we build a feature, we make sure to close the feedback loop and tell the people who asked for it. 

The result: Three years in, we’ve now tracked over a thousand pieces of feedback. 

That customer data has been incredibly helpful in understanding where to spend our dev resources. And our product has proven to be extremely sticky—we have a super low churn rate. We attribute that in part to being really responsive to feature requests and building a product that solves our customers' problems.

6. Asked for feedback from everyone, not just active customers

Asking for feedback from existing customers isn’t exactly ground-breaking. But it’s much less common to ask for feedback at other stages of the customer journey—from prospects, churned customers, and lost deals. 

What we did: We made a point to ask everyone for feedback at every stage of the development process. For example, we were careful to ask for feedback from our lost deals—the people that ended up not choosing our product. When people ended their free trial without converting, we asked them why. (And, we asked free trialers why they did convert, too). We also asked people why they churned. 

Guide: How To Use Feedback to Build Better Software At Every Step in Your Development Process (With Examples)

Result: We got very valuable insight from this around the jobs that people need Savio to do, the role people are in, our pricing, and the major hesitations customers have. Churned customers also gave us very valuable feedback around why they chose another tool. 

We used all that feedback to:

• Get buy-in from stakeholders on our roadmap

• Understand specific use cases and scenarios

• Write feature specs

• Identify customer champions

• Vet beta versions of our product. 

7. Wrote careful and detailed specs

Writing feature specifications is a skill, and we’ve intentionally developed it over time. Good specs help you put a bullseye on what the feature looks like so you know what “done” is. 

I’ve seen firsthand how poor specs become costly in the long run. If you don’t write a thorough spec, with wireframes, and edge-case handling, you’re setting yourself up for problems down the line. It’s way easier (and cheaper) to make changes to wireframes than it is to change code.

What we did: We got really detailed in our specs. For example, we make sure to think carefully about what kinds of inputs can go into each field, what errors look like, and so on. 

We also give our devs an opportunity to read the specs, and provide their input on changes. This helps us meet deadlines and give better estimates about the resources we’ll need to build a feature. When we need to, we can simplify to stay within our “resource” budget. 

The result: We waste much less time revising features after they’re built, and it helps us avoid shipping buggy features. 

8. Revised and polished our user interface

In her article Your App is Making Me Fat, Kathy Sierra presents evidence that people have a limited pool of cognitive resources and that both willpower and problem-solving draw resources from that same pool. She argues that if your app is difficult to use and requires problem-solving, she’ll have fewer resources available to muster the willpower to eat healthily and go to the gym.

I’m not sure there’s such a clear link between healthy eating behaviors and app design, but I think the conclusion is spot on: the better your software is, the better my life is. So, make sure you provide a really good user experience. 

What we did: We have been incredibly thoughtful about the main workflow in Savio: triage. Triaging feedback—understanding it, adding details, and assigning it to the right feature request—can be difficult and unrewarding. It’s the “eating your broccoli” equivalent of the feedback-logging process.

We carefully sanded the edges of the triage interface and polished it up to make it faster and easier. For example, 

1. We changed it from one long form to side-by-side, so you don’t have to scroll and you don’t miss key information. 

2. We customize the size of the feature request list based on the size of your screen so you could see a big list of your feature requests.

3. We also added more context to each item in the list to help you pick, including a panel to show you what the feature request is about to help you pick the right FR and eliminate mistakes. 

4. We added a “Snooze” feature to skip some feedback from triage when you need more information. 

The result: These small improvements, and many others, are a bit like adding bacon and cheese to the broccoli—they make it a much more pleasant experience. We’ve also seen it boost user engagement. 

These changes may not have much effect on your ability to resist junk food, Kathy, but we do think they will make your life a little better. 

9. Made integrations stupid simple

Our SaaS product requires integrations. Savio’s ability to flexibly centralize feedback from virtually any source is one of the main reasons it's better than any of our competitors. 

What we did: Because that connection piece is so central, we knew we needed to make integrations a piece of cake. We invested a ton of time in getting our integrations just right and making them incredibly easy to set up—even for non-dev users. 

The result: Our customers are constantly surprised at how easy it is to connect their tools. You can set up all the integrations—even the one to Salesforce—in literally a couple of clicks. No phone calls, no dev resources. 

10. Used a server-side rendered HTML Django app with HTMX sprinkled in

It’s quite common to build single-page applications using frameworks like React. But that model has some important limitations, so we decided not to use it. 

What we did: We chose a tech stack that was familiar to us to minimize learning new tools. It also fits the CRUD (Create, read, update, and delete) app style, which we are big fans of.

We’re believers in server-side rendered apps instead of client-side rendered apps, but these are typically less good for interactivity. So, on top of that, we also included HTMX to build back in some of the interactivity that makes Savio easier to use. 

The result: Those early tech decisions made a big difference. The foundation we used allowed us to build our MVP quickly and stay nimble, while also setting us up to easily scale over time. We’ve been able to maximize speed and stability while also remaining efficient and able to maintain the app. 

11. Personally provided support as founders

Founders will often offload support as one of the first things they do. And we get why—there’s a lot going on running the company. Support calls can feel relatively low priority compared to attracting funding, setting the company’s strategic vision, etc. 

What we did: We continue to provide customer support. There are a number of reasons for this: 

1. We see it as an opportunity to get really detailed feedback from our customers about what they need and unpack how they use the tool. That helps when it comes to directing the company’s strategy, marketing, product development, and so on. 

2. It helps us fix bugs quickly. When we’re listening to our customers, we stay really close to the product. Other companies take their time to fix bugs, but seeing them resolved quickly feels very satisfying for a customer. Since both Ryan and I are also devs, sometimes we fix the bugs ourselves and then follow up immediately. When we fix a bug on the same day it’s filed, customers are super happy. We build trust. 

Customers also know that the alternatives to Savio are these behemoth companies where bug reports go into a black hole and sometimes are never fixed. By being on the phone directly with customers and then addressing their issues, we help them feel confident that if something goes wrong with Savio, we’ll fix it. 

In one instance, a customer needed help getting her Savio data into an Excel report. I did it for her, and I even built the pivot table. The goodwill that generates—really helping customers solve their problems—is the magic behind really strong customer retention. It leads to insane customer engagement and genuine customer relationships. 

We get that’s not realistic for all companies, but we’re taking advantage of it while we’re still relatively small and nimble. 

The result: We’ve found that this strategy of staying close to our customers, having them see the founders listen to their needs, and fixing bugs quickly results in extraordinarily high customer loyalty and satisfaction, which manifests in low churn rates—and referrals via word-of-mouth.

12. Used support as an opportunity to hop on Zoom and really understand what the customer is after

Sometimes our intercom support chats blossom into quick, impromptu Zoom calls. We encourage this.

What we did: We have the customer walk us through their problem and what they’re trying to do. That helps us more easily solve their problem, but inevitably we also learn a metric ton about how our customers use our products. 

The result: We are better positioned to build a better product over the long term. For example, we used this method to learn about how customers use the triage workflow. 

And our high-quality support via multiple touchpoints generates very loyal customers. 

13. Watched people stumble around our app

No matter how much testing you do, your customers will find pitfalls—things that make your app difficult to use. 

What we did: Besides watching people use our app on Zoom, we use FullStory to see precisely how users use our app. It lets us see where people stumbled in our app, which helps us identify and fix those problems.

The result: Continuous UI improvement, a much smoother customer experience, and increased product usage.

14. Turned sales calls into product discovery

Sometimes we’re chatting with a prospect and they ask about a feature that we’re thinking about building. 

What we do: If it’s appropriate, we’ll use the sales call to do some product discovery. 

For example, once we were talking to a prospect and they told us they needed to be able to easily close the loop with customers. We were about to build our close-the-loop feature and we had already spec-ed it out. So we showed the customer the specs to see what they thought and if it would solve their problem. 

That strategy has been really useful for us with a bunch of different features.

More generally, we see the role of sales as not just selling the product, but also understanding user needs, pain points, and potential solutions. 

The result: We get more feedback about our future functionality, and also boost customer acquisition by helping new customers and prospects see that our product will continue to improve. 

Customer-centricity is a core value

Each of the above tactics and strategies that we’ve used to build a terrific product is based on a deep respect for our users. 

What our users think matters to us. 

It’s not the only criteria we use to build our product roadmap, but it’s a central one. That brings me to my final reflection on our success in creating a successful product: my business partner and I share happy customers as a value (rather than just a marketing tool or means to a higher bottom line). 

I’m not suggesting that making friends at CrossFit gyms is the secret to building great software or SaaS companies, but it worked for me.

If that’s not your journey, fair enough. But at least consider building a robust system for tracking customer feedback and feature requests.

Last Updated: 2023-06-21

Want more articles like this?

Product Leaders from Slack, Zapier, and Appcues read our newsletter to delight customers, lower churn, and grow revenue.

Send me more like this

Unsubscribe anytime.