Feedback on feedback clauses

A feedback clause generally gives a party a right and license to use ideas, comments, suggestions or similar feedback provided by the other party. Companies that offer products and services like these clauses because they allow the company way to learn information that can help them continue to improve their offerings.  The standard argument in support of this type of clause is that it’s important to a product or service provider to ensure that simply discussing products in development with a client does not jeopardize their ability to use information they learn during that discussion.  While that’s not unreasonable, there are a few different flavors of feedback clauses – the taste depends on which side of the fence you’re on.

As noted above, a typical feedback clause gives a party defines “Feedback” (e.g., any ideas, comments, suggestions or similar feedback provided by one party to the other); indicates that the provision of feedback is completely voluntary; and provides some grant of rights to the receiving party to use feedback.  Think of this as the “base.”  There are things you can “mix into” the base to change or enhance it, including a feedback trumps confidentialityprovision, a feedback ownership provision, and/or a feedback warranty provision. If you’re on the receiving end of feedback, these mix-ins may be worth considering adding into a base clause.  If you are on the disclosing end, these may be real causes for concern.  (If you’d like a copy of my standard mix-in clauses, send me an email.)

Feedback trumps confidentiality.  This mix-in states that any feedback provided, even if designated as confidential by the disclosing party, does not create any confidentiality obligation for the receiving party absent a separate written agreement, and the receiving party is free to use it the feedback without obligation or limitation.  To the recipient, this ensures that any feedback can be freely used if provided by a recipient, regardless of confidentiality obligations under the Agreement.  To the discloser, this can result in a “back door” around confidentiality.

Feedback ownership.  This mix-in states that the disclosing party agrees to transfer all right, title and interest in and to feedback to the receiving Party.  To the recipient, this ensures that they do not have to worry about creating derivative works of materials owned by a third party by using feedback.  To the discloser, this can result in an inadvertent surrender of its own rights to any of its underlying proprietary information disclosed as feedback to a third party.

Feedback warranty.  This mix-in is a warranty that the feedback does not infringe third party IP rights, is not subject to open source licensing obligations, and does not require payment of third party licensing fees.  To the recipient, this can give some important protections if the recipient uses the feedback.  To the discloser, this creates contractual representations for providing feedback, for which contractual damages may rise if the discloser breaches the warranty.

Here is my own base feedback clause where I represent MyCo (I flip this around and add in mix-ins on a case-by-case basis if warranted).  It requires designation of feedback as such, and protects confidential information if inadvertently provided with feedback:

“The Parties acknowledge that MyCo may from time to time provide YourCo with ideas, comments, suggestions, or other feedback on the features or functionality of YourCo’s product offerings which is designated by the disclosing party as “Feedback” in writing on any written feedback, or contemporaneously with disclosure if disclosed orally (collectively, “Feedback”).  The Parties agree and acknowledge that any Feedback is provided voluntarily by MyCo.  In the event MyCo provides YourCo with Feedback, MyCo hereby grants to YourCo a perpetual, royalty-free, worldwide right to use such Feedback for the limited purpose of improving and creating derivative works of YourCo’s Products (notwithstanding the foregoing, the foregoing right shall not apply or extend to any portion of Feedback provided by MyCo which is MyCo’s Confidential Information, MyCo Technology or MyCo Materials), and the obligations of confidentiality set forth in this Agreement shall supersede and have priority over any Feedback usage rights.”

Finally, one of the most important things you can do regarding feedback is educate your business teams on what to watch out for when sharing feedback with a contractual partner – as in many areas, sound business practices can go a long way towards ensuring reliance on the legal language never becomes a necessity.

How effective is your contract’s Effective Date?

It’s usually one of the first things in an agreement – the Effective Date.   The Effective Date is sometimes defined as a specific date, e.g., “This Agreement, effective as of October 21, 2013 (the ‘Effective Date’)…”  In other cases, a contract becomes effective once signed by both parties.  In that situation, most attorneys contractually define the Effective Date of an agreement as “the date last written below”, put a “Dated” line in the signature block, and don’t think twice about it.  It’s worth a second look.  The Effective Date can be critical to a company for a number of reasons, incuding revenue recognition and performance of contractual obligations tied to it.

In an era where exchanging signature copies or signature pages via PDF (or more rarely these days, fax) followed by an exchange of signed originals is more common, using “the date last written below” to define the Effective Date can have unintended consequences.  In many cases, once the parties have exchanged signed copies by PDF, performance begins and they leave it to the contract administrators to follow up with originals if requested by one or both parties.  But when the originals are signed by the parties, they can create a new Effective Date for the agreement.  This is because of the integration clause in the agreement boilerplate – an argument can be made that the newly signed original version of the agreement supersedes the previously signed PDF version of the agreement, creating a new Effective Date.

For example, suppose you have an agreement where the initial term runs for 1 year from the Effective Date, subject to automatic renewal for subsequent 1-year terms unless a party provides notice of non-renewal at least 30 calendar days prior to the end of the term.  Suppose the date of last execution by PDF was January 1, 2014, and the date of last execution of the originals was January 9, 2014.  Party A is hoping for a renewal as the minimums under the Agreement double in year 2, but Party B sends notice of nonrenewal on December 4, 2014.  Party A claims that the notice is invalid as improperly given, since it was received less than 30 days prior to December 31, 2014 (the end of the initial term).  However, Party B claims that Party A is relying on the wrong Effective Date, and matinains that the correct Effective Date is January 9 (the date last written on the originals), and thus notice of non-renewal was properly given.

A few years ago, I made two changes to my contract templates to eliminate the possibility of this problem.  First, I redefined the Effective Date as “the date on which this Agreement first becomes fully executed by all Parties hereto.”  Second, I added two date lines to the signature block – “Date PDF or Facsimile Signed” and “Date Original Signed.”  This approach ensures that even if originals are exchanged after PDFs, the date on which the agreement first became fully executed will be the Effective Date, and the signature block in the agreement will show clearly when a PDF or fax version was signed versus when an original was signed.  This makes it easier for not only attorneys to determine the correct Effective Date of an agreement, but for contract administrators, business owners, and others to ensure that they are recognizing revenue, and tracking and measuring performance, under the Agreement from the correct Effective Date. By implementing a more robust definition of the Effective Date in an agreement, parties can ensure that what is often considered a standard term doesn’t become a point of contention later on.

Risk Management 101

Risk management is, whether actively or passively, an ongoing process at all levels of an organization, one that can lead a company down the path to prosperity or ruin.  Any time someone asks, out loud or to themselves, “What if…,” “That could mean…,” “That might cause…,” “Have we considered…,”, or the like, they’re engaging in risk management.  Attorneys, whether in-house or in private practice, practice risk management in their daily activities – the core of our job is to facilitate our client’s business objectives while managing legal risk (attorneys are often viewed as the “de facto” risk management group within an organization).  Moreover, effectively managing risks can be a lot more difficult in practice than it sounds in theory. Fostering a culture throughout an organization that embraces, rather than shies away from, risk management (understanding what potential risks are, being able to identify them, knowing who should make risk management decisions, and making reasoned decisions) is critical to the success of any company.

At its core, “risk management” in the business and legal context can be defined as “the process of identifying, analyzing, and determining how to handle risks that may result from a proposed course of action or inaction.”  In other words, it’s the process of weighing both the positive and negative consequences from any particular course of action in making business and legal decisions. I use the following in my business discussions to summarize the importance of good risk management practices:  “It’s much easier to stop a snowball from rolling the wrong way while it’s still at the top of the hill.”

There are four core parts of risk management – (1) understanding what “risks” need to be managed, (2) identifying manageable risks during day-to-day business activities, (3) determining who makes risk management decisions, and (4) making risk management decisions.  I’ll save a detailed analysis of each for a broader article, but provide an overview and some basic guidance here.

Understanding the risk.  Risk management isn’t “avoiding all risk” – risk is an important part of business.  (There is an old AIG slogan – “the greatest risk is not taking one.”)  The trick is to manage risk to a level acceptable to the company.  Every company has a different tolerance for risk – e.g., start-ups may be willing to take more risk than a well-established company. Understanding what risks must be managed and an appropriate risk tolerance level is something that senior management (with the advice and guidance of internal or external attorneys) must determine, and must re-evaluate over time as the company grows and changes. The main types of risks that companies face on a day-to-day basis are (1) revenue risks (getting the business versus lost opportunity); (2) precedent-setting risks (the slippery slope); (3) legal risks; and (4) operational risks (writing checks the company can’t cash).

Identifying the risk.  If you remember anything after reading this, let it be this – you can’t make a risk management decision if you can’t identify and escalate the risk that needs to be managed.  Many companies are equipped to manage a risk, but don’t have good processes or training on how to spot them in the first place.  Company personnel – whether attorneys, sales team members, business owners, or any other employee, contractor, or advisor – must learn to spot risks associated with a proposed or ongoing course of action or inaction and escalate them internally (e.g., to their manager, to a designated risk management officer or team, etc.).  Managers should be responsible for educating their teams on spotting and escalating risks, and this should be a core component of any corporate-wide risk management training.

Approving the risk.  Once a risk has been identified, the next step is to determine the right approver of a risk management decision.  One of the hardest aspects of an effective risk management culture is getting someone to make a risk management decision, which is why effective risk management approval structure is essential.  Everyone is willing to take credit for a good risk management decision – no one wants to take the blame if the risk exposure actually happens.  If people fear they’ll be “thrown under the bus” for bad risk management decisions (whether that person is the presenter or the approver), establishing a robust risk management culture is not going to succeed.  Companies should consider assigning roles for approval of certain risks, discouraging/punishing individuals who do not follow the proper approval process, keeping good records of risk management approvals, and ensuring that individuals who make informed, well-analyzed risk management decisions aren’t thrown under the bus if the risk exposure ultimately occurs. (If proper risk management practices are followed, the realization of a risk exposure should not result in a “witch hunt” to find someone to blame, but should result in a re-analysis of the risk management decision to see if other “hindsight” data points would have affected the risk management decision and determine if changes to the risk profile of the company and/or risk management practices are appropriate.)

Making the risk management decision.  There are four things a company can with an identified risk – avoid it (don’t take the proposed course of action or inaction); mitigate it (implement new processes, obtain insurance, or take some other action to control the risk exposure) shift it (make another party responsible for the risk exposure, e.g., through a contractual indemnity and hold harmless); or accept it (proceed with the action or inaction knowing what might happen).  Each of these is a completely valid risk management decision, and they can be used individually or in combination once the identified risk has been evaluated (i.e., both the benefits and risks of a particular course of action or inaction should be presented to the appropriate decision-maker).  There are only two “bad” risk management choices – (1) accepting the risk because of a perceived need on the part of the business to “act quickly” and not take the necessary time to evaluate and manage the risk, and (2) accepting the risk because the risk was never identified in the first place.