How To Find Common Ground When Engineers Don't Like Features

Torres uses a made-up exchange between a product manager and an engineer to show how a feature disagreement is often really an implementation concern. Both people select different data and draw different conclusions, a pattern she connects to Chris Argyris's ladder of inference. She recommends moving down the rungs of that ladder to find where the disagreement actually sits, rather than debating the feature itself. She also describes a practical habit: asking whether a feature complicates business logic or the data model, and reframing toward how the system could support it. Reasoning this way helps teams surface missing data and reach common ground faster.

01Key takeaways

• Feature debates often hide implementation concerns; check whether the objection is really about feasibility.
• Recognize that engineers and PMs select different data and so reach different conclusions.
• Move down the ladder of inference to shared facts when a debate stalls.
• Ask whether a feature complicates business logic or the data model before judging it good or bad.
• Reframe from 'is this feature good?' to 'how could our system support this?'

02Key sections

A Typical Feature Disagreement

A sample dialogue shows an engineer rejecting a feature, when the real obstacle is that the system cannot yet store the needed company attributes. The disagreement is framed as a product question but is an implementation roadblock.

Why Knowledge Shapes Perspective

People naturally let what they know is feasible color their view of what should be built. This is human nature rather than laziness or a shortcut-seeking habit.

The Ladder of Inference

Teams look at the same data but select different pieces, then add meaning and assumptions that lead to different conclusions and actions. Each side holds unique information the other may lack.

Using the Ladder as a Communication Tool

When stuck, move down the rungs toward shared facts instead of arguing about the course of action. Sometimes this means returning all the way to the first rung.

Asking the Right Questions

Ask whether the feature complicates business logic or the data model, then shift the discussion to how the application or data model could support it. Printed reminders of the data model, business layer, and user experience helped one team locate where its disagreements lived.

03From the post

“Have you ever found yourself in an argument with an engineer about the value of a feature? Take a look at the following exchange: Engineer: I don't think we should let companies message candidates who haven't applied for their jobs. Product Manager: How come? Engineer: It doesn't”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.