Thursday, September 8, 2011

Adding Issues to Create Value

As we’ve discussed in prior posts, one of the most straightforward and effective ways to create value in a negotiation is to identify and implement value-creating trades.  If getting your way on an issue is worth a million dollars to you while getting my way is worth half a million to me, then my goal shouldn’t be to get “my way” but rather to let you get your way…in exchange for more than half a million dollars in value.

In some deals this is relatively easy.  The discussions begin with a variety of interests identified, the parties are sophisticated enough to be able to evaluate trade-offs efficiently and discussions move effectively towards the value-maximizing configuration of terms.

Frequently, however, life isn’t so simple.  Today’s post looks at introducing issues to a single-issue negotiation using a real-world negotiation I’ve just begun with a software developer.

Some years ago I published a card game called The Battle for Hill 218.  It’s fun, quick and deep and has been my most successful single product (still selling quite well today).  A few different players have asked me to consider making a version for the iPhone or iPad and recently one of them introduced me to a developer who was interested in creating an iOS version on a revenue share basis (i.e. instead of me paying for his time, he’d be paid out of a share of sales for the app).

The developer’s initial offer was a 70/30 revenue split in his favor.  Alternately, I could pay him a flat fee which would be somewhere in the $10K to $20K range.

If the revenue split is all we’re negotiating there’s not much we can do to create value in the deal.  Naturally there’s some value in each of us being happy with our agreement and being motivated to promote the app, but for the most part we’d be haggling on price and trying to capture as much of the ZOPA as possible.  If there’s only one issue, there’s no room for value-creating trades. 

Price, however, is rarely the only important issue worth discussing and in this case there are a number of other possibilities worth considering besides the split of sales.

Price of the app.  Even if we agree on what price will maximize revenue of the iOS version of Hill 218, either of us might want to set a lower price in order to attract more users to the app.  The developer might like wider exposure of his work and to be able to say (to other potential clients) that he produced an app that a lot of people downloaded.  More concretely, I have a monetary incentive to maximize users (especially new users) since I’m still selling the physical game.  I’m convinced that offering a free Java version of Hill 218 played an important role in sales of the physical game, and having an iOS version is likely to lead to more sales as well.

Let’s assume for illustration purposes that his ideal price is $3.99 and mine is $1.99.  Our next task is to determine how strongly we prefer those prices, as well as how we feel about prices in between.  If a price of $1.99 is worth $5,000 more to me than $3.99 and is worth $3,000 less to him, then pricing the app at $1.99 creates $2,000 in value between us.  Put another way, I can give up over $3,000 in value from app revenues (which makes him better off) and as long as I give up less than $5,000 I’m better off as well.

Marketing budget.  Presumably we can increase sales somewhat by advertising, but I get a double benefit since advertising should boost sales of the physical game as well.  To keep things simple, let’s assume that we each think that each dollar (up to $1,000) of advertising would lead to only eighty cents in additional app revenue (forty cents to him and forty to me if we’re splitting things evenly) and that I also think it will be worth forty cents in additional revenue from physical sales.  The total value of advertising is $1.20 per dollar, so it’s clearly attractive.  If, however, we don’t negotiate advertising then it won’t happen; he gets only forty cents on the dollar and I get eighty (forty from the app and forty from the physical game).  Neither of us gets enough to justify doing it alone.  If, however, the developer “pays” me more than twenty cents and less than forty cents for each dollar of advertising I do, we’re both better off.  (Payment could be done directly (i.e. we share the actual ad expense) or indirectly (i.e. factored into the terms of the deal).

Split based on results.  Hill 218 is a new game for the developer.  He’s played it online and likes it, but he’s naturally cautious about how much it will sell.  I’m more optimistic, given its sales numbers and how popular the Java app has been.

This difference will naturally factor into our discussion over what a split should be.  He’ll point to the number of game apps that sell less than a thousand copies and argue that he’s unlikely to make a normal developer fee even with 70%.  I’ll talk about how many unique players the Java version has, how the physical game has nearly sold out its second print run and the posts on BoardGameGeek asking for an iOS version.

The key to moving that discussion past arguments for value capture is to recognize that different expectations create room for a compensation split that both parties prefer to any flat fee they might agree.

To keep things simple, let’s assume a price of $3.99 (before Apple’s 30% commission) and volume forecasts as follows:

Developer’s Guess
Chad’s Guess
Total Sales (unit)
Total Revenue ($)
Each party’s share

(Total sales is calculated by multiplying each percentage estimate by that amount of sales, i.e. the Developer’s total sales is 70% of 1,000 plus 15% of 4,000 plus 15% of 10,000.)  N.B. These are not my assumptions and I have no idea what assumptions the developer may have -- I put them up here purely for the sake of discussion!

The developer’s average estimate puts total dollar sales at less than $10K and he thinks there’s a 70% chance that sales will only be about 1,000 units, or less than $3,000.    I think sales will be nearly $20K and my most likely scenario is a “hit” with 10K unit sales and about $28,000 for us to split.

Given this variance, the last thing we should try to do is agree a single fixed split.  That’s could break the deal altogether and is likely to lead to resentment down the road when one of us turns out to be right.  If I persuade the developer to take 50% and he ends up getting paid $1,400 it’s a turkey for him; similarly if sales are close to $30,000 and he got 70% of it I’d wish I’d never agreed to a revenue share deal.

A simple alternative is a split that changes as sales grow.  Suppose the developer gets 100% of the first 1,000 sales, 75% of the next 1,000 and 25% of sales beyond that.  The developer would expect to receive $4,480 (on average), an increase of 15%, and his risk is much lower.  If he’s right that the most likely outcome is only 1,000 units at least he gets 100% of the sales.  I also expect to receive about 16% more this way, albeit with a higher risk of getting nothing.

Some would argue against calling this value creation since eventually one of us will be proved wrong.  Both parties might like this deal better up front but in the future one will be better off and one worse off by exactly the same amount.  I would counter with two points.  First, being able to “bet” according to one’s beliefs is generally regarded as valuable.  Investors buy and sell stocks, companies invest in markets and technologies, collectors buy stamps, coins and other items based in part on their estimation of what the future will bring.  Enabling two parties to act according to their expectations of the future is a valid goal of negotiation.

More fundamentally, while one of us will be worse off we’re more likely to be satisfied with the variable commission because the result will be much closer to what we would have agreed if we knew the sales up front.  If unit sales are just 1,000 I won’t feel bad that the developer gets all the revenue…and if I expected sales to be that modest I would view the app as a nice promotional item rather than a source of revenue.  Similarly, if app sales are 10,000 units can the developer really feel badly about only getting around $10K?  Not only do sales of that level imply that the game (my contribution) was highly valuable, but if we knew that sales would be that high I could contract to have the app done by a professional firm for that amount.

How to Introduce Issues

Introducing issues is generally trivial with experienced, sophisticated negotiators.  They’re eager to include as many important issues as possible for the same reason you are – they know that’s a powerful way to maximize the deal’s final value.  The challenge arises when your counterpart doesn’t have this perspective.  He may see an attempt to introduce issues as some sort of gamesmanship or a waste of time.  Perhaps worse, he may see it as a request by you that merits a reciprocal concession – that is, your effort to introduce value creation may be met by a value capture effort by the other side.

I’ve found the best approach is to be up front and open about why you want to add issues and then to share at least top-level thoughts about where your interests lie (and where you think your counterpart’s may lie) on each topic.  For example, here’s an excerpt from the email I sent to the developer on the subject:

If we can put haggling aside for a moment, however, I'd like to make sure that whatever agreement we reach is as valuable to us in total as possible.  As you may guess from my signature, I'm a negotiations geek in addition to being a game geek.  This doesn't mean that I'm a particularly hardball negotiator but rather that I'd like us to make sure that we aren't forgetting any "levers" in our agreement that might make the final deal more valuable to each of us.  In addition to royalty split, I can think of some other terms we should discuss and I'll share my thoughts about my own interests on them.

I start off by establishing this as separate from haggling over price.  This helps avoid the “OK, we can discuss these things but you’ll have to do better on price” trap and makes it clear that adding issues is a mutual and collaborative process of value creation.  I finish by offering my thoughts, which then invites him to reciprocate with his.

Value Creation in Parallel with Value Capture

A key consideration through all this is that adding issues (along with other value-creation techniques) don’t replace value capture efforts.  They happen in parallel.  While raising other issues with the developer, I also expressed my view that his initial offer of a 70/30 split was too high.  I’m also addressing his implicit anchor and working on my BATNA by getting quotes from iOS development firms for a cash-only development deal.  Although I want my counterpart to be happy with our final deal, emphasizing value creation in no way means that I have to give anything away.  It just means that when we finally split up the figurative pile of money on the table, we’ve got as big a pile as possible.

No comments:

Post a Comment