When I first started building software for gyms, I thought I was doing everything right. I was talking to the people who used it every day — the front desk staff, the trainers, the assistants. They were quick to tell me what they needed: a new button here, an extra report there, a way to print labels faster, and so on. I took notes, nodded eagerly, and built exactly what they asked for.
And that’s how I wasted three months.
The new “feature” — a fully customized attendance-tracking workflow with six configurable filters and printable rosters — was used twice. The owner didn’t even know it existed. When I showed it to her, she said something that stuck with me:
“Oh yeah, that’s for the front desk. But honestly, I just need something that shows me who’s paying and who’s not.”
That moment hit hard. I had built for the wrong audience.
The Employee View vs. The Owner View
When you build software for small businesses, you quickly learn that “the business” isn’t one person. It’s a whole ecosystem of roles, habits, and incentives. The front desk person sees the world through their daily tasks: checking people in, answering phones, fixing printer jams, fielding customer complaints. Their idea of a “problem” is something that slows them down.
The owner, meanwhile, is playing a completely different game. They’re thinking about revenue, retention, cost per lead, chargebacks, and whether they can take a weekend off without everything falling apart. They don’t care if the front desk has to click one extra button, as long as the business runs smoother and brings in more money.
Both perspectives matter, but only one signs the checks.
The Illusion of “Needs”
I’ve lost count of how many times I’ve heard something like this:
“We need a button that automatically checks in a member, prints a receipt, and texts their trainer all at once.”
Usually, they don’t actually need that. What they mean is, “I wish my day went a little faster.” It’s a workflow preference dressed up as a business requirement.
It’s easy to mistake this for genuine product feedback, especially when you’re early in a relationship and eager to impress. But if you take every “need” at face value, you’ll end up duct-taping together a Frankenstein system built on personal preferences rather than business goals.
A good rule of thumb:
If you can’t connect a feature request to revenue, retention, or reduced headaches, it’s probably not a real business need.
The Resistance Factor
Another lesson: people resist change. Especially employees who didn’t ask for it.
You can build the most elegant, efficient system in the world, but if it changes how the staff do their job, expect pushback. Sometimes it’s subtle — the new system “doesn’t work right” or “takes too long.” Sometimes it’s more open: “We liked the old one better.”
I once rolled out a new membership dashboard that made it much easier for owners to track delinquent payments. But the front desk staff, who were used to manually chasing down members and taking cash, didn’t like it. Suddenly, “the system was broken” every other day.
Turns out they weren’t lying. It was broken for them. They had a routine that gave them a sense of control and importance, and the software disrupted it.
That’s not malicious — it’s human. Change management is part of product design, especially in small businesses where “processes” are just habits with name tags.
When Employees Sabotage (Even Accidentally)
One of the most eye-opening experiences came from a gym that swore their staff “loved” the old system. The owner wanted to move to ours for better reporting and billing. We did the migration, trained the team, and went live.
Two weeks later, I got a call.
“The system doesn’t work. None of the members are showing up correctly.”
After some digging, we found the issue: one front desk employee had been entering every new member as “Guest” because they didn’t like the new workflow. Their reasoning? “It’s faster this way.”
They weren’t trying to tank the project. They were just doing what made sense to them. But the result was chaos. Membership counts were wrong, billing failed, and the owner was understandably frustrated.
The lesson? You can’t assume user compliance — especially when change feels imposed. Even the best software will fail if the people using it don’t buy in.
Owners Think in Systems, Not Screens
When I talk to owners, the conversation is completely different. They rarely ask for a “button” or a “setting.” They ask for outcomes.
- “I need fewer missed payments.”
- “I want to see who’s at risk of canceling.”
- “How do I automate reminders so I don’t have to chase people?”
These are system-level problems. They’re not solved by adding a new dropdown; they’re solved by aligning product design with business strategy. Owners don’t need to know how it’s built — they just need to know it moves the needle.
That’s why I always make it a point now to frame product discussions around impact. Instead of “Do you want me to add this feature?”, I ask, “If we build this, how does it help your business grow or save time?”
You’d be surprised how often that reframes the whole conversation.
The Cost of Listening to the Wrong Person
When you’re selling B2B SaaS to small businesses, it’s tempting to build what the loudest voice asks for. But if that voice isn’t the one holding the credit card, you’re walking into a trap.
I’ve had employees lobby hard for features that ended up killing deals. They were passionate and convincing — and completely disconnected from what the owner valued.
One time, a gym’s assistant manager begged us to integrate with a specific SMS tool. “We need this or we can’t use your system,” she said. We spent weeks building the integration. When I finally demoed it to the owner, he said, “Oh, we canceled that service last month. Too expensive.”
Months of work. Zero ROI.
That experience taught me that enthusiasm from non-decision-makers can be deceptive. It feels like validation, but it’s often just noise.
Why Owners Are Harder (and More Valuable) to Talk To
Owners are busy. They’re juggling staff issues, marketing, maintenance, and probably teaching a class or two themselves. It’s easier to get ahold of an employee, and it feels more productive to talk to someone available right now.
But when you take the easy path, you end up optimizing for the wrong things. You’re solving operational annoyances instead of business problems. And those problems — the ones that actually matter — only come from the top.
Talking to the owner isn’t just about authority; it’s about perspective. They see the whole chessboard. They know which pain points are worth solving, which ones they’ve already accepted as “the cost of doing business,” and which ones they’ll actually pay to fix.
A Practical Framework for Founders and Developers
Here’s what I’ve learned after years of selling and building software for small business owners:
- Start every conversation with “why.”
If someone asks for a feature, ask, “Why do you need that?” Keep digging until you hit a business goal, not a workflow habit. - Validate with the decision-maker.
Even if you get great feedback from employees, loop back with the owner. A simple “Does this align with your priorities?” can save you months of wasted work. - Design for outcomes, not requests.
Translate what users say into what the business actually needs. “I need a way to print attendance sheets” might really mean “I want an easier way to track who’s coming.” - Anticipate resistance.
Don’t assume adoption will be automatic. Train the staff, explain the “why,” and help them see how the new system makes their life easier too. - Build relationships with owners, empathy with staff.
Owners decide to buy, but staff decide whether your product succeeds. Treat both with respect, but don’t confuse one’s enthusiasm with the other’s authority.
The Hard Lesson (And the Best One)
Building for small businesses is rewarding because you see the impact directly. A feature you shipped last week might literally save someone an hour a day or help an owner finally get a weekend off. But it’s also messy. You’re dealing with human dynamics, not just code and logic.
If you take one thing from all this, let it be this:
Talk to the person who feels the pain of the problem, not just the person who experiences the inconvenience.
The front desk might know the software better, but the owner knows the business better. One wants convenience. The other wants sustainability.
Build for the one signing the checks, and you’ll build something that lasts.
