This article was originally published by Alpha UX

One of the most difficult aspect of building successful products is communication and decision making across and within teams. These communication challenges are most pronounced between product managers and engineers.

Nathan Creswell illustrates what he and many others believes to be the crux of the problem:

“Engineering automatically see you [the product manager] as the enemy. Why? Because you make them do work. And sometimes it’s not always on the stuff they would prefer to be working on.”

Given the politics, bureaucracy, and cross-departmental communication challenges of a large company, how do you make it so that product decisions aren’t interpreted by engineers as meaningless busywork? Win the battle of building rapport with engineers and you can put your product development into 6th gear. Lose the battle, and you have skepticism, indifference, or worse, no code at all.

While there’s no panacea when it comes to building rapport with engineers, here’s a three-step process for product managers to build cohesiveness.

1. Involve engineers early so ownership is shared

Brian de Haff describes the importance of involving engineers early on in the process:

“Building great product is a collaborative process that works well if everyone agrees on the product vision and strategy. Why wait to involve engineering in your roadmap planning until you have set the product direction? Transparency builds trust and trust leads to great effort. Involve engineering early and often, so everyone has a chance to contribute to the product vision and buy into where the product is headed.”

If you wait to involve engineers until you need something from them (e.g. code) they may not feel as engaged as if it’s something with which they have background knowledge or ownership.

Engineers often feel disconnected from the customer’s use case, believing instead that the product they are building is desired by one and only one person: the product manager with some grand but delusional vision. By nature, engineers are analytical and skeptical, and will doubt the validity of a product without being able to vet the decision making process. Knowing the “why” behind a product not only builds trust but increases motivation.

2. Set expectations through experimentation

A happy engineer is a happy product manager. Coordinating among departments, particularly engineering, requires savvy diplomacy. Adopting a culture of experimentation accomplishes two objectives.

First, it empowers you with qualitative and quantitative data to defend product decisions and resource allocation. Experimental data make for a much better conversation starting point than do opinions when it comes to making decisions.

Second, and perhaps more importantly, experimentation sets expectations throughout the company. If you make it clear that every product decision and prototype is an experiment, you won’t lose as much trust with your engineers when every product or feature isn’t a big hit. Instead, your goal becomes learning rather than winning, and to that end, every experiment is a success.

3. Align perspective with the user

In a typical organization, ideas are argued until someone’s opinion trumps the others. The CFO might be concerned with ROI. The strategist might be concerned with the market size. Marketing might have some cool idea about messaging. Often, the winner is the HiPPO (“highest paid person’s opinion”).

But if you make the user the most important person in the decision making process, agreement becomes much more attainable. After you’ve involved engineers early on in the experimentation process, the users’ opinions become the only ones that truly matter.

There are a number of experiments that can clarify and validate the demand for a product before writing any code. The result is a vision around which it’s much easier to build consensus.

As a product owner, you can take all perspectives into account as you make decisions by putting them in front of the user. Instead of casting aside someone’s opinion, you can turn that into an experiment. This develops trust and builds a much better environment for collaboration.

Conclusion

The thrill engineers and product managers alike get when people actually use their product is like the thrill a deep sea fisherman gets when he snags a 500-lb marlin. Engineers are rightfully not interested in wasting their time building something that isn’t going to be used. User data helps ensure that the product or feature is something that users will respond to positively.

Giving engineers ownership early on in the product lifecycle, adopting a culture of experimentation, and incorporating user feedback to make decisions are three great ways product managers can build rapport with engineers.