Tobias Lütke, co-founder of Shopify, coined the term "trust battery" to describe relationships between coworkers. Every interaction either charges or drains the battery. A new relationship starts at 50 percent. Kept commitments push it higher. Broken ones pull it down.
The same dynamic applies — maybe more intensely — between a product team and its earliest users. Except the battery doesn't start at 50. It starts closer to zero.
Your first users don't know you. They found your product through a tweet, a recommendation, or a desperate search for something that solves their problem. They showed up with hope and skepticism in equal measure. Every interaction from that point is a deposit or a withdrawal.
In a community of ten thousand users, one person's experience is a data point. In a community of fifty, it's a story everyone hears by Thursday.
Small groups have short feedback loops. When you ship a fix, people notice. When you answer a question at midnight, people remember. When you say "we'll have this done by Friday" and it's done by Wednesday, the word spreads through the group like heat through a small room.
This is the compounding advantage small teams have over large incumbents. You can't buy this kind of trust. You can't manufacture it with a brand campaign. It accumulates through a pattern of kept promises, observed over time, by people who talk to each other.
The math works both ways. Break a promise in a small community and there's nowhere to hide. No PR team to spin it. No segment of happy users large enough to drown out the disappointed ones. The battery drains fast, and everyone watches the meter drop.
Most founders think about trust as a consequence of building a good product. They treat reliability — uptime, consistent behavior, accurate documentation — as hygiene. Table stakes.
That framing is wrong. For early-stage products, reliability is the feature. It's what separates you from the last three tools your users tried and abandoned.
Think about it from the user's perspective. They've been burned before. They migrated data into a product that changed its pricing. They built a workflow around a feature that got deprecated. They relied on an integration that broke on a Saturday and didn't get fixed until Tuesday. Every one of those experiences drained their trust battery with software in general.
When you show up and things just work — consistently, predictably, boringly — you're not meeting expectations. You're exceeding them. The bar has been lowered by everyone who came before you.
Specific actions matter more than intentions. Here's what actually moves the needle with early users:
Say what you'll do, then do it. If you promise a weekly update, send it every week. Not most weeks. Every week. The consistency is the message.
Communicate before you're asked. If something is broken, say so before users report it. If a deploy is happening, give people a heads-up. The worst thing isn't the problem — it's discovering the problem and realizing the team already knew.
Make your constraints visible. Early users understand you're a small team. They don't expect perfection. They expect honesty about what's happening and what isn't. "We can't build that this quarter, here's why" builds more trust than silence or vague promises.
Fix the small stuff. A typo in an error message. A tooltip that says the wrong thing. A settings page that loads slowly. These aren't high-priority bugs in most triage systems. But fixing them signals that someone is paying attention — and attention is what trust is made of.
The drains are predictable. Saying "soon" and meaning "never." Changing behavior without notice. Going quiet during incidents. Treating documentation as an afterthought. Shipping something half-finished and hoping nobody notices.
Each is small on its own. But trust batteries don't drain in a single dramatic failure. They drain through a series of small disappointments that accumulate into a feeling: these people don't respect my time.
Once a user has that feeling, feature launches don't fix it. Discounts don't fix it. Only a sustained pattern of different behavior fixes it — and by then, most users have already left.
Trust compounds. A user who trusts you will forgive the occasional mistake. They'll give you the benefit of the doubt on a design decision they don't love. They'll recommend you to a friend without being asked.
A group of users who trust you becomes a community that defends you in public and gives you honest feedback in private. That's the foundation of a durable business.
Trust compounds faster in small communities than large ones. But only if you treat reliability as a feature — something you build deliberately, measure honestly, and protect fiercely. Not a side effect of good engineering. The whole point.
Be the first to comment.
0 comments
Loading comments...