The Problem Isn't You. The Software Just Wasn't Built for How You Work.

A founder I was working with kept describing a routine technology task as something she was "struggling" with. Not a complex task — something that should have been straightforward. But the word came up repeatedly, with the kind of weight people reserve for real difficulty. Not frustration with a tool. Frustration with herself.

That word choice was the signal. In NLP training, you learn to listen for language that carries more emotional weight than the context warrants. "Struggling" for a task that should take five minutes isn't a description of the task. It's a description of how the person feels about themselves in relation to the task. She wasn't failing at the technology. The technology was failing her — and she'd internalized the gap as a personal shortcoming.

The misdiagnosis nobody catches

This pattern shows up constantly, across every industry I've worked in. A business owner apologizes for not understanding their analytics dashboard. A clinic administrator says they're "bad at computers" because their EHR system takes twelve clicks to complete a two-step process. A nonprofit director blames their own learning speed when the donor management platform requires a certification course to do basic reporting.

The common thread: capable, intelligent people concluding that they're the problem, when the actual problem is a product designed for a different user, a different workflow, a different context, or a different budget.

Mainstream software is built for the average case. It optimizes for the largest addressable market, which means it optimizes for the workflow that the most people approximately share. If your workflow deviates from that average — because your industry is different, your team size is different, your technical comfort is different, or your budget constrains which tools you can string together — the product creates friction. And most people blame themselves for the friction instead of the fit.

What happened when I built around her

Once I heard the pattern, the next step was straightforward. I didn't teach her to use the existing tool better. I didn't send her training videos. I built her custom applications that matched her actual workflow — her hardware, her daily routine, her budget, her learning style.

The technology did the same thing the mainstream product did. But it did it in a way that fit how she actually worked, not how a product manager in San Francisco assumed she worked.

The "struggling" disappeared. Not because she suddenly got smarter or more technically skilled. Because the friction was gone. The interface matched her mental model. The steps matched her routine. The tool worked the way she expected things to work, because it was designed around her expectations rather than asking her to adapt to someone else's.

The drive was already there. The competence was already there. What was missing was technology delivered in a form that respected how she operated — her device, her schedule, her cognitive style, her budget constraints. Once those were accounted for, the adoption was effortless.

Why mainstream products create this problem

Product design at scale requires standardization. A SaaS company serving 50,000 users can't build 50,000 custom interfaces. They build one interface and optimize it for the usage patterns that the largest segment shares. This is rational product development. It also means that everyone outside the largest segment gets an experience that ranges from "slightly awkward" to "fundamentally incompatible."

The research on this is clear. Status quo bias (Samuelson & Zeckhauser, 1988) means most users accept the default configuration even when it doesn't serve them. Cognitive load theory (Sweller, 1988) explains why complex interfaces with too many options cause capable people to feel overwhelmed — the interface is exceeding working memory capacity, not the person's intelligence. The paradox of choice (Schwartz, 2004) demonstrates that more features and options often reduce satisfaction and increase the feeling of inadequacy ("everyone else seems to handle this fine — what's wrong with me?").

The user isn't deficient. The product-user fit is wrong. But from the inside, those two things feel identical.

The behavioral science of technology adoption

Habit formation research (Lally et al., 2010, published in the European Journal of Social Psychology) found that new habits take an average of 66 days to form, with a range of 18 to 254 days depending on the complexity of the behavior and how well the context supports it. The key phrase is "how well the context supports it."

A tool that fits your existing workflow creates a supportive context for habit formation. The new behavior slides into an existing routine with minimal cognitive disruption. A tool that requires you to change your workflow, learn new patterns, and adapt to unfamiliar interactions creates a hostile context — and habit formation either takes dramatically longer or fails entirely.

This is why enterprise software adoption rates average 40-60% even after extensive training programs (Slack's 95% adoption rate, achieved through cognitive load management, is the exception that proves the rule). The training addresses knowledge gaps. It doesn't address context fit. You can teach someone every feature of a product and they'll still underuse it if the product requires them to work in ways that conflict with their established patterns.

What this means for how we build

At Kief Studio, one of our core operating principles is that technology should adapt to the person, not the other way around. This isn't a philosophical statement — it's a design constraint that changes specific architectural decisions.

We start with observation. How does the person actually work right now? Not how they should work according to a best-practice document. Not how a consultant thinks they should work. How they actually work — the tools they already use, the sequence they follow, the devices they're comfortable with, the time they have available, the budget they're operating within.

Then we build technology that slots into that reality. Sometimes that means a custom application. Sometimes it means configuring an existing tool in a non-standard way. Sometimes it means replacing three tools with one that does less but fits better. The technical solution varies. The design principle is constant: work with the person's actual context, not against it.

The difference in adoption is measurable. Systems built around observed workflow patterns adopt in days. Systems that require workflow changes adopt in months, partially, with ongoing support tickets.

The bigger point

There are millions of business owners, operators, and professionals who believe they're "bad with technology" because mainstream products don't fit how they work. They've internalized product-fit friction as personal failure. They apologize for asking questions that the product's design should have made unnecessary.

The technology industry treats this as a training problem. It's not. It's a design problem — and it's solvable. Not by building better mainstream products (those serve their market well). By recognizing that the mainstream product isn't the only option, and that custom-fit technology is more accessible than most people assume.

Sometimes the person who's "struggling" with technology doesn't need a tutorial. They need someone who listens carefully enough to hear what the struggle is actually about — and builds something that makes the struggle irrelevant.

---

Related reading

• Positive Psychology Isn't Soft. It's How Founders Survive.
• Why I Study Consumer Behavior as a CEO (And What It Actually Changes)
• Default Bias: The Most Powerful Design Decision You'll Ever Make
• The Problem with Generic Tech Recommendations
• If the Recommendation Came Before the Questions, It's Not Advisory

Frequently asked questions about the problem isn't you

Why do people blame themselves when software doesn't work for them?

Because mainstream products are designed for the average user, and when you don't fit the average, the experience feels like a personal failure rather than a product-fit problem. Status quo bias (Samuelson & Zeckhauser, 1988) means most people accept default configurations without questioning whether the product is right for them. The result: capable people conclude they're "bad at technology" when the technology is simply bad for their specific context.

Is custom software actually affordable for small businesses?

It depends on scope. A custom application that replaces a poorly fitting SaaS tool for a specific workflow can cost less than two years of the SaaS subscription it replaces — with the advantage of fitting the user's actual needs. The cost equation has shifted significantly with modern development tools and frameworks that allow faster delivery of focused, single-purpose applications.

How do you identify when someone has a product-fit problem versus a training problem?

Listen for emotional language around routine tasks. If a competent professional describes a straightforward task as "struggling," "fighting with," or "never getting right" — and the task itself isn't inherently complex — the friction is likely between the product and the person's workflow, not between the person and the concept. Training solves knowledge gaps. It doesn't solve contextual misfit.

What's the connection between behavioral science and technology adoption?

Habit formation research (Lally et al., 2010) shows that new behaviors form faster in supportive contexts — when the new tool fits existing routines and mental models. Technology that requires significant workflow changes creates a hostile context for adoption, which is why enterprise software averages 40-60% adoption even with training programs. Building technology around observed behavior patterns rather than idealized workflows produces dramatically higher adoption rates.