Trust Loop

In my entire career history, you are the first person to ever tackle something like this so quickly. Absolutely incredible - thank you so much!

This email came from one of our Customer Success Managers after I followed through on feedback from a new customer. It’s a result of my simple philosophy for building trust to stack wins and compound value-creation:

Pay attention.
Think critically.
Move intentionally.
Deliver with excellence.
Celebrate and amplify the win.

This works with customers, bosses, direct reports, and your non-work life. When it comes to customers of your product, it’s how you create raving fans. Building trust is a foundational element of any relationship—customers of your SaaS are no different.

Software has bugs. It’s normal and expected. It’s less about the presence of bugs than about how you handle resolving them. Do you seek them out and fix them when they’re reported? Or do you perpetually “put them in the backlog” never to be seen again? The latter approach is most common, and telling customers you’ll “let the product team know” is usually interpreted as you’re never going to fix the issue. I don’t subscribe to this theory. There’s a better way—a path to creating raving fans that market your product for you.

This idea is called the Trust Loop. It lives in the 🐍 Clarity Current of the Claritorium.

🦉 Clarity Codex (Structure): The hidden structure of clarity. Models, language, and frameworks that guide intuition and decision-making.
🐍 Clarity Current (Motion): The invisible force of clarity. Roles, rhythms, and relationships that activate and sustain clarity.
🦎 Clarity Climate (Environment): The emergent environment of clarity. Behaviors, values, and patterns that make clarity natural, resilient, and scalable.

(You can read more about the Claritorium at claritorium.com.)

The Trust Loop is a repeatable cycle for turning customer feedback into lasting trust:

Observe by being present, listening deeply, and finding the signal.
Scope the work out to assess impact and feasibility.
Act and deliver the improvement with urgency.
Close the loop to let them know you heard them and show the fix.
Amplify the win to build momentum and stack more wins.

Observe

I was sitting in a call with a new customer. We were doing a training session to demo our product and answer questions about how to use it. I was there as a silent observer, both to learn more about the product and hear early feedback from the customer. During the demo, someone asked about a specific citation style they use regularly. We have a wide range of citation styles, but not the one they mentioned. Some folks even chimed in the chat to say “about 95%” of their citations use that style, and it would be “difficult” using the product without it.

My colleague leading the call acknowledged the feedback, the fact it was missing in the product, and said they’d forward the feedback to the product team.

But there I was, paying attention to find the signal in the noise. Signal acquired.

I talk about the importance of language a lot. Because it is. How someone says something is often more important than what they say. Feedback is no different. You need to listen to the subtle nuances in the language to discern priority. This missing functionality was a problem, and it was hitting at a critical juncture with a brand new customer.

Scope

Immediately after the call, I started looking in the codebase to understand the scope of work. I wanted to know how big of a change this was. If we have other citation styles already, my assumption to validate was that it would be trivial to add this new style.

I found the place in the code and posted a message to the team. I asked the engineers about it, surfacing the feedback and the priority of the work for a new customer. There was a suggestion to change the current implementation and connect to an API that offers 10,000 different citation styles. This would cover all possible needs, now and in the future.

Sounds great, right? Yes, but not now. This would require more work, introduce new complexities, and create other second-order effects we don’t know about yet.

This is a common situation. You can make the smaller change that solves the problem in a less elegant way with lower complexity; or you can make the bigger change that solves the problem in a more elegant way with higher complexity (and more latent unknowns).

I (almost) always solve this the same way: make the smaller change and track work for the larger change to reconsider when you hit a specific threshold where the bigger change makes sense.

Take time to think critically about the work to do before you do it.

Act

We agreed to make the smaller change and I created the issue. One of the engineers picked up the task and completed it. I reviewed the work in production and took screenshots to share back with the customer. I talked to my colleague who led the call to align on how to proceed with communicating the change back to the customer.

You want to act decisively, but in a way that has the most impact.

Close the Loop

I sent an email back to the customer and included the sales and customer success folks who are managing the customer. I let them know we heard them on their feedback with the missing citation style, and showed screenshots of the live feature.

Make it clear you heard them and tell them what you did about it.

Amplify

That was quick! Thank you very much! We’ll make sure to let the team know.

The customer responded with this message. I shared the feedback to the original message I posted to scope out the work so the rest of the team could see the impact.

This is step is critical.

Engineers need to be close to customers. They need to see, feel, and understand their pain points when they work. The value provided by software engineering shouldn’t be abstracted behind a card in a board. A user story is a shallow abstraction of real problems experienced by real human beings. This step is how you connect the engineers to the impact of their work, which helps them make better decisions as they solve critical problems.

Amplifying impact helps create an Emergent Environment (Issue #37).

Transference

The Trust Loop is designed to build trust. I’ve leaned on this process heavily while I onboard to a new company. I’m not only gaining trust of customers, but of my boss and coworkers, too.

When one of our key projects received attention from the executive team, my boss asked me to figure out the work and build a timeline.

Observe: I heard the ask to “Figure out the timeline for this key project.”
Scope: I broke down what’s needed with engineering input, pitches, and visuals.
Act: I wrote two pitches, recorded Loom videos, and built a timeline visual.
Close the Loop: I delivered the work back to my boss same day.
Amplify: We shared the work with the executive team to align on the timeline.

All relationships are built on trust. The Trust Loop is designed to build trust in any context, stack wins, and compound the effect over time. Relationships get stronger, the product gets better, the team works more effectively, the customers get happier.