How to Protect Your IP in P2P Alliances
In the last couple of years, we’ve started hearing a lot more about partner-to-partner (P2P) alliances. Customers are demanding end-to-end solutions on a consumption model, and partners are selling to the line of business (LOB) buyer rather than the CIO. Traditional partners have been told to hyperspecialize, to learn how to solve for business outcomes, to invest in emerging technology, and to change their entire business models in order to accommodate the subscription-based economy.
But no one can do it all these days, and many traditional VARs and MSPs are looking to form partnerships with niche ISVs–a partner type that has a long history of hyperspecialization, LOB sales, and recurring revenue models. Many large vendors and distributors are helping to facilitate those partnerships, but their programs–and the concept behind them–are still nascent and need the kinks worked out. So a lot of partners are forming their own P2P alliances.
It’s a smart move, if done correctly. But navigating these new waters can be tricky. If you’re a VAR that’s used to traditional, reseller vendor programs, trying to figure out the parameters around a P2P alliance is a totally different ball game. It’s different enough just selling SaaS solutions on a recurring basis. But many traditional partners that are listening to their customers and the market are realizing that this focus on hyperspecialization and the LOB, combined with the rapid pace of change, means they need to develop customized solutions in order to differentiate themselves. They need to stop focusing on infrastructure and move up the stack where the margins are higher.
“Many of the ‘_aaS’ are turning into commodities,” says Jay McBain, principal analyst of global channels at research firm Forrester. “There are about 20 already-declared ‘winners’ across the lines of business (Salesforce, Marketo, Workday, NetSuite, etc.) and the real battle is shaping up to be the layers above the winning platform.”
The partnership between traditional resellers and software development houses is natural. VARs have the deep relationships with customers and experience selling services and solutions, and ISVs bring the LOB expertise and up-the-stack custom SaaS applications. But these two partner types have historically been competitors, and while the value of collaboration is clear, suspicions often run deep. Having a solid framework in place can go a long way toward alleviating that–but how do you know you’ve covered all the bases?
“The IP is the company’s first asset, so it should be treated as the most valuable,” says Kumar Vinnakota, a partner at Janik Vinnakota LLP, a Dallas-based law firm specializing in IP and patent protection. “Sadly, most companies don’t realize this and the protections are an afterthought, which causes cracks in the overall foundation of the company in the future if the IP is ‘disruptive.’”
Defining these relationships is hard because there’s still no best practice for how to go about it. The ISV will probably have a standard contract it sends all of its clients, but resellers and service providers should read it carefully to make sure there are no hidden loopholes, and always consult an attorney before signing. Some things to watch for might be:
- A reluctance to talk through the tech. Before ever signing with a software development firm, partners should sit in a room until they’re convinced the ISV understands what they want. This may take hours, and the development team may balk, but this should be non-negotiable. Talking through workflows, user experience, and back-end processes in person is essential to defining the scope of the project. You never know what unforeseen hiccups might arise in these brainstorm sessions. Companies have been known to change their entire go-to-market strategy based on these discussions.
- Vague deliverables and timelines. How does a partner track the progress of ‘software solution development’? ISVs should be able to provide a breakdown of each stage of the project, what components are involved, and the time it will take to develop them. Yes, things may change down the road. Market or customer research may impact the go-to-market strategy or the user experience, for example. Contingencies for situations like this should be written into the contract. But if there isn’t a well-defined schedule of deliverables, partners have little to no recourse when the project drags on longer than anticipated or is delivered incomplete.
- Clarity on subcontractors. A lot of development houses work with subcontractors outside of the U.S., typically low-level developers, engineers, or testers that perform mundane tasks at a fraction of the cost of workers in the States. These subcontractors are in many cases not subject to the terms laid out in the original contract, and their use can carry unexpected consequences. If there’s a hold on the project, for example, will the developer be able to bring the same contractor that worked on the project before and is familiar with the workflows when development resumes? Does the contract stipulate that these workers are paid at the same rate as higher-skilled American workers? Most importantly, the terms and conditions outlined in the contract partners have with development houses may not apply to the subcontractor. After all, they’re in a different country with different regulations. Even if it’s determined that the subcontractor violated a binding contract, who’s going to head over to India or Romania to engage in foreign arbitration? Partners should look at these clauses carefully. If there’s no mention of subcontractors in the contract, or if their definition, hourly rate, or confidentiality agreement is vague, the ISV should amend the contract to address these concerns.
- ISV rights to use of IP. Even in the simplest situations, there are considerations that should be taken into account when it comes to clauses specifying what rights the developer has to the intellectual property. The most innocuous stipulation can carry consequences. For example, it’s best practice to allow ISVs to use the tech they’ve developed for marketing purposes. But what happens when they slap that project on their website before the partner has even launched it? Service providers should watch out for clauses dealing with the use of code, too. Most contracts say that the developer can use the code they’ve written for other projects as long as those clients aren’t direct competitors and the purpose of the tech is different. But as anyone who’s gone through a commissioned SaaS project can attest, things rarely go according to plan, and what started out as one solution can easily turn into another. When an e-commerce portal turns into a data collection platform, for instance, the competitive landscape changes.
- Remuneration and revenue sharing structures. It’s complicated enough if the project is just on a one-time basis. But what about when service providers and software developers decide to go into business together? Suddenly, the complexity increases exponentially. If the ISV accompanies the reseller on a sales call, and they land the deal, who gets the commission? What percentage of the revenue does each party get each month? What happens if the ISV partners with another VAR on a similar project? Who is responsible for the customer support costs? Whose brand will be on the end user solution, and who will bear the cost of marketing? If these considerations, and a host of others, aren’t addressed in the contract, partners can find themselves embroiled in a bitter legal battle or hostile working relationship they can’t afford to get out of.
In the end, partners shouldn’t try to go it alone when it comes to protecting the IP they’re building their business on, especially if they’re hoping to attract investors or potential buyers. Safeguards and protection around the tech that hopefully will be disruptive minimizes the company’s risk and increases its valuation, says Vinnakota.
“The safeguards that investors look for include NDAs, IP assignments, effective IP management for patents, trade secrets or trademarks, and a plan for diversifying these assets, while also trying to take the core business ideas to market,” he says.
At the very least, partners should have an IP lawyer read over the contract before they sign it. There’s no map for these partnerships, and no crystal ball to tell them how everything is going to work out. Partners should be very careful lest they become a cautionary tale.
