We’ve know a number of clients or friends whose businesses are going through the initial phases of a data partnership lately. These relationships are often mission-critical, because without the added benefits of the data partnership, sometimes entire business strategies fall apart. At the same time, if you don’t take a thoughtful approach to establishing the parameters for those relationships, you may be dooming yourself to failure from the start.
To make the process less confusing, if not always easier, we’ve set out some important strategies for how to approach creating a partnership on paper, and for evaluating the relationships you already have. It may not always be the most enjoyable part of your day, but understanding the intricacies of your business partnerships is the only way to ensure that you’re protecting privacy rights, data integrity, and your own economic interests.
Thinking About the Relationships You Already Have
Once you are comfortable that you have the authority to pursue a partnership and you’ve begun the data inventory process, you’re in a great position to start analyzing the relationships you already have. Most companies don’t realize that they have a great deal of information flowing in from existing partners, even if those partnerships are not expressly data sharing partnerships. Consider, for instance, your distributors, affiliates, and similar partners — these relationships generate intrinsic and extrinsic data, of course, but they also depend on business relationships and contracts to facilitate those data flows. Understanding the contracts governing those relationships is essential to a complete data inventory.
It would be simple to just take whatever information you get from your third-party relationships and use them; after all, if the data is coming in, it must be yours to use, right? Not necessarily. All good contracts are specific about what rights and privileges the parties have, even if they aren’t written in plain language. If you’re dealing with a licensing agreement where you are only “renting” the goods or information you receive from a third party, then your rights are restricted. But even in non-licensing agreements (such as a standard supply contract), there can be language that curtails your rights. For example, most commercial contracts contain what are called “merger” or “integration” clauses, which say something like: “this contract is the entire agreement between the parties, superseding all previous agreements, and no modifications to this contract shall be of any effect unless in writing signed by both parties.” The purpose of these clauses is effectively to prevent one party from later saying in court “Yes well the contract says we get X, but we both agreed over a handshake that my company gets X, Y, and Z.” (Free legal advice: people are liars.) A merger clause also serves, sometimes, to limit what the parties are entitled to under an agreement. If valuable data from your business relationship can be considered an asset or an interest otherwise covered by the terms of the contract, then you can’t use it without the consent of your contractual partner.
There are endless permutations of this exercise. What about the data about the data produced by your business relationship? Is that yours to use, or does it contain proprietary information related to your partner in the contract? Is there confidential business information involved, such as in a licensing agreement? Sharing that data with a third party might not only be a breach of contract, it could also be a component of a copyright or patent infringement lawsuit. This principle extends to every piece of information that comes from your third-party relationships. If you don’t truly know who owns the data or who can use the information, you’re inviting risk. When it comes to data generated from relationships with other companies, be aware of the red flags that may come from licensing agreements.
Know Your Rights
Once you’ve identified the agreements and their important provisions, your next task is to identify your rights and obligations under each contract. This, of course, is something you will need to do with your lawyer, as every contract is different and there isn’t any catch-all method to explain contracts. The key is the repetitive task of reading and re-reading the contract until you and your lawyer are satisfied that you understand it well enough to make an informed choice. Don’t be surprised if, each time you read the contract, you discover a subtlety (or, often, a typo) that escapes you on the previous passes.
And that’s where the potential for litigation arises. The language of virtually all contracts is open to interpretation or challenge. I’ll give you an example. The words “I promise to sell Jane Doe fifteen widgets for six hundred dollars” are an agreement, seemingly without any ambiguity. But did you say them out loud or write them in a document? If you don’t have a signed document in writing, the law says that contract is likely unenforceable, because agreements for the sale of goods for more than $500 must be written. Also, were those US dollars? Do the widgets ever change or have different versions? And what about timing — the agreement doesn’t specify, but what if Jane needs them immediately? Now you’re headed back to court to figure out if the timeframe for selling the widgets was a “material term” of the contract.
The point is that conducting a data inventory or using data that comes from your existing business relationships may not be as simple as pulling together a spreadsheet. Until you have a firm grasp on what the agreements say and how they limit or define your right to use data, you must be extremely careful in how you proceed. This is particularly true if you did a decent job drafting the contract in the first place where it is advantageous for your company. The use of data derived from the other party, outside of the accepted contract, may be an excellent excuse for them to find a way out of the contract.
That being said, let’s examine a systematic approach to reviewing your contracts (with the help of your lawyer, of course) to determine next steps for making use of intrinsic data.
Determine Who Is Involved
It’s crucial to understand who your partner in the contract is. Sometimes, when you have a relationship with a third-party provider, that provider is a subsidiary of another entity, or may even be a single purpose entity (a “SPE”) that has no real substantive existence other than on paper. By focusing first on who is a party to the contract, you’ll have a better idea of who the key decision makers are (or at least be able to find out).
Identify Your Value Propositions
Every contract has terms that represent the most important aspects of the agreement for your company. Sometimes those terms include the price, sometimes the duration, but ultimately, there are always portions that are essential. Find these provisions and silo them off in your mind — there’s no negotiation around them, and no strategy that should put them at risk. If you know what’s most valuable, you know what you need to secure.
Set Your Goals for the Contract (and the Partnership) Clearly and Succinctly
This is the one place where we have seen the most problems arise: a failure to understand exactly what it is you’re looking for and an accompanying failure to actually write that goal down. It may seem redundant, but the reality is that if you have a written statement of exactly what you want to gain out of your existing relationships, you are far less likely to wander off from your goal or make unnecessary concessions.
Trade Secrets, Derivative Uses, and Secret Sauce
What is a “proprietary field” in any given dataset? This is an important question. It’s axiomatic that data has value both intrinsically and as a matter of its relationships with other data (that’s basically the premise of our book). But data also has value in the sense that it reflects the process it took to create it. The value you ascribe to data, in many ways, depends upon how much effort it took to create, and that effort can also include your own trade secrets, like customer lists or algorithms. You can think of a trade secret as your company’s “secret sauce,” the internal business method, idea, or product that gives you your competitive edge. Your client lists, algorithms, customer preferences, or even sales pitch scripts are also trade secrets, and all are protected by law, just as much as KFC’s secret spices.
Why are these important to protect? Because they reflect the work that a company has put into developing its business methods and products. If there were no way to protect these kinds of investments, the incentives to poaching employees or secrets would be very high, creating economic havoc. So the law recognizes the importance of trade secrets, and, importantly, encourages their development.
There are two kinds of trade secrets at stake in these situations. First, the dataset that you have may be a trade secret — either your own or someone else’s. To be a trade secret, a dataset merely needs to be created through your efforts, valuable, and kept secret. That broad definition covers an enormous number of potential datasets, and means that you almost certainly have trade secret datasets. The second trade secret you may have is how you analyze, slice, break down, or otherwise make use of those datasets. Consider, for instance, Zillow’s Zestimate, which starts with publicly available data (like historical sales records for a given property and comparable sales in the neighborhood), but uses a proprietary formula to calculate a sales price estimate for any given residential property. The underlying data isn’t a trade secret, but the Zestimate formula absolutely is, because it meets those three elements described above: created by Zillow, valuable, and kept secret.
So what does this have to do with data legal basics? Quite a bit, actually. If you’re trying to form a data partnership and your dataset is based on your own trade secret data or trade secret formula, sharing it means it isn’t a secret anymore. By revealing a trade secret (in the absence of an MNDA or other legal protection), you may effectively waive the right to protection because you have broken the third component of our definition: you didn’t keep it secret, and now you can’t protect that right in the same way or, in some circumstances, at all.
To avoid that unpleasant outcome, be sure to think carefully about how you have framed your MNDA, or how you intend to make your presentation more generally. You can also make clear that, in the formation of your data partnership, you should consider if and how you want to maintain control over the derivative uses of your data or your formulas. Conversely, if you are obtaining data from another party, you’ll want to guarantee your right to derivative use of data.
Derivative use is, effectively, the outcome of analysis on a dataset. Most of the time, when you perform an analysis on a dataset you are creating a derivative data element, one that may (or may not) be your property. Of course, depending upon how you create this new derivative data element, it may itself qualify as a trade secret. If you don’t carefully consider what rights you have to derivative uses of data, you may inadvertently preclude yourself from using derivative data elements or allow someone else to claim them as their own.
Ultimately, the most important point about trade secrets here is that you understand that they exist. Think carefully about what your trade secrets are, and how you plan to protect yours. If you don’t, they may not be secret, or yours, for long.
Read Everything Yourself
Once you understand some of the legal basics, it is critical that you take an active role in your contracts and legal decisions. In our experience, the business owners or product managers that stay close to the contract process when building data partnerships ultimately are more successful than the ones that assume their lawyers can handle it on their own. This is because, as well qualified and intended as their counsel may be, most lawyers are not familiar enough with the sources, processes, calculation, and presentation of data assets to understand the nuances necessary to gain success in a contractual negotiation. Keep close to the process and with the help and guidance of your counsel, you will be in a better position to begin leveraging your existing and future relationships to access all of the intrinsic and potentially extrinsic data that you have. Just remember these three pieces of advice that are central to the DataSmart Method:
- Don’t think that you can use data just because it is related to your business
- Read all the contracts, and then read them again
- Use the contracts that you have to your advantage, including by protecting your data assets
Although there is no guarantee in any business relationship, creating a structure that protects your interests and gives your partner a clear idea of their own rights is a strong start. By cutting out ambiguities and setting clear expectations in your contract, you’ll be working to minimize opportunities for either party to take advantage of the other, which reinforces trust. Ultimately, a well-planned contract can’t create a good relationship, but it can certainly help sustain one.
