The AI Productivity Paradox: Why Curiosity Beats Role

The Disconnect

“I honestly don’t see the productivity gains everyone’s talking about,” my tech lead said during our weekly one-on-one. We’d been discussing our team’s AI tool adoption, and I had just mentioned how Claude Code had transformed my workflow. “It takes me longer to review the AI-generated code than to just write it myself.”

My coder friend echoed this sentiment over coffee a few days later: “I mean, it’s helpful for boilerplate stuff, but for anything complex? I spend more time explaining the context than it would take to just solve it.”

Meanwhile, I’m over here feeling like I’ve gained a superpower. Claude helps me draft technical specs, brainstorm user research questions, validate market assumptions, prototype features—the list goes on. Some days, it feels like having a brilliant intern who never gets tired and can context-switch between business strategy and technical implementation seamlessly.

What’s going on here? Are we just experiencing different tools, or is something deeper happening?

The Research Reality Check

Then I stumbled across a study that stopped me in my tracks. METR (formerly ARC Evals) published research showing that experienced developers using AI tools actually took 19% longer to complete tasks than those working without AI assistance.¹

Read that again: 19% slower.

But here’s the kicker—despite being measurably slower, these developers believed AI had made them 20% more productive. Even after experiencing the slowdown firsthand.

The perception-reality gap is staggering. And it perfectly captures the tension I was seeing in my own team.

The Wrong Question

My first instinct was to frame this as a role-based problem: “Why do product managers see AI productivity gains while developers don’t?”

But the more I thought about it, the more I realized I was asking the wrong question.

The real question isn’t about roles. It’s about something much more fundamental: What drives some people to successfully expand their capabilities with AI while others struggle?

Because when I look at my own AI usage, it’s not really about being a product manager. It’s about something else entirely.

The Agency Factor

Here’s what I think is actually happening: effective AI usage requires agency and curiosity—a genuine desire to expand beyond your current boundaries.

With LLMs, I can stretch my capabilities in two directions simultaneously:

Toward Users: I use Claude to generate user interview scripts, analyze survey responses, simulate customer conversations, and brainstorm edge cases I might miss. It’s like having access to a research team that never sleeps.

Toward Technical: I use Claude Code to build POCs, understand system architectures, and create functional prototypes that illustrate my ideas to the engineering team. Last week, I built a working dashboard mockup in React—something that would have required a week of back-and-forth with our frontend team to communicate.

From a value chain perspective, I’m constantly using LLMs to expand my business knowledge through ongoing conversations about market dynamics, competitive analysis, and strategic frameworks. It’s like having a consultant available 24/7 who’s read every business book and can help me think through complex problems.

But here’s the key insight: you have to actually enjoy learning to initiate these actions.

The Learning Enjoyment Prerequisite

I don’t want this to sound condescending, because I’m genuinely curious about understanding where my own passion comes from. But I think there’s something about intrinsic motivation that determines AI productivity outcomes.

When I see a technical challenge, my immediate response is: “How can I understand this well enough to contribute meaningfully?” When I encounter a user problem, I think: “What context am I missing, and how can I gather it quickly?”

This isn’t because I’m a product manager—it’s because I’m genuinely curious about expanding my capabilities. The AI tools just happen to make that expansion possible in ways that weren’t feasible before.

My tech lead, on the other hand, is incredibly skilled at what he does. He can architect complex systems and solve challenging technical problems with elegance and efficiency. But he’s not necessarily driven to expand into product strategy or user research—and that’s perfectly fine. In fact, his deep technical expertise is exactly what our team needs.

The difference isn’t competence—it’s motivation direction.

Why This Manifests Differently Across Roles

This curiosity-driven approach to AI might appear more beneficial for product managers, but I think that’s correlation, not causation. Product management, by nature, requires constant context switching and boundary spanning. We’re used to being “good enough” at many things rather than excellent at one thing.

This orientation happens to align well with how LLMs work best—they’re generalists that can help with a wide variety of tasks, but they need human expertise to guide them toward quality outcomes.

Developers, especially senior ones, often have the opposite orientation: deep expertise in specific domains. When you’re already excellent at something, AI assistance can feel like more overhead than benefit. Why use a tool that gives you 80% of what you could produce at 100% quality?

But I’ve seen developers who approach AI with the same curiosity-driven mindset I described, and they see similar productivity gains. They use AI to explore new languages, understand unfamiliar codebases, generate test cases, and explain complex concepts to stakeholders. The common thread isn’t their role—it’s their approach to expanding capabilities.

The Meta-Question

This brings me to a question I’ve been wrestling with: Where does this drive to expand actually come from?

I catch myself using AI to learn about topics I’ll probably never use professionally—diving into urban planning principles when discussing feature adoption curves, or exploring cognitive psychology when thinking about user interface design. There’s something inherently satisfying about connecting disparate domains, and AI makes that kind of intellectual wandering both possible and productive.

Is this just personality? Is it learned behavior from years of product management, where you’re constantly the person who needs to understand “enough” about everything to facilitate good decisions? Or is it something else entirely?

I don’t have a complete answer, but I suspect it’s related to what I wrote about in my first post—the conscious effort to think deliberately rather than defaulting to automation. AI becomes incredibly powerful when you combine it with intentional learning, but it requires you to actively choose expansion over efficiency.

What This Means for Teams

Understanding this dynamic has practical implications for how we think about AI adoption in organizations.

Instead of focusing on role-based AI training (“Here’s how PMs should use AI, here’s how developers should use AI”), maybe we should focus on curiosity cultivation. How do we create environments where people feel safe to experiment with expanding their capabilities? How do we reward learning and boundary-crossing, not just execution?

The developers who struggle with AI productivity aren’t struggling because they’re developers—they’re struggling because they’re being asked to adopt tools that require a different kind of motivation than the one that made them excellent at their current role.

The product managers who see huge gains aren’t succeeding because they’re PMs—they’re succeeding because they’re approaching AI with a learning mindset that happens to align with how these tools work best.

The Bigger Pattern

This connects back to the themes I’ve been exploring in previous posts about context engineering and conscious effort. AI productivity isn’t just about the tools—it’s about the intentional work of expanding your own capabilities and staying curious about domains beyond your core expertise.

The conscious effort isn’t about resisting automation—it’s about using automation to become more capable, more curious, and ultimately more valuable in an AI-augmented world.

Maybe the real AI productivity paradox isn’t about roles at all. Maybe it’s about the difference between people who use AI to become more of what they already are versus people who use AI to become more than what they thought possible.

References