Saturday, 26 October 2013

Flocations Pivot Analysis Parts I & II - Intro & Technology

Introduction - Part I
In 2011 a group of nerds came together with the goal of changing the paradigm of travel search. We wanted to release people from the burdens of your boring “search-by-destination” constraint of making a search that is so prevalent in sites like Expedia, Orbitz and every other online travel agency (OTA).

The logic behind pursuing this path was rather simple; leisure travel was more popular than business travel and leisure travelers made travel decisions differently.  They needed inspiration and choice to make their next trip decision. Of course your regular Expedia or Orbitz were never created for discovery. They were created for transactions.  They didn't give ideas, suggestions, allowed for social integration, or let you make the best choices and help you discover new places. Travel search was centered around "you know where to go, now here's a price".  Interfacing with travel search was all very...  transactional.

We decided to try to change that. We created the very first inception of It was a "visual based meta-search engine", as we liked to call it.  It had the power of but with an interface that was purely visual, with no loading screens, no search delay and above all else, fun to play with!
First version of

It worked something like this: instead of typing where you wanted to go (the old, traditional methodology), you only had a slider bar that controlled a budget.  The user simply adjusts his budget and the visual interface - a map - rearranged itself in real time to show you where your travel dollar can take you. It was a very neat idea and we received over USD 600,000 to develop the idea into a business. Six months later we pivoted the business. 

Whether it was inexperience with marketing the product, the business model, or technology, the product didn't really get off the ground.  I'm not quite sure which one it was but it might have been a combination of all of them - more exploration is needed to determine the culprit.

I'm going to go into each one of these aspects for my own edification and memory so it might be a good idea to post them here for other entrepreneurs to benefit!

Technology - Part II

Too Many Platforms

Flocations was a flight search engine with a google map interface as the overlay. If you look at google flights or kayak explorer or the skyscanner map, that's what we did. Except our results were actually real time meaning you could change your search variable, like price, and the map would change dynamically to show you results, no need for a loading screen. This created an extremely interactive way to discover and get prices for  travel search. It was actually a fun way to search for flights which is something no one has cracked yet. 

However this was built on several pieces of technology that unfortunately wasn't a fit for our target audience. 
Second Revision of Flocations

Using HTML5 and google maps together is actually quite resource intensive.  Furthermore, you needed a new browser such as chrome or Firefox to render the Flocations website.  We thought that this is fine.  We wanted people that are the savvy to use this new paradigm of travel and we developed strictly for them. Although our hypothesis was correct we didn't actually realize that habits were much different in real live.

You see, the majority of travel searches actually happen at work, during office hours. However, unlike your home PC equipped with the latest browser, enterprise browsers are sill running internet explorer 6 , 7, 8 and in rare cases, 9 or 10. Unfortunately these browsers either can't render HTML5 or they just do it very very poorly. 50% of our audience was using internet explorer and they were having massive problems when they tried to use Flocations, making Flocations unique value proposition of fluidity, quickness and beauty diluted.  
When Search Occurs

We thought fixing these problems and being backwards compatible for IE was a top priority, so of course, our tech team tried making everything backwards compatible.  However developing for IE and retrofitting the product was like having to develop for a completely new platform!  It took away from resources that could have been dedicated to actually improving the product or creating that targeted minimum viable product (MVP). We thought retrofitting the product would get us market share, which might have been true, but we hadn't even begun scratching the surface of the FireFox and Chrome market. This whole time, we should have been concentrating strictly on creating a breakthrough product for a chosen platform, not trying to retrofit a product that wasn't even proven.

It all seems obvious now, but at the time, it wasn't clear cut for us and funny enough, no one tried to stop us from developing for IE.  For a startup to concentrate on multiple platforms is pretty stupid.  We knew that we should concentrate on one platform and dominate it. However, we saw "Web" as one platform and being compatible with all browsers was a requirement.  I now understand that web as a platform, is a fallacy since the web is fragmented amongst many browsers.  We should have not even bothered for IE and just concentrated on FireFox and Chrome. Rookie mistake I suppose.   

That was technology mistake number one.  

Doing Too Many Things - Data and Content Gathering

The second problem with the technology was the availability of data or gathering content to put on your site. In our case, our content/data, was flight information.  How do we acquire flight information?

We were catering to a whimsical travel crowd, weekend warriors, explorers that wanted to get lost in new places, backpackers and so forth.  We decided that this market just wants to get there on low cost carriers.  So, we started aggregating budget airlines such as Tiger, Jetstar and AirAsia. Unfortunately, these carriers don't have APIs and we were left to invest in yet more development time to acquire our own data.  
Acquiring flight information is an extremely arduous task as low cost carrier prices change hourly. We always had to keep servers running and scraping to ensure prices were updated and correct. These became thousands of pages scraped hourly. In other words, resource intensive, expensive to maintain, and no robustness (it would break a lot). It was a problematic task from day one, but part of the Flocations unique value proposition (UVP) was that the product should be dynamic! In other words flight results should show in real time and therefore we needed that data on our servers so we could access it quickly. Going to a larger incumbent like Expedia and accessing their data was not an option for two reasons: 1.  They wouldn't let us cache 2. it was too slow to do an API call to get the data on-demand.  We decided we needed our own cached data for pure speed and to deliver our promise. 

Looking back on the decision to not use someone else's data, has been another rookie mistake. We were then running two businesses - new UI and data acquisition.  Even Skyscanner has a team of people managing flight data and we were trying to do it by ourselves.  Data acquisition was not our business, it was just a means to support our real business which was a visual flight search tool, a purely UI play.    

Technology Lessons Learned

In hindsight I would have done two things to correct the technology issues; 

1.  Know what platform you're building for - If 50% of your audience is on another platform and you're dedicating development resources to it, drop that platform altogether, concentrate on one platform and dominate it. If you're a startup, you don't develop for iOS and Android at the same time. You develop for one platform, find product/market fit and then port to another to grow. Unfortunately for us, we thought that the "web" was one platform so it was ingrained in our minds that we MUST develop for all browsers.  The reality is that the web as a platform is a fallacy and the real platforms are the browsers themselves.  Develop for one browser to find product/market fit, port/optimize to another to grow.

2.  Use someone else's content - Does whatever you’re building require content?  Does someone else have this content?  Is your main business to create content?  If it's not, use someone else's data.  "Borrow" it if you have to.  Our main business was not data acquisition like Kayak or Skyscanner. Our main business was a b2c visual product. We should have just used someone else's content to fill up our product and found a way around sticky licensing rules.  But we didn't, we decided to collect our own and spend tremendous resources doing it that could have been better placed on the main visual interface.  Hipmunk is the perfect example of concentrating on just UI. I only knew about Hipmunk a year after they launched. They were using Orbitz data exclusively which gave them the freedom to concentrate on their UVP, UI.  

Final words, simply concentrate on one platform and only work on your core business. If you're building things that are not part of your main business, replace them with something that someone else has already built, or cut them off! Remember, product/market fit as quickly as possible, even if it’s “frankenstined” together.  Once you hit product/market fit, then you will have funds to make it into something nice!

Next post: business model (soon to come).