Sell Where Your Customers Buy

Many marketing or business planning discussions eventually hit on the seemingly self-evident notion that you should "Sell What People Are Buying." (For a humorous discussion of this, see this blog) In addition to this basic truth, it is also important to "Sell Where Your Customers Buy." Think of the sidewalk entrepreneurs in New York City selling ice cold sodas or bottled water out of a cooler on the corner in lower Manhattan on a hot summer day. These vendors are able to charge a premium for a cold drink because they are right where the people are walking and thirsty - they are selling Where their customers want to buy.

For Information Providers, this truth is becoming very important. Not only is the Information industry moving heavily from a print to an all-digital delivery model, and not only are the roles of intermediaries and centralized procurement "locations" (such as corporate libraries) being diminished, and not only do Information Consumers have more choices and more access mechanisms than ever before, but in addition the easy access to information is changing the notion of information gathering from a stand alone task to simply one small (and hopefully automated) step within a larger process. Let me explain what I mean in a little more detail.

We all know that Print media is turning Digital. See the news stories about declining Newspaper readership, Amazon's (and BN's, and Border's, and...) push for digital books, the frequent discussion about the "Google Effect" on content providers, and the Open Access Initiative. The digital content is available on many platforms - the web, your mobile phone, smartphones, tablet computers, and e-readers. Information Consumers expect to be able to read the articles, analyze the data, and do their jobs on any of these devices, anytime during the day, on the train, in the airport, or wherever they are. This is what I mean by "Sell WHERE Your Customers Buy" - you need to be able to sell the article, or provide the data visualization, or the drill-down analysis on any device connected to the internet. If your valued, long-term Customer is sitting in the airport, curious about something she is not going to wait to get back to her office to use her subscription service to order a new report - she wants to download it to her phone, right now. If your service does not provide that, she will go to your competitor's app and get her Information right now. Your valued, long-term, trusted relationship goes right out the window because your Web 1.0 Information Delivery website cannot meet her expectation of instant information access.

The effect of this is to require every Information Provider to need an iPhone app. Well an iPhone app and an Android app. Oh, and an iPad app. And probably a Galaxy and Playbook app. And of course, a mobile friendly version of the web site. You can see, this quickly adds up.

Early attempts to create mobile apps usually involved creating a separate application stack, content collection, or Information Delivery Channel. This was the quickest, and least expensive approach to get the first mobile app out and does work. But the cost curve is not pretty, and you soon need to maintain and support 10 different applications, delivery channels, etc at 10x the cost for only marginal revenue increases.

The better approach is to build an API. Not just a dirty hack of a url that can be used to access content, but an actual, thought-out Service Oriented API that provides billing, metering, search, retrieval, and easy integration for apps. Now those 10 apps are just thin layers reusing the core SOA enterprise services and can be built and maintained cheaply. Better yet - if you have a loyal community who truly values your content, they will wind up building innovative apps on every platform you have never heard of to access and embed your content. This is because your customers are empowered to scratch their own itch, and build an application to solve their own personal or particular corporate need. And it turns out that a lot of times your customers know how to use your content better than your own product development team -- so the apps they build and the embedded data usage they put together are more useful to your customers than the pre-built website or stand alone applications you might design. Your customers become your distributors and open up entire new retail channels you were not even aware of.

So... you get more sales channels, at a cheaper delivery cost, with more customer value from enabling your content through an API. Sounds like a Win-Win-Win!

Data Visualization and Web 2.0

I love data visualization techniques. From my early days as a operations data analyst and all of my software development career, finding patterns in data and finding an easy way to convey the pattern through a graph or other visualization has always been fun. Working on custom application development projects that provided a picture of how the business was doing, where customers were spending, etc is fun. Now working with our Business Information Services clients to help create innovative approaches to information discovery and data analysis is fun. It really is true that often "a picture is worth 1,000 words."

I vividly recall a stubborn memory leak my team had been trying to track down for several weeks. This was a long time ago, in the days of VB6 COM dll's running inside ASP web pages, and we were pretty sure our code was not leaking. The team had found memory leaks before, and tracked every single one of them down to circular references in our COM object model so that the automatic release never occurred. Historically, it had been easy to find a leak by running a simple load script, executing each page thousands of time in isolation and watch to see which page shows the memory leak. But not this time. We had run the load tests several times and never found the leak. We scanned the code thoroughly. We added as many "set obj = nothing" safety lines as we could. But still the production web servers kept leaking memory, and we were forced to move the automatic restarts of the servers from weekly to daily and hope our band-aid would hold.

One day, I had some down time and decided to see if I could find a correlation between the memory used and what pages were invoked on the production system. An hour or two later, I had pulled all the IIS log files, gotten dumps of memory traces from the systems team and started my analysis. A bit of awk, grep, Access, and other quick and dirty processes later to pull out the data I wanted, adjust for timezones, aggregate hits to cumulative 15 minute buckets and otherwise line up the datasets and I was ready to plot the data.

Instantly, the answer of where the leak was was obvious. The two lines, cumulative hits to a particular URL and memory in use were nearly on top of each other. The correlation jumped out, completely overwhelming the noise of other URL's, pages, etc. This is the power of a good visualization. (Of course, it turned out that the leak was coming from a web services API proxy URL, not a page in the website that everyone had focused on! Since the proxy was not 'in' the website it had been ignored for weeks as the team hunted for the answer.)

Recently, some colleagues and i were discussing what areas Alliance Global Services provides solutions to clients in. This is a pretty broad topic, and we talked about the types of industries we serve (including our focus on Business Information Services), the geographies we serve (mostly North East US, from about Virginia to Boston), the types of services we provide (Custom Software Development,Application Architecture Analysis). And we talked about the easiest way to visualize our coverage areas.

Well, today I had a little downtime before the holidays. So I took a list of our client locations used some simple geocoding tools, and put together two quick samples of mapping in the Web 2.0 world - one using a Yahoo! map through batchgeocode.com and the other using the Google visualization API.

Batchgeocode.com made it very easy to process the first set of data and create a map but then you were stopped. Google was a different story - getting the map running required coding, but then I had full control. To see the first map, visit this blog on Alliance Global Services.

Obviously it's not perfect, but lots of fun for a quick afternoon's work!