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

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

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 make sense to me. I don’t want to get a bunch of spam from employers, I don’t care about.

Product Manager: Ah, got it. That’s why we have preferences. The job seeker can indicate they only want to hear from employers who match certain criteria.

Engineer: I guess that helps. But even so, I don’t want to hear from any tech company. I only want to hear from the good ones.

Product Manager: We support that. You can say, you only want to hear from these specific companies.

Engineer: Great, so can we allow employers to only contact job seekers who have explicitly said that company can contact them?

Product Manager: Hmm, no that doesn’t really work. What if I am interested in hearing from startups. I don’t want to have to, nor would it be possible to, enter every startup I might be interested in hearing from. Why can’t we allow the job seeker to just say, I want to hear from startups?

Engineer: I don’t know how to do that. We allow a company to contact a candidate before the company has filled out their company profile. I might not know that the company is a startup or a hospital. But I always know which company it is.

(Note: This conversation was completely made-up and does not reference any real people, features, products or real-world situations.)

A-ha. Do you see what’s going on here? The engineer ran into an implementation problem, but it’s being manifested as a concern with the feature.

This is really common.

When you hit a roadblock, it’s natural to stop and question what you are building. But the problem is your perspective is now influenced by what you know is easily possible.

If you know you can look up a company name, but not the attributes of the company, you are going to convince yourself that setting preferences based on company name and not attributes is the best solution.

This sounds nefarious. But it’s not. It’s human nature.

For the most part, engineers aren’t lazy. They aren’t trying to take shortcuts or do the least work possible. But their knowledge of what’s possible and what’s unknown will always color their perspective.

In fact, engineers aren’t the only ones susceptible to this. Chris Argyris, introduced the ladder of inference, a model for describing this exact problem.

The ladder of inference explains the often sub-conscious process we each go through when forming conclusions. We might all be looking at the same set of observable data or share the same experiences. However, we each select different data from that set based on our own knowledge and perspective.

From that selected data, we then add meaning, make assumptions, and draw conclusions. These conclusions influence our subsequent beliefs and actions.

With this in mind, let’s revisit the above exchange.

Often times the engineer has access to data the product manager doesn’t., such as how easy or hard something is to implement or the details of the underlying data model. The product manager also has access to data the engineer may not have, such as the customer need or the impact on the business.

It’s up to each to share this unique data with the other. But even in cases, where both the engineer and the product manager have access to the same data, each is going to select different data on the next step of the ladder, simply because we each bring a different perspective, which means we are likely to draw different conclusions, hold different beliefs, and thus suggest different actions.

So what can we do?

Use the Ladder of Inference as a communication tool. 

When you disagree on a course of action, don’t debate the course of action until both parties are frustrated. Move down the rungs of the ladder. Keep moving down the ladder until you find agreement. This might mean you have to move all the way down to the first rung. That’s okay.

In the context of building products, it’s easy to debate which features are good and bad. But it can be hard to resolve these issues when the debate isn’t really about the feature itself and instead is actually about the impact on the underlying data model or on the complexity of the required business logic in the application layer.

In fact, more often than not, i can find common ground, by asking an engineer, does this complicate the business logic or does the current data model not support this? If the answer to either is yes, I try to move the conversation from, is this feature good or bad, to how could the application or the data model support this.

Often times, just asking the question helps the engineer realize this is their real concern. It also helps shed light on missing data and allows both parties to work together to find common ground.

Of course, they also may just not like the feature. That’s for a different post.

At my last company, we posted printouts on the wall that reminded us of the three layers where we often encountered issues: the data model, the business layer, and the user experience. Both the engineering team and the product team, would often refer to both as reminders to help clarify, where the point of disagreement was. It wasn’t uncommon to hear someone say, “Wait, where’s your concern?” while pointing to one of our printouts.

What techniques do you have for finding common ground? Please share in the comments.