Back to Blog
Product and Engineering: The Real Conversations We're Not Having
EngineeringAIProduct

Product and Engineering: The Real Conversations We're Not Having

Written by Charlie Lehman
April 9, 2025
5 min read

I've spent a decade working alongside engineers who build incredible software. I've seen, again and again, the problem-solving, the late nights deploying, and of course, the pride in shipping elegant solutions that users actually use.

Now I'm watching some of them grapple with a new reality: AI tools generating in seconds what used to take hours.

A bit of the engineer anxiety I'm hearing isn't just about job security. It's about identity. It's about their craft. About purpose.

The changing landscape of software engineering

The changing landscape of software engineering

What Engineers Are Actually Telling Me

When I really listen, here's what I hear beneath the surface:

From senior engineers: "I spent 15 years building very specific skills and expertise. Does that still matter?"

From mid-level engineers: "I finally got good at this. Now the rules are changing."

From junior engineers: "Should I even bother learning the fundamentals?"

These aren't just anxious questions. They're existential ones.

The View From Both Sides

As a PM, I need to ship features. AI tools help us move faster. That's undeniable.

But as someone who's built their career alongside engineers, I know that speed isn't everything.

I've seen too many "quick wins" become maintenance nightmares. Too many shortcuts become technical debt. Too many clever solutions fail because they solved the wrong problem.

What 10 Years of Working With Engineers Has Taught Me

After a decade watching great engineers work, I've learned what truly separates them from the rest:

They ask questions no one else thought to ask:

  • "But what happens when the user does X?"
  • "How will this perform under Y conditions?"
  • "What if we approached this entirely differently?"

They see implications others miss:

  • "If we build it this way, we'll have trouble scaling later."
  • "This solution creates hidden dependencies."
  • "That approach might work, but it trades performance for reliability."

They protect the team from bad decisions:

  • "I know we want to ship fast, but there's a critical edge case."
  • "That library seems perfect, but I see red flags in how it handles errors."
  • "This approach seems simpler, but it breaks our authentication model."

No AI tool I've seen can do these things. Not even close.

Engineering wisdom comes from experience

Engineering wisdom comes from experience

The PM's Perspective on AI Tools

When I evaluate any tool, I ask: does it solve real problems for real users?

For engineers working with AI tools, the answers are mixed:

Unquestionable wins:

  • Generating boilerplate code
  • Explaining unfamiliar code
  • Suggesting test cases
  • Documenting existing features

Still questionable:

  • Architectural decisions
  • Performance optimizations
  • Security considerations
  • Actual user based problem-solving

How I'm Thinking About Engineering Value Now

The engineers I most value on my teams have never been the fastest, they've been the ones with the best judgment and aren't afraid to fail fast.

They're the ones who:

  • Understand what we're actually trying to achieve
  • See around corners to identify risks
  • Know when to push back on requirements
  • Recognize when simple beats clever

These qualities come from experience. From failures. From successes. From years of seeing what works and what doesn't.

No prompt can generate that.