Data and Analytics · Customer subscription model

Contract negotiation strategies for a joint project with potential profitability

Weihong Zhang Co-founder at Brilent, Inc.

July 26th, 2013

My company is engaged in a trading signal analysis effort with a fund management company. We provide quantitative methods to analyze stock data and recommend trading strategies, which will be bundled with their fund management platform system. We make profits by taking a portion of the subscription fees of the customers owned by their company. There are a few ways to make a contract for the effort:

(a) cash-only deal in which we develop the software product and deliver it for good. We charge the development costs at the market rates.

(b) Profit only from the prospect subscription fee. The pro is that it may have massive customer subscriptions, while the con is, if the integration does not happen for some reason beyond our control, our effort is voided.

(c) a mix of (a) and (b) where we trade a lower-than-market-rate development compensation for a portion of the subscription revenue in the future.

 

Please share your thoughts. If the other company insists on (b), how to negotiate?

Sandy Naylor Product Management and Development

July 26th, 2013

Your cash position will be key to answering this question.  Can you afford to wait a year or two or three for revenue - and deal with the possibility of getting nothing?  This is more important than any abstract 'right answer.'

It's hard for me to tell how risky this revenue is.  Is your effort a new feature for an existing product with an existing subscriber base?  If so, the revenue is not risky at all, and so (b) is essentially (a). 

Alternatively, is your effort a new product with zero subscribers today?  If so, to what extent will you be able to influence marketing and sales strategy?  Or are you dependent on the partner providing resources and solid strategy to sell?

Are the trading strategies being developed by your company?  That is, are you offering investing expertise along with development manpower?  Or, are you a development shop?

Finally, to what extent do you believe in your product?  Not just its technical execution, but its ability to drive excess returns for users?  This will be intimately interconnected with the previous question.

Now, to bring all these questions together.  To the extent that you need cash, are building a feature, can't control sales and marketing, offer dev skills only, and don't believe in the product's ability to create alpha, you will be leaning towards (a).

To the extent that you have more appetite for risk, are building a new product, can influence sales and marketing, offer investing know-how, and believe in the product's ability to generate alpha, you will be leaning toward (b).

In practice, I think maximizing cash now [(a)] is a strong option, with some bonuses for achieving certain hurdles.  Especially if you can't control marketing and sales.

If they want you to go in the equity-like (b) direction, you will want to see commitments on marketing and sales support.  Worst case scenario is, you build a great product and they don't devote resources / strategic thinking to get it out the door.

Nick McLain Helping Millennials Vote

July 26th, 2013

Why not use a license model and generate revenue per seat (B)? The fund would buy the amount of licenses prior to delivery to the end customer so any integration issues would belong to the fund. Nick McLain

Jonathan Vanasco

July 30th, 2013

I'm not really sure how to think in those terms. 

In publishing, we often had vendors offer to give us X,Y,Z to monetize traffic and they would do a 50/50 profit sharing.  Sometimes it went to 60/40.  

In your case, you're saying "We're going to bill % of subscription fees", but i'm not clear on how your software fits in.  Are they just planning to resell your product and then you're getting a cut of that ?   If that's the case, 20% sounds low -- you're really talking about an 80% sales commission.  

The two sales notions that I keep thinking of are:

a) As far as they're concerned, your product should be done; you should be charging Professional Services fees for integration and customization.  Ideally that's done so at a profit , so you underwrite the costs of internal projects/maintenance/other costs.

b) I'm not comfortable with the idea of developing a bunch of software for someone on the promise of revenue by them reselling subscriptions.  You mentioned that the project could be abandoned at any point ?  Do you have an exclusive contract , where they won't develop something in-house or use a competitor for X years ?  Do you have a contract where they guarantee Y number of sales ?  

I'd honestly push for professional services fees to customize your algorithms for their requirements and APIs for integration, and also insist on a "kill fee" -- if they drop the project or go with a competitor, you're awarded something.  If you can't get that, I'd question whether or not this deal is worth it. 

Usually kill-fees will be something like "pro rated project budget, not to be less than 75% of  total budget" or that + the projected revenue for X months.  As a quick example -- if you sign a contract with Akamai, they  want 75% of your bandwidth for the year; and maintain rights to bill at the contract rates for the difference between their carriage and that 75% level; if you want to exit the contract, it's cheaper to pay their minimum monthly billings and hope they don't ask for more money, than it is to negotiate an exit ( where they will forecast what their bills should be ).  Google(DFP) and Adobe(Omniture) do the same exact things.

Also,  I'd definitely start talking to their competitors and be ready to play groups against each other. If you can't get a good deal, and decide to pursue because you had an interested investor, you'd still need to be able to quickly sell your product to any of their competitors on a moment's notice.

Jonathan Vanasco

July 27th, 2013


Have you considered any of the traditional "Enterprise Software" business models ?   It seems like they'd be a natural fit.

Typically you would give clients the ability to either a) subscribe to a software service that you host or b) pay a license fee to host on their own infrastructure.  there's usually an initial account setup fee, then the monthly/yearly costs.  the self-hosted variants will often charge a site license or per-cpu license.  on top of that, you offer Professional Services for custom development or integration help at market rates.  

Anyone that you'd be working with is dealing with these types of contracts already, so negotiating specific terms should be rather simple around frameworks like this.

I'd also add a tangent to Nick  McLain's comment -- your "Sales Products" don't need to line up with "Internal Products" ( and your "internal products" might not line up across departments ).  Don't let your tech or sales teams define what the company's products are -- sales should be slicing / dicing and rearranging existing (and potential) products into whatever they can bill on.  Then can also bundle different things together to fund your R&D ( just like with Cable Television -- the only way to get Network X is to buy the package with Networks Y,Z that you don't want )

Weihong Zhang Co-founder at Brilent, Inc.

July 28th, 2013

Thanks to Nick and Jonathan for sharing your thoughts. The method of three products and three pricing/distribution models is appealing. Their importance and weights in the final subscription offerings software can be used as a reference for negotiating the percentage of the profit portion. I think that either side hosting the service can work out in my case. Maybe self-hosting model is more advantageous for our side since the changes or updates of the fund software modules require our professional services to align them with the hosting environment.

The discussions so far have helped me greatly in planning the products/profiting/pricing/distributions. I want move to consider this question: if the fund is reluctant to give us cash for covering our development efforts and only like us to share the future profit after the subscription service is up and running, but I want to negotiate with them to offer some cash before the profit is materialized, how can I persuade them to do so? The logic of the fund is justifiable because they can say that their cash flow is constrained and they already offered sharing the future profit.

The way I can think of to figure things out is that I can take a lower percentage of future profits if the fund can offer some cash to cover our development cost. Say, if by calculations I can take 20% of the subscription service revenue, but if they can offer some cash now, I can lower it to 15%. Certainly, the product risks and marketing risks kick in here, as Sandy mentioned earlier. Another way I can think of is to tie the cash amount to their marketing efforts/commitments -- if more marketing efforts are committed (hopefully more likely success of the subscription offerings), we can lower requested cash amount. I am not sure how the fund will respond, although at least we can try. I like to have your thoughts in this direction. 
 

Nick McLain Helping Millennials Vote

July 30th, 2013

I agree with Paul Travis; it comes down to your vision for the company.

There are corporate clients, channel sales, and direct-to-consumer routes that can be taken. And it's ultimately up to you to determine where the best benefit exists.

Perhaps it's the right time to bring in a Sales Leadership role?

Chris Nunes

August 1st, 2013

You could also position your new product as an equivalent in terms of marketing spend, i.e. "You, hedge fund, need new products to market to your customers. You can't build this kind of product in-house and adding this product to your platform makes your platform overall more marketable.  By announcing the availability of this product to your customers, you're going to get industry exposure in press, newsletters, blog reviews, etc. that are equivalent to an ad buy of $$$.  Lets talk about paying us a development fee of ($$$) x (Y%) in exchange for our product that now gives you lift in the industry, and if you're good at what you're doing and your customer base is really worth what you're telling us, then we'll also take Z% of the transaction - because we're willing to take some of the risk on the development cost."
Position your development costs in terms of other expenses they would have to pay elsewhere - marketing, regulatory, salaries + benefits, etc.

Nick McLain Helping Millennials Vote

July 27th, 2013

Perhaps first consider each of your three products, uniquely. Manage them as individual businesses with their own pricing and distribution models. Three products, three models. A more complicated approach would be to permutate all products so that each can stand on its own, and combine with one or both of the others. That would leave you to create seven product pricing/distribution models: 1 2 3 1,2 1,3 2,3 1,2,3 Each product model should be priced relative to customer access and business benefit (e.g., typical weekly use by customer for product 1 = monthly recurring fee (vs flat one-time fee)) Recurring fees build predictability into your revenue stream. Hope this is of help. Nick

Weihong Zhang Co-founder at Brilent, Inc.

July 30th, 2013

Thanks guys for very helpful follow-ups. To Jonathan, our products, more specifically our software modules that provide trade signal analysis, will be integrated into the end product that fund customers can use for receiving trading signals and strategies. Hence, they do not simply resell my products; instead, they bundle ours with theirs and then sell. The software modules can be delivered as licensed source codes, or more preferred as APIs. I feel that if my 20% is too low, then 80% is too high. The fund provides the current software platform, their data sources, model-to-visualization translations, user interfaces such as desktops and smartphones and tablets, and very importantly their current customer base. The estimate of the percentage will be more accurate later as a split of software functionality and contributions from both sides becomes definite.   

Jonathan's Point b) is exactly my concern. We started this efforts based on a "private" and "reliable" business connection. The project is not expected to be abandoned. We have not talked about a guaranteed number of subscriptions, although they have a good number of customers for other services right now. They do not have an in-house development team for this and thus rely on our contribution. We do not have an exclusive contract with them yet; that is why the thread is called "contract negotiation strategies". I expect to move soon to that point of having something in writing.

The notion of kill-fee is something I really like to pursue.  It is a good idea and pretty doable to prorate the killing fee based on  the full development costs as we can estimate the overall costs of developing the models and software modules. The Akamai example is enlightening. I understand  in the context of internet firms "if you sign a contract with Akamai, they  want 75% of your bandwidth for the year; and maintain rights to bill at the contract rates for the difference between their carriage and that 75% level." I know that Akamai and other internet firms use traffic and clicks for building their business and revenue model, but not sure how the "75%" plays out in a customer subscription model in our case.  Maybe one relevant measurement is the size of the customers. Say, if they have X customers now and they have Y customers after a period of offering the subscription service, we got a difference Y-X. It would be interesting if we have certain ways of relating Y-X to the subscription service and further to its internal modules (including mine). I like to do some maths if  there is maths here.  

Thanks to Paul for bringing two other dimensions. I have to say that insofar I am development-oriented and have no experience of managing a sales organization. I have a lot to chew on the road and hope to digest a little daily. The volume dimension is a big aspect here. Surely 0~100, and 101~1000 are quite different. As our products or MVP prototypes are ready, I will work on the first 3 for the very beginning. To Nick, I will spend about several more weeks to develop and refine our models and results. I will see how the negotiation goes and decide a Sales Leadership role then.

Jonathan Vanasco

July 31st, 2013


Think of it in other terms - those Akamai/etc contract points are based on expected minimum revenue generation.   You're extending them a courtesy price ( x% discount over "published rates"  ) and/or professional services ( integration , customization , metered support , etc ) in exchange for their commitment to future revenue.    Through this partnership, you expect to make $x as a minimum, per month, over x months.  It's up to them where they generate the revenue for paying you the minimum fees -- usage of your product, resale, subscription fees, or other methods.  You should be able to work with them to phrase it into something that looks good on both your balance sheets and theirs.