DEV Community: Mihaela Draghici

Engineers have product insight that PMs don't

Mihaela Draghici — Thu, 24 Sep 2026 13:36:06 +0000

We often talk about product insight as if it comes from a fairly predictable set of places:

Customer interviews.
Analytics.
Market research.
Sales conversations.
Support tickets.

And usually, a Product Manager is expected to bring those signals together and decide what matters.

But there is another source of product insight that many teams underuse:
Engineering.
Because engineers see parts of the product that nobody else sees. And even if it's generally considered just technical information, it is actually product information.

Engineers see where the product is fighting itself

Engineers know where the system is fragile. They know which apparently simple workflows require fifteen exceptions behind the scenes. Or which customer request keeps reappearing in slightly different forms.

They know which parts of the architecture make seemingly obvious product changes disproportionately expensive.

And they often see patterns long before those patterns show up clearly in a dashboard that a PM looks at.

Take a workflow that generates a constant stream of edge cases.

From a product perspective, that could look like:

"We need to handle more scenarios."

From an engineering perspective, the pattern might be telling you something very different:

"Maybe the underlying workflow no longer matches how customers actually use the product."

That's no longer just an implementation issue.
That's a product question.

Technical complexity can be a product signal

Complexity is often treated as something Engineering needs to manage. Sometimes it is.

But complexity can also tell you something about the product itself.

Imagine a SaaS product where every large customer requires slightly different permission rules.

Over time, Engineering builds:

exceptions
configuration flags
account-specific logic
fallback behaviour
special migration paths

The conversation might remain:

"Our permissions architecture is getting too complicated."

But there is a deeper question:

Why is the product generating this complexity in the first place?

Maybe the customer segments are more different than the company assumes. Maybe the underlying permissions model is wrong. Maybe enterprise customers are being forced into a model designed for smaller organisations. Maybe Sales is selling flexibility that the product was never designed to support.

The code is showing you something about the business and the customer.

You just have to read the information.

Repeated exceptions are rarely just exceptions

Engineers are particularly well positioned to notice repetition. One special case isn't necessarily meaningful. But ten similar special cases probably are.

If customers repeatedly require workarounds, custom logic or manual intervention, that pattern deserves product attention.

The question shouldn't always be:

How do we support this exception?

Sometimes it should be:

Why does our product keep creating this exception?

Because when engineers are involved only after a solution has been defined, they are usually being asked to solve the first question.

When they are involved earlier, they can help the team ask the latter.

Engineers also see what suddenly becomes possible

Engineering insight isn't only about constraints. It's also about opportunity.

Technology changes, APIs improve, infrastructure becomes cheaper.

AI makes previously expensive capabilities dramatically easier to build.

A workflow that made no sense two years ago might suddenly be viable.

Engineers are often the first people in an organisation to recognise that.

But if Engineering is treated purely as the function that implements the roadmap, that information has nowhere to go.

The product conversation becomes one-directional:

Product → requirements → Engineering

Instead of:

Customer + Business + Product + Design + Engineering → better decision

That's a significant amount of intelligence to leave on the table.

"Product decides what. Engineering decides how." is too simplistic

This sentence still appears in many organisations.

It sounds clean.

But taken literally, it creates a bad product development model.

Because how something works can fundamentally change what should be built.

Technical constraints affect the solution. Architecture affects the economics. Data availability affects what can be measured. Implementation complexity affects whether the opportunity is worthwhile. New technical capabilities can create entirely new product options.

The "what" and the "how" are not independent variables.
They influence each other.

The goal is to make sure the decision uses the information each role has.

PMs don't know everything. They shouldn't be expected to.

None of this diminishes the role of Product. Quite the opposite.

A PM will usually know things an engineer doesn't.

They may have context from:

customer research
commercial strategy
competitive positioning
stakeholder conversations
revenue targets
company priorities

Engineering brings a different view.
Design brings another.
Sales, Support and Data bring others.

The quality of the product decision depends on how well those perspectives are combined.

The mistake is assuming that because Product owns the decision process, Product must also own all the relevant insight.

The engineers closest to the system are often closest to hidden product signals

We spend a lot of time trying to get teams closer to customers.

We should.

But customers are not the only place product insight lives.

Some signals are buried in:

logs,
architecture,
exceptions,
failure modes,
data quality,
support tooling,
integration behaviour,
and the strange workarounds engineers keep having to build.

Those signals are easy to dismiss as technical detail.

Sometimes they're telling you something important about your product.

The difference is whether anyone asks.

Engineering judgment becomes more valuable, not less.

An engineer who can generate code faster is useful.
An engineer who can identify that the team is solving the wrong problem is far more useful.

An engineer who notices that five feature requests are actually symptoms of the same underlying customer problem can change the direction of a roadmap. They need to be part of the conversation.

An engineer who understands that a new technical capability makes a previously impossible customer outcome feasible can create an entirely new opportunity.

That's product leverage.

And it doesn't require engineers to become PMs.

It requires them to participate in the thinking before the decision has already been made.

Bring Engineering in before the ticket exists

If the first time an engineer sees an idea is when it appears in the backlog, much of their product insight arrives too late.

By then:

the problem may already have been framed
the solution may already have been chosen
stakeholders may already be expecting delivery
estimates may already have become commitments

At that point, challenging the underlying assumption feels expensive.

So engineers don't do it.

A better moment to involve engineers is while the problem is still being understood.

Ask things like:

What patterns are you seeing in the system?
Where are we repeatedly introducing exceptions?
What looks simple from the outside but is actually very complex?
What assumptions about user behaviour don't match what you're seeing?
Where is poor data limiting our decisions?
What has recently become technically possible that wasn't before?
If we didn't build this proposed solution, how else might we solve the problem?

These aren't questions about implementation.

They're questions about the product.

Engineering shouldn't just receive product decisions.

It should help inform them.

AI can write code. Your advantage is deciding what should be built.

Mihaela Draghici — Thu, 24 Sep 2026 13:19:02 +0000

For a long time, writing code was one of the biggest constraints in building software.

You could have a great idea, a clear customer problem and a strong business case but turning that into working software still took time.

Now, developers can generate boilerplate in seconds. Agents can implement features, refactor code, write tests, investigate bugs and scaffold entire applications.

The cost of producing software is falling.

But that doesn't necessarily mean we're going to build better products.

Because faster implementation exposes another constraint:

Deciding what is actually worth building.

The question becomes:

Should we build it?

And that requires a very different skill.

Because removing the time/speed constraint doesn't remove the need for judgment.

When implementation becomes cheaper, teams can develop and build more ideas.

Which means they also have the ability to build more bad ideas, faster.

This changes the job of the engineer

There's a version of the AI future where engineers become primarily supervisors of code-generating systems.

I think that's too narrow.

The engineers who become more valuable aren't simply the ones who can produce the most code with AI.

They are the engineers who understand why the code should exist in the first place.

They can look at a request and ask:

What problem are we actually trying to solve?
For whom?
What evidence tells us this problem matters?
What outcome are we expecting?
What assumptions are we making?
What happens if we're wrong?
What are we choosing not to do?

Those aren't coding questions.

They're product judgment questions.

And historically, many organisations have treated them as someone else's responsibility.

"Product decides what. Engineering decides how."

Consider a familiar request

A stakeholder says:

"We need an AI assistant inside the product."

There are at least two ways an engineering team can respond.

Response 1

"What should it do?"

The requirements get written. Then they design the architecture and build the assistant within hours (with AI tools).

Perhaps it even works perfectly.

But six months later, hardly anyone uses it.

Technically successful. But a successful product failure.

Response 2

Before discussing implementation, someone asks:

"What problem would the assistant solve?"

Maybe the answer is: "Customers struggle to configure their accounts."

Good. Now we can keep going.

How do we know?

From Support tickets.

Where exactly do users struggle?

During initial setup.

What are they trying to understand?

Which configuration is appropriate for their organisation.

Now the conversation is very different.

Perhaps the right solution is an AI assistant.

But it might also be:

better defaults
contextual guidance
a setup wizard
improved documentation
automatic configuration based on account type
redesigning the workflow entirely

The engineer asking those questions hasn't stepped outside their role.

They've improved the quality of the decision before implementation even begins.

Product sense isn't about having better ideas

People sometimes describe "product sense" as intuition.

That definition isn't particularly useful.

Strong product judgment is less about magically knowing the right answer and more about being able to reason when the answer isn't obvious.

Especially when:

the data is incomplete
users contradict each other
stakeholders want different things
technical constraints exist
commercial pressure is high
several options look reasonable

That is normal product work, that is typically considered under the remit of a Product Manager.

But Engineers play a crucial part in this conversation, in asking the right questions and giving the right answers before even starting to build anything.

So this product sense isn't just a PM skill. It becomes essential for the entire team to develop, including, and most importantly, the engineers.

Start with three definitions of "good"

One model I use when making product decisions is simple: A good product decision usually has to work across three perspectives.

User:

Is this desirable?
Does it solve a meaningful problem?
Will someone actually use or value it?

Business:

Is it viable?
Does it support the organisation's strategy, economics or competitive position?

Technology:

Is it feasible?
Can we build, operate and maintain it responsibly?

Product decisions get interesting when those perspectives conflict.

A customer might desperately want something that creates massive long-term architectural complexity. A technically elegant solution might solve a problem customers barely care about. A commercially attractive feature might introduce significant reliability or security risk.

There often isn't one objectively correct answer.

There are trade-offs that need to be noticed and understood.

AI makes weak product decisions cheaper to execute

This is the part I think we underestimate.

When implementation is expensive, organisations are forced to choose.

When implementation becomes cheap, the temptation is: "Why don't we just build it?"

But every feature still has a cost. Even if generating the code takes ten minutes.

Someone still has to:

review it
test it
monitor it
maintain it
explain it
support customers using it
integrate it with the rest of the product
handle edge cases
manage the additional complexity
deal with the risks if something goes wrong

And every additional product capability creates another decision users might have to make.

Ask better questions before writing better code

One of the most useful habits engineers can develop is learning to interrogate the decision before jumping to implementation.

When someone asks for a feature, try asking:
What changed?
Why is this important now?

What problem are we solving?
Not "What functionality do we need?"
What is actually happening to the user or the business?

What evidence do we have?
Customer interviews? Usage data? Sales feedback? Support tickets? An executive assumption?

What would success look like?
What behaviour or outcome should change if we build this?

What are we assuming?
What must be true for this idea to work?

What happens if we're wrong?
A reversible experiment should be treated differently from a major architectural commitment.

What is the smallest thing we could learn from?
Sometimes the right first step reducing uncertainty before building a full solution.

AI should increase engineering leverage, not reduce engineering judgment

There is a danger in the opposite direction too. As AI tools improve, we can delegate more of the thinking process itself.

"Analyse these customer interviews."
"Suggest the most important problems."
"Prioritise these features."
"Recommend what we should build."

AI can be extremely useful for all of those tasks.

But there's a distinction between using AI to improve your reasoning and using AI to replace your reasoning.

If a model gives you a convincing recommendation, you should still be able to answer:

Why is this the right decision?
What evidence supports it?
What evidence contradicts it?
What assumptions is the recommendation making?
What trade-off are we accepting?
What new information would cause us to change direction?

If you can't answer those questions without pointing back to the AI output, you haven't made the decision.

You've delegated it.

The most valuable engineer may not write the most code

For years, developer productivity was often implicitly associated with output. Measured in the form of:

Tickets completed.
Pull requests merged.
Code shipped.
Not tokens burned.

But if one engineer uses an agent to generate 5,000 lines of code while another engineer asks one question that prevents the company from spending three months building the wrong thing, who created more value?

The second engineer might produce almost nothing you can count.
But their leverage is enormous.

That is why I think one of the most important skills engineers can develop in the AI era is product sense.

Because building great products has always required more than implementing requirements correctly.

It requires understanding what is worth building.

And as AI makes implementation faster, that distinction becomes more important, not less.

The advantage is for the engineers with product sense

Knowing how to prompt the latest coding agent will matter, but it probably won't remain a meaningful differentiator forever.

Judgment is harder to commoditise.

Understanding customers.
Recognising weak evidence.
Seeing second-order consequences.
Connecting technical decisions to business outcomes.
Knowing when to challenge a request.
Knowing when not to build something.

Those are the skills I would invest in.

Because in a world where almost anyone can build more software, the scarce capability will be knowing what deserves to be built.

I'm running a free live session on 1 October: AI can write code. Can you make the right decisions?, where I'll showcase exactly this kind of decision-making using real product scenarios.

We'll work through how to challenge feature requests, calculate the value of investments, and connect engineering decisions to user and business outcomes.

*If this is a capability you're trying to develop, you can find the live session here.
*