No Free Pass – The Reality of Product Engineering in Teams

I was recently confronted by a product engineer colleague here at epilot, frustrated with some of his non-engineer colleagues who didn't seem to buy into the idea of involving engineers in the product process from the start. An all too familiar and frustrating situation for many of us. You think of yourself as a proud product engineer wanting to solve meaningful problems but yet get slapped with a detailed feature specification designed by a group of non-developers without your input. Now they expect you to go deliver their vision. This is very much the reality in most product teams. Calling yourself a product engineer doesn’t automatically mean your voice will be welcomed. And that's totally ok. The Ideal vs. the Reality In my past writings I've painted the ideal: engineers who understand customer needs, question roadmaps, challenge designs, and contribute beyond code. But the reality is often much messier. PMs and designers aren’t always used to engineers wanting a seat at the table. Some actively resist it. Either out of habit, pride, low expectations, or because collaboration simply takes more time. And let’s be honest: sometimes engineers haven’t built the trust or skills to contribute meaningfully (yet). The Friction is Normal The moment you step outside "your lane", you shouldn't be surprised when the reaction isn't overwhelmingly supportive. You will face skepticism. You might be seen as overstepping. You will encounter: Requests to give estimates for someone else's ideas Roadmaps shared as top-down mandates Detailed UI design handed over "ready for dev", expecting pixel-perfect implementation Pushback when you ask why, or whether we know enough to start building This is the price of wanting to do more than just execute. And if we’re honest, many of us haven’t always shown up in these conversations in a way that earns trust. At the end of the day it's our job to show product engineering works. Earn the Trust Calling yourself a product engineer isn’t a free pass. No one hands you a seat at the product table just because you want it. You must earn it. Show don't tell. Do the homework. Know the names of your customers. Know the business domain. Talk to your colleagues, not just other devs. Find opportunities to interact with customers. Ask helpful questions that sharpen the team's product thinking. Dive into data, gather insights. Find new metrics and ways to collect useful data. Bring value to the table. Demonstrate you understand the customer problem by making thoughtful proposals that move the product forward. You need to show up in demos, RFCs, testing sessions, and reviews. not just code commits. Why Bother? Because it’s worth it. We do this for our own professional pride. To put great products into the hands of happy customers. And our our portfolios. We don’t challenge product decisions to because we want to take over the PM job, or to undermine the work of our teammates. We do it because we care about impact. Because you want your effort to count. Because it hurts to pour weeks of your life into something that doesn't work, only to discover it failed because no engineer was involved in the concept phase. Because we know our technical effort has more impact when it’s aligned with real problems and thoughtful design. Our leverage And here’s something to remember: we, as engineers, hold real leverage. We are the only ones who can actually turn product decisions into reality. No idea ships without us. So while we may not always get a say by default, we do get a say in how we show up, and how deeply we choose to care. Use that leverage wisely. And proudly.

Apr 8, 2025 - 12:33

No Free Pass – The Reality of Product Engineering in Teams

I was recently confronted by a product engineer colleague here at epilot, frustrated with some of his non-engineer colleagues who didn't seem to buy into the idea of involving engineers in the product process from the start.

An all too familiar and frustrating situation for many of us.

You think of yourself as a proud product engineer wanting to solve meaningful problems but yet get slapped with a detailed feature specification designed by a group of non-developers without your input. Now they expect you to go deliver their vision.

This is very much the reality in most product teams. Calling yourself a product engineer doesn’t automatically mean your voice will be welcomed. And that's totally ok.

The Ideal vs. the Reality

In my past writings I've painted the ideal: engineers who understand customer needs, question roadmaps, challenge designs, and contribute beyond code. But the reality is often much messier.

PMs and designers aren’t always used to engineers wanting a seat at the table.

Some actively resist it. Either out of habit, pride, low expectations, or because collaboration simply takes more time.

And let’s be honest: sometimes engineers haven’t built the trust or skills to contribute meaningfully (yet).

The Friction is Normal

The moment you step outside "your lane", you shouldn't be surprised when the reaction isn't overwhelmingly supportive.

You will face skepticism.

You might be seen as overstepping.

You will encounter:

Requests to give estimates for someone else's ideas
Roadmaps shared as top-down mandates
Detailed UI design handed over "ready for dev", expecting pixel-perfect implementation
Pushback when you ask why, or whether we know enough to start building

This is the price of wanting to do more than just execute. And if we’re honest, many of us haven’t always shown up in these conversations in a way that earns trust.

At the end of the day it's our job to show product engineering works.

Earn the Trust

Calling yourself a product engineer isn’t a free pass. No one hands you a seat at the product table just because you want it. You must earn it. Show don't tell.

Do the homework. Know the names of your customers. Know the business domain.
Talk to your colleagues, not just other devs. Find opportunities to interact with customers.
Ask helpful questions that sharpen the team's product thinking.
Dive into data, gather insights. Find new metrics and ways to collect useful data.
Bring value to the table. Demonstrate you understand the customer problem by making thoughtful proposals that move the product forward.

You need to show up in demos, RFCs, testing sessions, and reviews. not just code commits.

Why Bother?

Because it’s worth it.

We do this for our own professional pride. To put great products into the hands of happy customers. And our our portfolios.

We don’t challenge product decisions to because we want to take over the PM job, or to undermine the work of our teammates. We do it because we care about impact. Because you want your effort to count.

Because it hurts to pour weeks of your life into something that doesn't work, only to discover it failed because no engineer was involved in the concept phase.

Because we know our technical effort has more impact when it’s aligned with real problems and thoughtful design.

Our leverage

And here’s something to remember: we, as engineers, hold real leverage. We are the only ones who can actually turn product decisions into reality. No idea ships without us.

So while we may not always get a say by default, we do get a say in how we show up, and how deeply we choose to care.

Use that leverage wisely. And proudly.