In this series, I’ll discuss the key areas in contract negotiations that Product Managers need to know. I’ll describe the basic contracts you’ll encounter (NDA, MSA, SOW and CO) and key watchouts from both the Client and Vendor perspective.
When working with a Client or Vendor, you’ll usually find 4 types of contracts:
Non-Disclosure Agreements (NDA)
Master Services Agreements (MSA)
Statements of Work (SOW)
Change Orders (CO)
You might encounter these as multiple documents or they might be consolidated into a single one. The image at left summarizes the contracts flow. It all starts with an NDA and then an MSA. MSAs can have multiple SOWs, and each SOW can have multiple Change Orders.
As a software manager, I strongly recommend becoming familiar with contract language and staying involved throughout the contract negotiation. Many red-lined versions will go back and forth between your two companies. It’s in your best interest to understand what these contracts are about and what you are signing up for, whether you are on the Client or the Vendor side.
/ / Key Watchouts
1. Stay involved: DON’T leave contract negotiations exclusively to Legal or (worse) to Sales. They have different incentives than you do. And at the end of the day, you’re the one on the hook to deliver or receive what was agreed upon.
2. Are you authorized to sign? Keep in mind that contracts are legally binding documents between two companies. Often, only a few people within an organization are legally authorized to sign contracts. So unless you have signature power within your organization, you should never sign a contract or any legally binding document. You could get yourself or your company in trouble.
Contract negotiations are usually tough, take a long time and they can make or break a project. In general, everything in life is negotiable, but the bigger company usually has the upper hand. If you are the Client and work at the bigger company, chances are you’ll be able to get away with a lot. Vendors will bend over backwards to accommodate your needs and get your business. On the other hand, if you are a startup or smaller company and would like to work with a big established Vendor, then chances are, you won’t have a lot of leverage. Regardless of the situation, negotiation is key. My book section has some recommendations on negotiation books in case you need to brush up on your skills.
In a nutshell, here is what each contract covers, and key watchouts for each:
Non-Disclosure Agreement (NDA)
An NDA is an agreement between a Client and Vendor to not disclose proprietary information with anybody outside the companies. As a Client, you’ll probably want to sign an NDA before you start sharing too much information about your product/project with a Vendor, and it’s common to sign NDAs with multiple Vendors before making a final selection. That way you’ll be able to share more information and get more realistic bids.
// Key Watchouts
1. Unilateral or mutual? NDAs can be mutually or unilaterally binding, meaning either one or both companies is prohibited from sharing the other’s info. No matter which way you go, the important part is to make sure you and your company are on the protected side.
2. Company or individual? Make sure that the NDA binds the company and not the individual employee. If you are the Client, you need the certainty that nobody on the Vendor side will divulge your trade secrets. If you are on the Vendor side, it’s a good idea to make sure nobody on the Client side can talk about your procedures and your “secret sauce”.
Master Services Agreement (MSA)
An MSA (a.k.a. Master Contract) defines how two companies will do business together. It is an umbrella contract that governs every SOW you undertake together. The MSA includes very important things like: payment terms, who owns the intellectual property (IP), marketing rights, limitations on liability, how to solve disputes, no solicitation of employees, warranties and so on. Very involved legal stuff. And chances are, both Client and Vendor side will have an MSA template they’d like to use. Which template to use is just the beginning of the negotiations. MSA negotiations can take weeks if not months. Make sure you account for this delay in your project roadmap or schedule.
// Key Watchouts
1. Ownership of IP: A key negotiation point is who owns the intellectual property created during the engagement. Some Vendors release all IP to the Client, while others just give a “perpetual license” but keep the rights. This allows the Vendor to take whatever they built for you and resell or reuse with other Clients. Make sure you understand your company policies and decide whether this clause is a deal-breaker.
2. Payment terms: Cash flow is important. As a Client, you’d like to pay as late as possible, but as a Vendor, you’d like to get paid as soon as possible. The standard terms I’ve seen are “net 30”. If you are on the Vendor side, keep in mind that the term starts counting from when the Client receives the invoice, not from when you sent it out. So “net 30” is really more like “net 35”, and that’s if they pay on time. Make sure your cash flow can take those hits. On the other hand, you can negotiate for shorter payment terms, for example “net 10” or “due on receipt” in exchange for a discount or other concessions. Everything is negotiable.
3. Marketing rights: For many Vendors, the ability to add a big name to their portfolio is invaluable. Many Vendor MSAs include a clause stating they can use the Client logo or advertise that they worked on a specific Client project. However, many Clients consider their chosen Vendors to be a strategic advantage, so they want to keep them secret and don’t allow for this clause. A common negotiation is to agree to a joint press release in exchange for a discount or better payment terms.
4. Non-Solicitation: MSAs usually include a clause to prevent Clients from hiring the Vendor employees. This is a way for the Vendor to protect themselves and keep the Client coming back for more. As a Client, if you really want to hire a person (and they want to come work for you), then you need to openly negotiate it with the Vendor. If you proceed without written permission from the Vendor, you might have a lawsuit coming your way for breach of contract.
5. Limitation of Liability: Usually, this clause states which side is responsible if the Client gets sued for work done by the Vendor. Some big companies have brutal liability clauses. For example, they might claim that the Vendor is liable in case the Client is sued by another company for patent infringement even if the Vendor had no idea about those patents. Basically it’s just a way for the Client to deflect all blame and use the Vendor as a scapegoat. This type of clause can bankrupt a company, so make sure you understand all the risks before signing. Possible solutions include modifying the language to add more protection for the Vendor and/or buying liability insurance that will be valid a certain number of years after the engagement is over. If buying insurance is the agreement, then it must be specified in writing in the SOW and the Vendor must show proof that they, in fact, bought that insurance.
Statement of Work (SOW)
Once the companies have agreed on an MSA (a.k.a. they agree how to work together), now it’s time to negotiate the specifics of the actual project. Each project will have its own SOW, but they all fall under the same MSA. Basically, the MSA defines the “how” and the SOW defines the “what” of the work.
The SOW defines, in detail: the deliverables, timelines, price, invoicing schedule, conditions and assumptions for any particular project. If you are on the Client side, this is what the other company is legally agreeing to deliver to you. If you are the Vendor, the SOW is what you are committing to deliver. Depending on your type of engagement, the SOW type may vary. The most common variations are:
Time & Materials: Client pays Vendor for a certain number of hours of work. Client has to cover any overage incurred to complete the desired deliverables. (see part 2 of this series)
Fixed Price: Client pays Vendor for specific deliverables. Vendor has to cover any overage incurred to complete the deliverables. (see part 3 of this series)
Retainer: Client pays a monthly fee in exchange for unlimited (or loosely limited) services. (see part 4 of this series)
Staff Augmentation: Client temporarily adopts a Vendor employee into their team. (see part 4 of this series)
Recommended post: Internet of Things: A Primer for Product Managers.
Change Order (CO)
As part of the MSA, companies often agree to a change management process, which includes Change Orders (a.k.a. Change Request Order). Change Orders document any changes in scope, budget, timeline, assumptions or any other deviation from the current SOW. A particular SOW can have many change orders. Once a CO is signed, the corresponding language in the SOW is no longer valid, and the CO becomes the new legally binding agreement for that part of the contract.
In general, change management is difficult to track. Often companies refrain from doing Change Orders because they fear the project will slow down until the companies finish negotiations. Don’t be discouraged by this. It is very important to document every change and have the matching contracts to back you up.
//Key Watchouts
1. Keep it in writing: Handshake agreements are often a recipe for disaster. Doesn’t matter how big or small of a change, I strongly recommend creating a Change Order to document the new agreement. As a Vendor, I’ve been burned a few times by having handshake agreements and then having the Client side stakeholders change. Yikes! The new stakeholders didn’t recognize our agreements and wanted (rightfully so) to go strictly by what was in the contract. Can’t tell you how much trouble that was…
2. Be clear and explicit: COs (and any contract) should have little room for interpretation. Make sure the changes are quantifiable and deliverables are clear.
3. Zero-dollar CO: Not all COs have to involve money. It’s common to do “zero-dollar change orders” meaning that the change is in schedule, assumptions or content of the deliverables.
4. Bundle changes: If your company is too slow to sign contracts, you might save time by bundling many changes in a single Change Order.
Recommended post: A Product Management Framework for the Internet of Things.
The Bottom Line
Contracts are a complicated part of software management, so it’s important to get a basic grasp on them. The most important piece of advice is to make sure that all assumptions, deliverables, timelines etc are clearly stated in your contracts.
Avoid handshake agreements or additional comments in emails or other documents. Contracts are legally binding documents, and you want to make sure everything is in writing while the relationship with the Client/Vendor is still in good standing. If a problem arises, companies go with what’s on the contract. If it’s not there, you have no leverage at all.
So where do you go from here?
Now that you know the basics, it’s time to dig deeper into each type of contract:
Part 2: How to Negotiate Time & Materials Contracts






Hi Daniel,
What is a 0$ SOW? And when is that used? I was readying your explanation for LOI. Is LOI similar to 0$ SOW?
Also what kind of SOW do I submit as a vendor in case of a pilot project? and how do I handle changes in SOW due to delay in project for dependencies on client? and delays from the vendor side?
Can you please help explain these.
Regards,
Sharma
Hi Sharma,
An LOI can come even before an MSA/SOW to let the vendor know that the company is serious about doing business but they are slow at getting the contracts signed. A $0 SOW implies there is an MSA in place and its purpose is to document work your company agrees to do at no charge, but you still want to keep legal record that it happened. $0 SOWs can be used for new projects, but if you want to make a concession on an existing project (one that has an existing SOW) it is more common to do a $0 change order.
Changes due to delays (or other things), need to be handled based on the initial agreements included in the MSA. You don’t want to be negotiating what to do with delays once you are already in one. You need to agree that upfront in the MSA. The usual way to handle it is by having clear language stating what happens in each scenario, for example, any delay of X days from the customer, will result in delays on your end of Y days, or will result in penalties of X% of the SOW value, or will result in a change order, etc.
Hope this helps,
Daniel
Hi Daniel,
This really helped.
Can you please explain about the whats whys and whens of a RFPs ( request for proposal)?
Thank you very much
Hi Sharma,
I’m glad my article helped you. RFPs are used when bidding for a big project. Big companies or government entities usually can’t select a vendor at will. Their processes require them to launch a “competition” where they evaluate multiple vendors. As part of this competition, they issue an RFP so whoever wants to bid can provide the necessary information to be invited to the negotiation table.
Hi Daniel,
Thank you for the explanation. That helps.
So does the RFP involve the SOW or is it vice-versa? Or are they both independent? and is there any order in which they are executed?
Regards,
Sharma
The RFP comes first since companies are evaluating potential vendors. Once the vendor is selected, then you go into contract negotiations starting with an MSA and then an SOW.
Best,
Daniel
Hi Daniel,
Thanks for this article, it has given me a lot of confidence in dealing with MSAs. I’ve recently started up my own LPO and thanks to you for your guidance, indeed the article is very helpful.
God bless you
Excellent Article! I am a fresher in an Organisation, and I was able to interpret this easily. Thank You very much..!
Thank you. I’m glad you found it useful.
-Daniel
I am an architect accustomed to very different contract terminology than that of the tech world. This is an excellent explanation - one of the very best I have read about any of the many types of contracts I have encountered in my 40 years of practice. Thank you Daniel for sharing it. Clear, Crisp, and Concise. Great Job!
Hi Peter,
Thank you for your kind words! I’m really glad the article was useful.
-Daniel
very nice write up.. thanks daniel
Glad you liked it. Thanks for reading!
-Daniel
good one
Fantastic article. It’s informative, concise, and well-written. You have no idea how long it took me to find a simple and one-stop article to explain these component parts. Thank you!
Thank you Evan! I’m glad you found it useful.
-Daniel
Are you there? I have a quick question re MSA vs. SOWs. If there’s a conflict in terms, shouldn’t the SOW generally control?
Hi Aaron,
In my experience, the MSA is the one that prevails. Once the MSA is signed, then you can have multiple SOWs under that same MSA. All the SOWs are governed by the MSA. In situations where there are conflicts, I’ve seen both parties go back to the MSA and update that. The modification now applies to all SOWs, not just the last one.
Ultimately, I recommend you get your legal team involved to avoid any issues. Our responsibilities as Product Managers is to raise these issues, but it’s important to get proper counsel if we find discrepancies.
What has been your experience?
-Daniel
Hello Daniel
I did not know so much about contracts but after reading your post I can proudly go back to my manager and say that I understand all the these terms.
Can also explain LOI and where will you put this in order.
Hi Mohit,
Thanks for your comment. I’m really glad you found the article useful.
Good question about LOIs! A Letter of Intent (LOI) is a document that formalizes a “hand shake” agreement between two companies. It doesn’t have the legal weight as other contracts. As the name implies, it just shows “intent” of two companies to do business.
A common use of LOIs is to accelerate the start of a project. Usually, the person contracting the service (i.e. a Product Manager) has a tight deadline and she can’t wait for her legal or procurement department to turn around the final contracts. In that case, she might ask the vendor to start the project “at risk”, meaning without a signed contract with the promise that “the contracts will be done soon”.
Understandably, the vendor will be hesitant to start the project without a signed contract, so they ask for an LOI to at least know that the company is serious about contracting with them. When vendors accept an LOI, they are baring all the risk because they’ll be putting resources into a project before closing the deal.
If you are a buyer, you can use LOIs to your advantage to accelerate the start of your projects. Just make sure your company is really planning to go through with the contracts. Otherwise, it’s better to wait for the full contracts to be signed. If you are a vendor, you can use this tool to secure a client and meet your revenue goals. Just understand that the customer might back out of the deal or they might come back with terms that you don’t agree to.
Since and LOI can signal the start of a project, it usually comes after an NDA.
Let me know if this helps,
Daniel