Tanuj Parikh

Buffering

Deals to use another company’s API usually require the most legal oversight and diligence, because you’re typically exposing your company and your users to another company’s terms of service, privacy policies, etc. — not to mention whatever potential liabilities are created by the new product you’re building.

One of the trickiest things to navigate in these deals is the balance between legal protection (contract clauses that may compromise the product) and product execution (building the best possible user experience). Being good at BD means placing yourself squarely in the middle of that tension, acting as a buffer between the product vision and the legal red tape.

After several months of negotiating an API deal for GroupMe, here’s what I’ve learned about the best way to buffer, in no particular order:

• Be product oriented. Know what the vision for the final product your team wants to build is, inside and out. Stay involved throughout the design process, from initial wireframes to beta builds to the public release. Understanding how everything is supposed to work lets you evaluate how restrictions or requirements the API company’s lawyers (or your own) try to put on you could impact the final product. Better to catch any potential hiccups early in the development process. An added benefit is that with each contract revision or additional round of negotiating, you don’t need to run to (read: bother) your product team to see how the latest deal terms affect their work.

• Don’t work in isolation. It’s inevitable that you’ll need to consult with your product team for certain things, so keep them in the loop, particularly for negotiations that are taking a while. If there are unavoidable legal clauses that affect the product, let them know as soon as possible. If the deal is getting delayed, tell them, so they can adjust development cycles and plan accordingly. 

• Pretend you have a J.D. Before sending a new draft of a contract or other legal agreement, particularly one that’s been redlined and has comments from the other company’s attorneys, to your lawyers, read it yourself. Try to understand all the legalese. You may not get it all right, but by presenting it to your lawyers with your own opinions/reactions, you not only gain their respect but you can frame the subsequent discussion. For instance, a change may be requested that your lawyers have no problem with from a pure legal perspective, but that negatively impacts your product. By getting smart about contracts and legal fine print, you can move negotiations to a close much quicker.

• Push back. Don’t be afraid to push back against your own lawyers. Know what matters for the end product, and fight for it. 

• Good cop / bad cop. When asking for concessions from opposing counsel, find the right balance between making the ask yourself versus having your lawyers do it. It can help to frame it as a good cop / bad cop situation, with the lawyers being the hard asses and you using softer negotiating tactics in a backchannel. 
  

• Have a backup plan. Despite your best efforts, things may fall apart. Be sure that you, and your product team, have a backup plan. Other API’s may not be as elegant or do everything you want, but don’t put all your eggs in one basket. Do contingency work in parallel to negotiating the primary deal; don’t wait for it to fall apart. For BD that means making contact, queuing up legal effort, and evaluating terms. For product it means testing the API, talking to other developers, and resource planning. All that work may end up being redundant and ultimately unnecessary, but in the event you do need a fall back option, you’ll be glad you did.