The Product Engineer and the Shift from Stakeholders to Partners

Greetings from San Francisco, California 🇺🇸

I’ve been thinking about this topic for a while. But after attending the first LeadDev Athens Meetup—where the theme came up in different forms—I knew it was the right time to finally write it down 🧑🏻‍💻

Great Products Start with Mature Teams

To deliver what really matters, you need to build a mature team—both internally and externally.

Why? Because some of the best product ideas don’t come from top-down strategy docs. They come from the people building the product every day: the developers, the designers, the engineers closest to the actual implementation.

There are engineers who simply implement features. But there are also engineers who understand the business better than anyone else. They know the pain points. They’ve seen the trade-offs. They recognize what doesn’t scale.

As a leader, your job is to find the ambassadors inside the team—the ones who care deeply about the product—and bring them into discussions early. Run brainstorming sessions with them. Invite them into product planning. Their insights are gold.

This brings me to a role that’s gaining traction in many mature tech teams: the Product Engineer.

The Rise of the Product Engineer

If you’re not familiar with the term yet, pay attention. I believe we’ll be talking about it a lot more in the years to come.

A Product Engineer is not just a developer who ships features. They are engineers who:

• Deeply understand the product and its purpose

• Feel ownership over outcomes, not just deliverables

• Actively engage with product, design, and business stakeholders

• Think in terms of value, not just implementation

I’ve had the privilege of working with teams like this.

Sometimes, requests would come in from the product side—and after healthy discussion, engineers would push back. Not because they were stubborn, but because they understood the users, the context, and the product. They knew the request didn’t make sense. And in many cases, they were right.

Some of our best features didn’t come from product roadmaps. They came directly from engineers. These were grounded in reality, informed by user behavior, and often created outsized impact.

For more context on the Product Engineer role, check out Nate Lee’s “WTF is Product Engineering?” and Adam’s field guide in ”The Product Engineer“. They both offer helpful comparisons between traditional engineering and this emerging, hybrid role.

Why Engineers Should Join Customer Calls

Here’s something I’ve learned that made a big difference: Put engineers in front of customers.

Picture this: a product manager is leading a customer call. A feature request comes in, and the PM says,

“Thanks, I’ll take it back to the team.”

It’s a reasonable response, but it can also give the impression that the PM doesn’t fully grasp the product’s complexity or trade-offs.

Now imagine a different scenario—an engineer or engineering manager is also on the call. When a request comes in, they respond immediately:

“That’s an interesting idea. It’s technically possible, but here’s the complexity it introduces—and here’s an alternative that might get you 90% of the value with 10% of the effort.”

This builds instant trust. Customers can tell when they’re speaking to people who understand the product inside and out. And internally, it reinforces a powerful message: engineers own the product too.

Let me give you two real-world examples.

Two Real Examples from the Trenches

1. Rethinking the Billing Model

In a product I was leading, an engineer challenged our existing billing model. At first, it seemed like a technical opinion—but it turned out to have broad business implications.

We organized a brainstorming session to dig into it, and the proposal gained support across engineering, business development, product, and even legal.

Although the full rollout took over two years to complete, it all started with a single engineer raising their voice. That idea reshaped how the company approached pricing.

2. Winning Over a Skeptical Customer

A new customer joined us from a competitor, where everything was done manually—no automation, no workflows, just brute-force operations.

They initially struggled to understand our product because so much of the logic ran behind the scenes. But after just a couple of calls with our engineers—who explained how it all worked under the hood—the customer was fully onboard.

I still don’t understand how we occasionally lost customers to competitors with far less capable technology. But I suspect it often comes down to communication and trust‼️

From Stakeholders to Partners

There’s another mindset shift that’s essential: stop managing stakeholders—start building partnerships.

Too many people approach leadership as something to please. They focus on keeping their manager or external teams happy, hoping it protects their visibility. But that mindset leads to bad decisions. I’ve seen entire product directions veer off course because no one was willing to speak up.

Real partnership is built on trust. You earn the right to say “no” because you’ve shown you care deeply about the outcome.

But before we get into the story, let’s talk about one more thing: value.

Talking About Value

Talking about value might seem obvious in technical roles, but it’s surprisingly hard—especially when communicating with non-engineering teams.

And yet, it’s crucial. Even when your estimates are rough. Even when they don’t pan out.

Because making estimations isn’t a gut decision—it’s grounded in a deep understanding of the business, the product, and the user. That’s why it’s hard. And that’s also why it matters.

If you don’t understand what the business is trying to achieve, you can’t accurately assess whether something is worth building. This is exactly where product-minded engineers thrive—they help translate complexity into value.

A Story About Saying “No”

Let me wrap up with a final example.

I joined a meeting already in progress. A couple of colleagues had pitched a new feature idea to our Chief Product Officer (CPO). The VP of Product and Product Manager were also in the room. After they explained the concept, I was asked to share my thoughts.

I said:

“I don’t support this feature. It’s complex, it’s effort-intensive, and I don’t see the value. It feels flashy for the sake of being flashy.”

To my surprise, the CPO agreed. We parked the idea—despite the effort already spent analyzing it.

Why did my voice matter in that moment?

Because we’d built trust. We’d been on customer calls together. We’d shipped under pressure. We’d prioritized well when it counted. And we both cared about the same thing: building the right product.

This is what happens when you move beyond stakeholder management and into true partnership. You’re not just aligned on a roadmap—you’re aligned on purpose.

Final Thoughts

The concept of the Product Engineer ties all of this together:

• Engineers who own what they build

• Engineers who collaborate across functions

• Engineers who understand the customer

• Engineers who know when to say yes—and when to say no

If you’re leading a team, building a product, or even thinking about your next career step—this is the direction to move in.

Let’s stop building walls between roles. Let’s build trust, ownership, and real value instead.

That’s how great products—and great teams—are built‼️