One of the most challenging, and conversely, rewarding areas of software development is managing the relationship between you and your business partners.

As a developer, you speak the language of systems. You walk in the specific and precise languages of database, of code, of specifications. Your primary currencies are exact specifications and knowledge. Your job is to translate requirements into specifications, and instruct your system how to precisely and simultaneously execute both the requests of the user and the business.

Your business partner speaks the languages of marketing, operations, and their currency is relationships. Their primary concern is branding, and building the relationships, networks, and strategy of your company.

The two positions could not be more different in terms of language or means. But they are united in a common goal: That of building a product. It is their job to define the problem of your market, both of your job”s to define to solution to said problem, and your job to build the solution. Nevertheless, that does not make the hand-off of specifications, or the delivery of information from one party to another much easier to navigate.

There is a language barrier between software developers and businesspersons.

Though I”ve discovered that the only true ways to navigate this language barrier is through process and experience, I have come up with a few best practices for both parties.

Best Practices, Navigating the communication barrier:

Learn to walk in both worlds. Developers, spend some time understanding your market at a more-than-trivial level. If your niche is gambling, you should understand the primary motivation of the gambler is to have fun and win money. If your niche is dating, you should understand the primary motivation of your user is to create relationships (probably sexual ones). Understand what sets your product apart from all of the other gambling, dating, or otherwise competing apps, out there on the web. I”d also encourage you to explain often, at a high level, how your system works.

Build common ground. Cite specific examples of miscommunications in the past (without laying blame), and lessons learned from them.

Provide context into what you are trying to accomplish or communicate. When I”m trying to push forward a specific initiative, it is helpful to provide context into where the initiative came from, why it”s important, and where it fits into a timeline. Then, translate that into what it means for the business, the amount of time it will take, how high a priority I think it should be.

Let the data drive decisions. I”ve had quite a few times in which I”ve disagreed with a partner about how a featured should be implemented. In this case, I try to let the data (which has been gathered from our analytics software or usability tests), not ego, drive the decision-making process.

Clearly narrate the trade-offs involved in any decision. A lot of times, building feature x means feature y needs to be cut. I”ve found it infinitely easier to present these decisions in biz-speak than in dev-speak.

Establish a specific common goal. Many times this is implicitly obvious. Often times, it is not. I always restate my goal at the end of a conversation or meeting.

Clear up ambiguity by asking specific questions. A lot of times, the mandate I”ll hear from the business is ”build feature x”, so that it does x and y, and looks like z. There is often much assumed about x, y, and z. Is x an AJAX feature? What is the UX like when you press the button in y?

In sum, these are the best practices I”ve found for navigating the language barrier between developer & businessperson. What has worked best for you?

Note: Any information of proprietary value to my employer has been removed or approved, and this post has been approved by my employer.