Tuesday 8 April 2008

There is a lesson in here if you look closely...

We had a tough weekend but if we take the right things away from it then it will be one of the cheapest lessons we could pay for...

A while back we launched a new product; starting price.  The concept is pretty simple and analogous to it's parent product (the sports exchange) where for every event backers are matched against layers.  In the case of starting price bets, we are matching starting price backers (who have specified a stake) and exchange backers with starting price layers (who have specified a liability) and exchange layers.  So just like traditional SP but with our unique peer-to-peer slant on it.  There is one more big benefit I like, SP lets you set a persistent bet at the beginning of an market which stays open once the market goes in-play (these used to be voided) which is big for us because that can be tens of thousands of potential matches depending on the event.

So what went wrong?  Depends who you ask.  Let's say I ask my monitoring systems - nothing.  How about my sysadmins - nothing.  Intrusion detection - nothing.  If I ask my developers, testers, mathematician - still nothing.  Anecdotally (the currency of monitoring) I can say nothing went wrong at all yet I am still not happy.  By "I" I really mean the business and the business wasn't happy because our SP was being calculated at around 50% of the industry benchmark - on the one hand if that's the true market value then that's the true market value but on the other hand it just isn't how we'd planned that the product would perform.

So here is what I think went wrong - we built a sunny day system.  Product managers will always write specs based on what they want to happen, the journey they have planned for their users.  They'll hardly ever write about what they don't want to happen or think about an alternative journey a user might take through the system.  It is just as important to think about what else people might do, through legitimate or malicious use, with your functionality - if the only input to your design is the desired behavior then you're doomed (unless you are unfeasibly lucky).  On top of all this you should also add common failure scenarios and some sensible behavior under exceptions and variable performance (latency, disk space etc).

What was our newbie mistake?  Most people that are new to a trading system back only and it takes them a long time to build up the courage to try some lay betting.  Good old fashioned assumption; "people will use SP to back and lay" rather than "most people will use SP to back only" and I can't help thinking that had we considered this simple piece of human behavior (that we considered undesirable) we could have built in some rule - min and max thresholds or distance from trend etc.

That's software in the real world.

No comments: