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.
Top comments (0)