Necessary and Sufficient

Bernie Madoff perpetrated the biggest Ponzi scheme in history. It's estimated that 65 Billion USD of his clients' money has disappeared. In the media many analysts have talked about how secretive he was with his "secret sauce". In the past people suspected his miraculously consistent returns were due to his market maker operations employing "front running" trades. This involves placing advantageous trades just prior to execution of other big trades that the firm sees coming in. In hindsight that has turned out not to be the case - it was a straight out Ponzi scheme running clandestinely next to his market making operation. But it has been reported that Madoff did say his returns were the product of a split-strike conversion investment model. So what exactly is that? After a bit of digging around I think I can offer a non-expert opinion of how that works...

First some basics. In options trading a simple "buy and write" strategy involves buying a stock (the "buy" part), and writing an out-of-the-money covered call (the "write part"), meaning the strike price of the option is greater than the current buy price of the stock. Since you are writing the call you collect the premium up front. If the stock price doesn't move you won't be exercised - the options you sold expire worthless - and you keep the option premium. If the stock goes up by an appropriate amount you will get exercised so you deliver the stock you already bought, hence the name "covered call", but you still keep the option premium. If the stock goes down, again you're not going to get exercised on the written call, but you still keep the option premium. Of course the value of the long position you are holding is going to reduce but this loss is cushioned by the premium earned on the option. In summary, you profit if the stock price increases but this profit is capped by the option premium + the difference between the purchased stock price and the option strike. If the stock goes down your loss will be offset by the premium collected, so overall the buy-and-write outperforms a strategy that merely involved buying the stock, unless of course the stock price goes above the said (initially out-of-the-money) option strike price. [For simplicity this analysis ignores transaction costs.]

Taking this one step further. If you use the proceeds of the written call to buy an out-of-the-money put option, sometimes referred to as a protective put, this strategy is then termed a “collar” or a split-strike conversion. Purchasing an out-of-the-money put gives you the right but not the obligation to sell the stock at the predetermined strike price on or before the expiry date, thus you are protected from large downward moves. So now let's consider the pay-off matrix for such a strategy by examining the differences between this and the above buy-and-write strategy. In effect the upside profit is still present but the unlimited downside we had with the buy-and-write has now been limited to the strike price of the purchased put option. Thus a collar protects you from massive losses but it also prevents massive gains.

So now you know. The split-strike conversion strategy that Madoff claimed to be his secret sauce is just a trade that consists of a long equity position plus a long put and a short call. It's not a bad strategy, but it's obvious to everyone that it cannot produce positive results when markets go down which begs the question why he would offer such a strategy to fund managers who would know that?

If you want see empirical evidence that it is not possible to produce such consistently good returns with this strategy go read this paper.

Usability experts often espouse many cardinal rules such as:

• People hate filling in forms.
• People don't read long bits of text you put on the screen or in an email.
• People don't like to give you all their personal details just to try your service.
• People don't like to download something just to be able to try your service.
• People don't like too many choices.
• People prefer a pricing structure that is easy to understand.

They say that all of the above are barriers to entry and sources of user confusion that you need to eliminate. Perhaps these are true but you might want to get some data before making bet bets on them.

But some things are just damn obvious:

Data entry of URLs on a regular phone keyboard is a major pain.

For English, you have to press a key up to 4 times to get the letter you want, and rather than place the more popular characters in position 1 on each key they went with a simple alphabetical listing so you need multiple key presses more often than not (see Text Message Outrage problem to solve this). The damn keys are so small you can easily hit 3 different ones with "fat thumb syndrome". As well, URLs always contain some non-alphanumeric codes. "http://www.necessaryandsufficient.net" has a colon, 2 periods, and 2 forward slashes. Granted, advanced users will know that they can omit the "http://www." prefix assuming the website operator knows what they are doing with DNS, but it's still likely that there will be a forward slash in the URL which almost always requires shifting to an alternate character display.

These aren't new problem so companies have tried to address the problem with several innovations but many of them fall short:.

Predictive text and auto-complete are based on language dictionaries which don't contain trade names so unfortunately that isn't much help to you.

Voice recognition is a promising technology but it hasn't quite got their yet,

On-screen digital keyboards like that found on the iPhone and HTC Magic have error-correction algorithms so you don't ever hit 2 or more keys at once, but that still doesn't help with a lengthy URLs.

But there are 2 innovations that are really useful:

URL shortening services like tinyurl and bit.ly help website operators transform longer URLs into much shorter URLs. Mobile browsers will certainly appreciate that, and it uses fewer precious characters if you use an SMS-based distribution service like Twitter. Here's my bit.ly URL:

http://bit.ly/HEX8I

The other nifty innovation is QR codes. I've seen these at conferences, on billboards, in department stores, in magazines and on price tags. Essentially they are 2-dimensional bar codes that encode some information like a URL. The idea is, the mobile surfer uses the camera on their phone to take a picture of the bar code. Some software on the phone converts the image to the textual string that represents the URL and pops open the phones web browser at the specified URL. So all the user had to do was to take a photo - no data entry needed at all!

If you have an Android phone, like I do, grab the zxing application from the Appstore, fire it up, and put the cross-hairs on the bar code above. Within seconds it should acquire and give you the decoded text with some options. The iPhone has similar apps but the camera quality on the iPhone isn't great so you'll need to be closer to the qr-code.

QR-codes can contain 4000 odd alphanumeric characters which is more than enough for URLs, and they are royalty-free even though they are patented by the Japanese corporation, Denso Wave. The magic behind it involves Reed-Solomon error correction which is the same technology used by your DVD player. [That reminds me of a crypto scheme I had to implement a while ago called Shamir Shared Secret but more on that another time].

So the message is clear. If you want to be kind to your mobile users give them qr-codes to photograph
or at the very least give them a shortened URL to minimise data entry and maximise their ability the remember it!

Bringing a new product or service to market is like raising a child. You can get all the advice in the world, and know all the theories and best practices beforehand but it's only going to get you so far. There's no unilateral, all-revealing formula for success. Perhaps more valuable is first-hand experience and battle scars about what works in certain circumstances and what doesn't. You might have a different perspective on these things - that's fine - but I thought it was time to jot down some lessons I've learnt, and some things I've picked up from others for future reference. Some people might call this advice common sense, others might term it user-driven development, some will classify it as user experience optimisation (UXO), yet others might call it product management. Whatever you want to call it, it makes sense.

1. You need your users! They are the only reason you built the application/service.

   So don't treat them like garbage!

2. Your users are not technical experts.

   So don't assume they are. Sure, there may be small percentage of experts in your userbase but target the majority before the minority. 

3. Your users might not care to learn 5 different ways to do something in your app.

   Don't put huge amounts of effort into the "expert mode". 

4. Your users might have radically different opinions about the quality of the app than you do.

   Swallow your pride/ego and listen to them! Find out what their pain points are and address them. You obviously can't please everyone, and you might not have the data you really need so some judgement comes into play here

5. Your users may not use your app as expected.

   Observe their behaviour and adapt accordingly!

6. Your users may not be as motivated as you are to use the application.

   So don't build a UI that gets in their way and forces them up a learning curve that they have no chance of getting an ROI on.

7. Your users may prioritise features radically different to what you expected.

   The developers of GMail thought the delete button was unnecessary but their users didn't. The rationale the Google PMs used was sound - why do you need to delete when you have tons of free storage - but Google listened to their users and put the button back in because the users demanded it.

8. Your user may not be as passionate about your application as you are.

   Sure, you can have an animated paperclip overlay coming to life and speaking to the user in any one of 5 different languages after they've caused a form validation error but does the user really need that, or is your dev/UX team just trying to get new technology XYZ onto their resume? The user just wants to get round the issue ASAP and get on with their activity. Keep "Microsoft clippy" and "Vista UAC" in mind when you do your Kano model.

9. Your users may not care to tell you what sucks about your application.

   So take the issue into your own hands by doing anything and everything from "hallway usability tests", to organised user experiments. Waiting for people to come to you with negative feedback is just putting your head in the sand waiting to be hit by a runaway hummer. Hint: waiting to do usability test until the product is finally built is a certain route to wasted cycles.

10. Intuition is regularly wrong. Let data drive decisions.

It was Lord Kelvin who said "If you cannot measure it, you cannot improve it." And he was right.

To finish allow me to quote from Geoffrey Moore, author of Crossing the Chasm:

"The mass market comprises the pragmatists, those who just want the damn thing to work."