Boo.com Goes Bust

As many of you may have heard already, Boo, the com­pany for which I used to work, has closed its doors.

I’ve been look­ing at the press cov­er­age and it seems that some of the cov­er­age does not work out. For starters, Boo.com’s fail­ure is not an exam­ple of why B2C E-commerce will fail, it’s an exam­ple of why Boo failed itself. Nor is it a fail­ure of E-commerce in Europe.

Now that the com­pany is buried, I’d like to take a look at what went right and what went wrong with the com­pany and go into more details as to what we should learn from that fail­ure. I will try to sum­ma­rize what I learned over the 6 months I spent there but I may be off a lit­tle here and there since it’s been a while since I’ve left the company.

Boo was the first com­pany to launch from the ground up in mul­ti­ple coun­tries from day one. This rep­re­sented a set of chal­lenges that were pre­vi­ously unadressed, rang­ing from tech­nol­ogy chal­lenges to more tra­di­tional issues in gen­er­at­ing a global brand. While I was work­ing for Boo, I was in charge of devel­op­ing the back-end ful­fill­ment sys­tem, a plat­form that allowed us to han­dle mul­ti­ple cur­ren­cies, mul­ti­ple lan­guages, on the fly tax cal­cu­la­tion, and inte­gra­tion with mul­ti­ple ful­fill­ment part­ners. Let me go into more details on what this means.

Mul­ti­ple currencies

If you want to trade glob­ally, you can’t only offer US dol­lars. As a result, you need to fig­ure out a way to han­dle mul­ti­ple cur­ren­cies rang­ing from dol­lars to pounds to liras to francs, to deut­shmarks, to kro­ners, etc… If you are plan­ning on doing this well, you have to peg your prices to a par­tic­u­lar value. How­ever, you have to real­ize that prices are not the same in every coun­try and what may seem expen­sive in the US can be seen as cheap in other coun­tries. This is where you have to make a deci­sion as to whether you want to set a fixed price in the local cur­rency or set a more dynamic price that is affected by cur­rency exchanges and other fluc­tu­a­tions. It’s a fas­ci­nat­ing prob­lem in and of itself but it’s one that we dis­cov­ered to be a big pain to deal with.

In the end, Boo built a sys­tem which allowed us to set a dif­fer­ent price for each coun­try or set a sin­gle price for all coun­tries and have that price be trans­lated in the proper cur­rency based on a set exchange rate. It was a bit of a kludge but it worked and, to this day, I haven’t seen an Ecom­merce shop with a sim­i­lar system.

LESSON:

When deal­ing across mul­ti­ple coun­tries, decide early on how you want to set up your pric­ing scheme, it will save you headaches down the road.

Mul­ti­ple languages

First of all, for­get trans­la­tion soft­ware pack­ages. They are still rel­a­tively imma­ture and there is (at this point any­way) lit­tle hope that they will mature much beyond their cur­rent point in the near future. If you’ve taken any lin­guis­tics course, you know that gram­mat­i­cal rules can hardly be stan­dard­ized for sev­eral lan­guages. For exam­ple, some­thing as sim­ple as a verb can become a whole new set of prob­lems. In Eng­lish, there is a rel­a­tively small set of basic rules. The verb “to want” breaks down into “I want, you want, he wants, we want, you want, they want”. Notice that there are only two basic vari­a­tions here. In French, the same verb “vouloir” breaks down as fol­lows: “Je veux, tu veux, il veut, nous voulons, vous voulez, ils veu­lent.” In this case, there are 5 dif­fer­ent vari­a­tions. In span­ish, it’s six… and so on. Take that prob­lem and try to auto­mate it and you are build­ing a sys­tem that is bound to fail. The way we worked around it at Boo was to cre­ate a sys­tem where the copy was trans­lated by hand by peo­ple who were flu­ent in the language.

Unfor­tu­nately, another prob­lem cropped up: British Eng­lish and Amer­i­can Eng­lish are EXTREMELY dif­fer­ent. Con­sid­er­ing that the assump­tion was that one ver­sion of each lan­guage was suf­fi­cient, prob­lems cropped up and some of the per­fectly nor­mal British eng­lish stuff ended up being very offen­sive in the US. THAT was a major problem.

LESSON:

One lan­guage per coun­try can be a dan­ger­ous road, check with the locals before mak­ing any­thing avail­able to the gen­eral public.

On the fly tax calculation

This one almost killed me. In the US, it’s rel­a­tively easy to deal with tax­a­tion. For the most part, the only taxes you have to pay are for states in which you have a phys­i­cal pres­ence. Where it gets tricky is when your servers are located in one area and your offices are in another. Tech­ni­cally, that is two locations.

In the case of Boo, it got worse. For exam­ple, a sale to France was taxed three ways. Why? Quite sim­ply because the com­pany had offices in Paris, its servers were located in Lon­don, UK and its dis­tri­b­u­tion cen­ter was in Cologne, Ger­many. How­ever, the inter­est­ing part of the prob­lem was that we were mak­ing a sale but not deliv­er­ing a good in the UK, deliv­er­ing a good but not mak­ing a sale in Ger­many, and mak­ing a sale and deliv­er­ing a good in France. This was just one exam­ple. Mul­ti­ply that by the num­ber of coun­tries the com­pany was doing busi­ness in and it soon got VERY com­pli­cated. Add to that the fact that cer­tain goods were com­ing from China or Tai­wan and the pic­ture got so clouded that we had to bring in tax attor­neys to help us on the details.

LESSON:

Hard to believe, but accoun­tants and tax attor­neys should be part of your devel­op­ment cycle if you are devel­op­ing global Ecom­merce apps.

Inte­gra­tion with mul­ti­ple ful­fill­ment partners

The main issue here was deal­ing with dif­fer­ent file for­mats for DeutscheP­ost (the Euro­pean ful­fill­ment com­pany) and UPS (the com­pany that did ful­fill­ment for the US). What we ended up doing was cre­ate an EDI link to those guys (DeutscheP­ost was not web-enabled yet) and cre­ate a set of fil­ters for each of them. A sim­ple answer to a sim­ple prob­lem but this lit­tle answer cost about 150 man months of work as the con­tent had to be migrated from the old (untagged) setup to the new one. Because the orig­i­nal data­base was orig­i­nally set up wrong, we had to totally reor­ga­nize the schema and refit the con­tent into it.

LESSON:

Plan early, think of all that can go wrong, and then plan it again. Usu­ally, spend­ing more time on specs saves you from many headaches down the road.

Where’s the plan?

When I joined the com­pany in August, the launch was behind sched­ule by three months and we had ten weeks to the Christ­mas sea­son. The first thing I asked to see what the project plan. It didn’t exist. Peo­ple were work­ing on bits and pieces of the project with­out com­mu­ni­cat­ing with other peo­ple they were affect­ing. Within a week, we put together a MS-project chart and things started to move properly.

LESSON:

An e-commerce project with­out a devel­op­ment plan will always be “this close” to launch but will never launch.

Front end is technology

One of the biggest fail­ures at Boo was to assume that the front end was not a tech­nol­ogy issue. Up through launch and beyond, the front end team was first report­ing to busi­ness devel­op­ment and then to mar­ket­ing. This was a cap­i­tal mis­take that I kept fight­ing over. A web site front-end is inter­face design, it’s not a mar­ket­ing exer­cise. It should include peo­ple who are versed in this and not just peo­ple who know about pretty col­ors. Ulti­mately, I think this was one of the big fail­ure fac­tor in the company.

LESSON:

No mat­ter how good your back­end sys­tems are, the users will only remem­ber your front end. Fail there and you will fail, period.

There are many other rea­sons for which Boo failed (I’d rather not go into them but I can say that the press is on the mark on a lot of their accu­sa­tions) but ulti­mately, there were a lot of really smart and really good peo­ple there who worked very hard to put together what, to my mind, was an amaz­ing back-end oper­a­tion. Lack of com­mu­ni­ca­tions to and from the top was def­i­nitely a prob­lem as well as a lack of under­stand­ing of Inter­net time (the redesign of the site I heard about on the day after launch has not yet hap­pened and prob­a­bly never will now). In the end, though, Boo’s fail­ure was not that unex­pected to any­one who had worked for or with the com­pany. Boo.com did not fail as an Ecom­merce com­pany, it failed as a com­pany, period. The thing that took it down were not Ecom­merce related as much as they were just plain busi­ness. Yes, I’m a bit sad­dened by the fact the com­pany went down­hill but I already knew this was going to be the out­come back in Jan­u­ary when I left.

Ulti­mately, Boo is a typ­i­cal exam­ple of a les­son that many VCs are push­ing these days: Man­age­ment makes or break a company.

Let’s hope we all take that les­son, remem­ber it, and let Boo stand as old mis­takes we will never make either again (for those of us who made them) or at all (for those who haven’t).

Related Terms

More in Analysis,Business,Technology (5 of 5 articles)