Redefining a Product Through Friction Thinking — Why More Features Won

There was a time when I was trying to improve my product by adding more features.

"If only it could automate more." "If only it covered a wider range." — I believed that would get people to use it. I kept pouring in fuel. But then I realized: it was never about the fuel.

In this article, I document the thinking process that led me to fundamentally rethink the direction of my product, DevLoop Runner, after reading Loren Nordgren's The Human Element.

To state the conclusion upfront: I redefined the product from an "automation tool" to "an environment that grows engineers who can collaborate with AI." But getting there involved considerable internal conflict.

"Fuel" and "Friction" — The Real Reason People Don't Move

The core insight of The Human Element is simple.

When trying to get people to act, most of us try to add "Fuel" — a better pitch, a more logical explanation, a bigger benefit. But the primary reason people don't move isn't lack of appeal — it's Friction, the resistance that holds them back.

The book identifies four types of psychological resistance to change:

Inertia: The hassle of changing current habits
Effort: The burden of understanding, learning, and executing
Emotion: Anxiety, loss aversion, identity disruption
Reactance: The pushback when people feel they're being pushed

Reading this hit close to home. It was exactly what I'd been doing with my own product.

Decomposing DevLoop Runner's Friction

DevLoop Runner (devloop-runner.app) is an environment where you collaborate with AI starting from a GitHub Issue — handling design, implementation, PR creation, and documentation generation. I'm confident in the technical depth I've built. I have the philosophy. I have the implementation skills. I can create content.

Honestly, the fuel was sufficient.

So why wasn't it spreading? I examined my product through the lens of Friction.

graph TD
    A["Why DevLoop Runner isn't spreading"] --> B["① Nobody knows it (Inertia)"]
    A --> C["② Weak perceived necessity"]
    A --> D["③ Psychological anxiety"]
    B --> B1["Won't try what you don't know<br>Won't evaluate what you don't try"]
    C --> C1["Nice to have, but urgently needed?<br>→ Most teams say 'hmm...'"]
    D --> D1["GitHub credential concerns<br>LLM API key management"]

My priority ranking looked like this:

Simply unknown > Weak necessity > Psychological anxiety

"Unknown" might look like a marketing problem, but in Nordgren's framework, it's a form of inertia. You don't try what you don't know. You don't evaluate what you don't try. You don't feel the need for what you don't evaluate. "Unknown" is a friction strong enough to prevent action.

The strategically most important friction, though, was "weak necessity." DevLoop Runner is "nice to have" and "interesting." But when asked "Do you need it right now?", most teams hesitate.

The tempting response is "Let's build even more impressive features." But that's adding fuel — it doesn't reduce friction.

The First Target Persona — and the Conflict

While decomposing Friction, the first target persona that came to mind was this:

Organizations that overwork engineers on time-based labor. Engineers there want to ease their burden even slightly. They'd secretly use DevLoop Runner to reduce their effective working hours from an 8-hour block. The freed-up time could go to studying or other pursuits. Same pay but more time — effectively a higher hourly rate.

To be honest, this was a quite realistic hypothesis. I believe such needs genuinely exist.

But I paused here.

This direction has structural problems. A tool used "secretly without the company knowing" can't get organizational approval. No budget allocation. No adoption spread. No referrals. In other words, it doesn't scale.

What bothered me even more was that the product's narrative would become distorted.

Between Productivity Enhancement and Exploitation

Let me go a bit deeper here.

Productivity tools for engineers have a structural dilemma. Even if productivity increases, the surplus gets absorbed by additional tasks, and salaries don't rise. I think this is actually happening at many companies.

If the tool couldn't be spread in a way that lets engineers boost their productivity and reclaim free time, maybe it would be better not to offer the tool at all. I was quite serious about this.

But thinking more calmly, not releasing the tool wouldn't fix the exploitation structure either. Instead, efficiency gains would just be introduced top-down by management.

This is where things clicked for me:

The problem isn't the tool — it's the organization's allocation rules. Tools themselves are neutral; when structures are distorted, even good tools get used in distorted ways. What matters, then, is who the tool is designed for.

From "Automation Tool" to "Capability-Expanding Environment"

Through this internal conflict, a clear picture emerged:

graph LR
    subgraph "❌ Time-Saving Tool"
        A1["Efficiency"] --> A2["Cost reduction context"]
        A2 --> A3["Surplus labor for management"]
        A3 --> A4["More tasks → Exploitation risk"]
    end

    subgraph "✅ Capability-Expanding Environment"
        B1["Thought expansion"] --> B2["AI collaboration skills"]
        B2 --> B3["Increased market value"]
        B3 --> B4["Negotiation power ↑ → Options ↑"]
    end

"A tool that saves time" and "an environment that expands capability." The content might be similar, but the philosophies are entirely different.

Selling time savings means creating "surplus labor" for management. But selling capability expansion raises the individual's market value itself. Negotiation power grows. Independence from the company develops.

Agency isn't about winning against the company — it's about not depending on it.

The moment this clicked, the product concept shifted entirely.

DevLoop Runner isn't an automation engine. It's an environment that grows engineers who can collaborate with AI.

Why Visible Collaboration Processes Matter

Another fork in the road appeared here.

From a product perspective, a "black box where AI does everything" might sell more easily. But when the thinking process is invisible, users' capabilities don't grow.

What DevLoop Runner aims for is this flow:

Input an Issue (Human)
AI presents a design proposal (AI)
Judge and refine the design's validity (Human)
AI implements (AI)
Focus on review and improvement (Human)
PR and documentation are generated (AI)

Humans don't become unnecessary. The human role evolves from "implementation" to "judgment."

And because this process is visible, users develop skills: the ability to delegate to AI, to structure Issues, and to clarify review perspectives.

Honestly, a black box would be easier and probably sell better short-term. But it contradicts my philosophy. A tool meant to expand engineers' agency shouldn't strip away their thinking.

The Moment a Unique Position Became Clear

Comparing with similar services, most of them sell "code generation efficiency," "PR automation," "effort reduction," and "cost savings."

The axis I've found is "growing engineers who can collaborate with AI." That's a different layer entirely.

Moreover, it's consistent with my background: introspection research (ORIMD), career consultant certification, and the theme of engineer agency. Everything connects into a single thread.

The concept might be the same, but the context for why I'm doing it is different. The depth of that context becomes the unique positioning — that's what I felt.

Landing Page Rebranding

With the concept settled, I rewrote the landing page entirely.

The hero copy became:

In the AI era, the engineer's role is changing.
DevLoop Runner is an environment for practicing that change.

Initially, I had a question-style copy: "Will AI take your job? Or will you become someone who masters AI?" But that has an alarmist tone. Moving people through fear doesn't align with my philosophy.

I chose words that arrive quietly but land deeply.

Across the entire landing page, I kept these principles in mind:

Don't say "cut your time in half." Say "the center of gravity of your thinking shifts."
Words to avoid: blazing fast, dramatic reduction, revolutionary, overwhelming efficiency
Use story-driven persuasion (depict Before/After as one engineer's typical day)
Convey: "Efficiency is a side effect. The essence is the evolution of thinking."

Honestly, it's still being refined. The concept is abstract, so clarity needs continued polish. But I'm confident the direction won't waver anymore.

Retrospective: Look at Friction, Not Fuel

The biggest takeaway from this entire thinking process was that no matter how much fuel you add, it won't reach people if friction isn't reduced.

Add features. Improve performance. Expand coverage. That's all Fuel. But the real reason a product doesn't spread is usually on the Friction side.

And when you decompose friction, before you hit technical issues, you arrive at the question: "What does this product exist for in the first place?" For me, that was the biggest harvest.

DevLoop Runner is still reaching only a small audience. But with the axis of "an environment that grows engineers who can collaborate with AI" now established, I believe every decision from here becomes dramatically simpler.

Add fuel or dissolve friction? It's not one or the other — you need both. But since my attention had been entirely on adding fuel until now, gaining the perspective of dissolving friction was the real breakthrough.