Entrepreneurship

What Do You Do When Your Market Disappears?

In these turbulent times of COVID-19, my good friend Charlie Paparelli has been hosting a weekly Zoom meeting for entrepreneurs interested in discussing our “new normal.” This week’s topic, which I absolutely stole for this article’s title, was “What do you do when your market disappears?

I feel very blessed that Rocket Partners’ business has been going strong these last six months. We are continuing to build new innovative solutions for our fantastic clients. In fact, most of our recent work has shifted to building new revenue generating digital experiences to help our clients adapt to their new COVID-19 induced competitive landscape.

That said, in previous tech cycles, I have found myself exactly in the predicament of having my market disappear. Below, you can find what I believe were four costly mistakes I made that all entrepreneurs in this situation need to avoid.

I started my first company, Synthis Corporation, in late 1999. At that time, we were a consultancy specializing in helping dot-coms build their tech platforms. After 9/11, all residual dot-com consulting evaporated. Market #1 gone. I had a great team of five committed partners, a bench of expensive consultants, a list of great clients who were now all out of business, and a portfolio of software tools and IP that we had been developing as part of our consulting practice. As I have written about here before, my partners and I decided to pivot out services and commercialize our IP as a suite of software development tools.

A year or two later, the software development tools market dramatically changed with large vendors like IBM starting to give away their tool sets to support the sales of application software and consulting work. Market #2 gone.

Again, we looked around for a new market and decided to shift our IP to target the ISO-9000 and the new Sarbanes Oxley (SOX) compliance markets. It turns out the SOX market never really developed the way we had hoped. Large accounting companies threw bodies and billable hours at the challenges created by the new laws and were not interested in labor saving software. Market #3 gone.

Looking back at Synthis’ journey, I can absolutely tell you that we NEVER should have left consulting. The consulting market came back strong within 18-24 months, and my partner (down to 1 partner at this point) and I spent five years trying to commercialize a software product that was more of a technology trying to find a problem, instead of trying to identify a problem and building the business to solve that problem. We were broke for five years anyway, so we should have stayed the course in a market that we knew with a validated problem, where we already had customers, success stories, contacts, etc.

So why did we do all of these pivots? Why not stay the course or cut your losses? After time and age, I realize at least four errors in judgement on my part.

  1. I was in love with the tech framework that I had built as a consultant and did not want to abandon it. There was no way for me to be objective about its marketability.
  2. We were in love with being our own bosses, and we simply had no idea what we were going to do next, personally, if we shut the company down. The result was some fear-based momentum.
  3. We had a damaging bias towards action. We did not want to simply hunker down and bide our time or feel like we were trying to squeeze blood from a stone. We wanted to feel like we were doing something productive. As my good friend Evan LaPointe @ CORE has written, coached, and tweeted about numerous times, a bias towards action needs to be eliminated from strategic thinking. As he put it to me recently “The time to step back and use the brain to think rather than the muscles to act can save a lot of pain. Same goes for bar fights.”
  4. After our first product market disappeared, we were not objective about treating our existing investments (both personal time and money, as well as investor dollars) as sunk costs. We had to squint really hard to make new markets look like they needed our tech. That was a huge mistake.

Having coached many tech entrepreneurs and been an entrepreneur for my entire career, I can tell you that people seem to irrationally love a good pivot story. Early-stage entrepreneurs, especially, are praised for refining their offering and steering towards hopefully greener pastures. From my personal experience, however, a pivot can be an extremely expensive proposition that is unavoidably fraught with conflicts of interest. I think that, in the long run, many entrepreneurs would be better off hunkering down and waiting for their market to return or simply closing up shop, walking away, clearing their head, and finding a new opportunity to fall in love with.

Technology

The Usual Suspects of Poor App Performance


tl:dr Diagnosing poor application performance is an art and a science.  Below you will find my  personal short list of common causes of poor app/site/API performance compiled over decades of late nights debugging sessions and too much coffee. 

In the summer of ’97, I got my first real exposure to what it takes to build fast, high-scale web apps as a junior developer on IBM’s cyber cast team for the US Open Tennis Tournament. I spent weeks painstakingly developing beautifully manicured cross-browser-compatible HTML templates for just about every page of the site, including a bunch of hellacious nested table layouts for the marquee real-time box-scoring feature. Boy, was I proud of my code! When we landed in NYC for the three weeks of the tournament, I still had no idea how much I was about to learn.

One of the first on-site team members I met was a guy named Nick who had an IBM Power PC laptop running AIX. That was some pretty rarified nerd gear back then and I immediately wanted one. Nick was part of the IBM team building the web hosting infrastructure for the 1998 Nagano Winter Olympics; he was there to use the US Open as a testing platform to see just how far they could scale traffic before the infrastructure and thus the user experience started to break down. 

Nick and team had a super-cool trick. Remember those HTML layouts I made for real-time box scores? Well, on low-traffic tournament mornings, these guys would incrementally dial up the HTML refresh rate on the scores pages and use the web browsers of hundreds of thousands of unsuspecting tennis fans around the world to generate a nearly unlimited volume of concurrent requests. They were setting new internet traffic records every day; it was incredible. “The Slashdot Effect” was already popular nerd parlance, but I don’t think the term “denial of service attack” had even been coined yet. 

So, what does this have to do with my prized HTML? Shortly after setting up our on-site office/war room, Nick called me over to show me something on his badass laptop he was super-excited about. He’d written a script to strip out all of the whitespace from every HTML page I’d authored, reducing the page byte size considerably. I was horrified; my beautifully indented layouts had been mutilated. Smiling, he said. “It’s like I always say, save 30% of your homepage size and add 30% more users.” Fortunately, my 21-year-old wounded ego kept its mouth shut long enough for me to learn a valuable lesson… At least, that’s how I choose to remember it.

And that was the start of a career that’s often involved diving headfirst into performance and scalability problems. While NO-SQL internet-scale databases and hyper-scale cloud platforms have banished many of yesterday’s problems, so much of the investigation game is the same. It seems that as our stacks’ capabilities have grown, they’ve introduced their own sets of nuances that often capture the most mind share when breaking down a problem. We need to remember to double-check the basics. Here’s my list of slow apps “usual suspects”—as relevant today as back in 1997—plus some new items courtesy of today’s fabulously updated tech.  

The Usual Suspects of Poor App Performance

Job #1 is to determine if your app server request processing time is actually slow or if one or more client-side inefficiencies are creating a perception of slowness. The answer will probably be both, but go for the biggest wins first.

Optimize for first meaningful paint

  • Poorly structured CSS/JSON can force all page assets to load before the first meaningful rendering in the browser, making it look like the entire page is slow.  
  • Tools built into Google Chrome, such as Lighthouse, give you x-ray vision into this type of problem.

Unnecessarily large payloads

  • Minify your HTML/CSS/JavaScript.
  • Use media queries, img srcset, and other responsive techniques to load the appropriately sized images for your client device—e.g., don’t load desktop images on mobile devices, even though your code may autoscale it and it looks right: it is a huge waste of bandwidth and time. There are plenty of tools out there that will automatically resize your images and cache them in a CDN for you.

Too many assets / connections

  • Concatenate your JavaScript and CSS each into their own single minified file to reduce the number of requests required to render your first page.  
  • Consider embedding your CSS and JavaScript directly into your HTML instead of linking to it.
  • If your design uses a large number of small rastered icons/images, consider using CSS sprites.

Poor use of HTTP caching headers

  • Most modern CMS platforms (WordPress, etc.) are pretty good at setting generically appropriate cache-control and eTag headers on static assets so browsers don’t continually try to reload them. It is always a good idea to double-check these settings, especially if your custom logic ends up serving static content.

Too many database queries

  • If you are running hundreds of queries to generate a page (an easy thing to do with something like WordPress and WooCommerces plus additional plugins), there is almost no way to make the site perform and scale.    
  • Even for highly dynamic sites, the majority of the dynamic content does not actually change from request to request.  
  • If possible, extract any personalized content into AJAX calls so the dynamic content on the core page can be cached on the server side for future requests.

Lack of a CDN

  • CloudFlare—enough said. OK, we like CloudFront too if you are native AWS, but CloudFlare’s free CDN is basically impossible to beat.
  • For all third-party JS libs, fonts, etc. that you’re not going to embed in your code, make sure you link to their CDN sources.

SSL offloading

  • SSL still takes a lot of compute resources. SSL offloading moves the SSL termination off of the servers that are processing your business logic and moves it to a load balancer or some other type of proxy. If your requests are slow but your app server CPU is not maxed this is still a best practice, but is probably not the culprit. 

Undersized app server worker thread pool

  • If you are working on a platform like Java/Spring Boot, when moving from development to production it can be really easy to overlook prod configurations such as the number of work threads of the JVM memory allocation. If your worker thread pool is undersized compared to CPU resources, you could be artificially forcing requests to queue up while CPU cycles go underutilized.

Cold starts for serverless functions

  • Serverless deployments with AWS Lambda, Azure Functions, and the like can be awesome, but you have to pay attention to potential “cold start” times that are the straight up overhead of the cloud infrastructure. If you are running in a serverless environment and are seeing inconsistencies in response times, particularly if your traffic is naturally bursty, you may want to check to see if your longer response times correlate to launching new serverless runtimes. If your traffic is consistently slow across the board, this could be a contributing factor, but is probably not the main culprit.  

Running your app logic and database on the same server

  • It feels like this should not even make the list anymore, given that separating these functions has been a best practice for over 20 years, but amazingly we still run across legacy apps with this configuration all the time.  

Mismatch between database compute and IOPs

  • For cloud databases in AWS, Azure, and other clouds, you can dial in exactly how much CPU and IOPs you want. In a cloud context, your IOPs limit the number of disk reads/writes your db can perform. If your CPU is not maxed out but your queries are slow even though they are appropriately indexed, there’s a good chance your IOP allocation is maxed. It’s the cloud equivalent of having super-fast CPUs and super slow disk drives.  

Undersized database connection pool

  • This is another deployment configuration that is easy to overlook. If your individual queries are executing quickly according to the slow query log but the round-trip time seems to be taking a long time in your code, your logic thread may be blocking waiting for a connection. Double-check that you have a reasonable number of connections compared to the number of server worker threads.

Missing DB indexes

  • When you have identified specific slow pages or API calls, if they are connecting to a relational database, make sure that your table indexes cover all of your query patterns. 
  • While NoSQL databases can really help eliminate RDBMS scalability problems, almost all of them have their own partitioning or indexing strategies that you must pay attention to. You can still end up doing the equivalent of full table scans in DBs such as Azure ComosDB and AWS DynamoDB. That will KILL performance… and probably your budget, too.

Hot NoSQL partitions

  • Often a companion to many NoSQL indexing strategies is a partition strategy. Poorly designed partition keys can result in “hot partitions” that receive an oversized position of the request traffic, causing those queries to slow down. Make sure your key strategy matches your data access patterns in a way that maximizes the spread of requests across partitions.

So, these are some of my “usual suspects,” the list of easily recognizable problems that may contribute to poor app/site/API performance. I would love to hear what’s on your list!

If you are having trouble with slow applications or struggling to scale up, contact us. We would love to see if we can help.  

Entrepreneurship

Inversion – An Antidote to the Ordinary

A message to my amazing Rocket Partners team…

From a technical perspective, I will be the first to admit that the demands of our clients don’t always make sense. Our clients, after all, are usually not rational nerds. They are humans.  While we battle code, they battle budgets and politics in one of the most complex, inefficient, perilous social structures humanity has ever created: corporate America.

When we are faced with the daunting and illogical, it can be easy to become callous. When today’s requirements feel unsatisfiable, we can easily lose touch with the long-term vision of what it means to provide our clients with world-class service. We will never do that.

Yesterday, I received notification from our IP attorneys that one of our trademark applications for our Open Source Inversion API Engine had been approved by the USPTO. You may have noticed it in the Inversion README or in the banner on bootup. “Create More. Code Less.”

To me, “Create More. Code Less.” is not just a hopefully catchy slogan. It is an antidote to the ordinary. It is an organizing principle. It is a vision. It is my mission for Rocket Partners and the theme that I want to underlie the amazing work each of you does for our clients every day.

Some of today’s pundits say that you should not worry about your application architecture because the people who come after you will not invest in understanding it and will work around it no matter what. On somewhat the opposite end of the spectrum, Larry Ellison, of Oracle fame, is often quoted as saying that it takes 10 years to build good software. Experience has taught me that there is truth in both of these positions. What I know for sure is that the solutions we build for our clients today will be in production FAR longer than you might think. I expect a Rocket Partners solution to adapt gracefully to new requirements and future generations of developers, consultants, and client stakeholders. This means we must always consider what lies beyond the immediacy of a specific requirement.

This message is a mandate to each of you to always consider, explore, discuss, and challenge why and how we deliver value to our clients. Helping each other to discover, invent, and deliver excellence in software consulting is our collective job. 

Entrepreneurship

The Long “Pivot” Home

My first experience with the word “pivot” was a fateful one. It was 2001, the bubble had burst and the writing was on the wall. I had founded a dot com consulting company two years earlier and we were running out of cash fast. I can vividly recall a late night sitting on the floor huddled in the corner of our office with my partners and deciding that we were going to change course and invest the last of our money in productizing some of the intellectual property that had sprung out of our consulting practice. Just like that, without any real understating of consequences I left the world of technology consulting for the world of software products.

From Synthis to LIFT Retail to Verifone, I spent the next 14 years, pivoting many more times, but always building products. Finally, I knew in my gut I was a square peg in a round hole and I left Verifone in 2015 thinking that it was time to get back to my next software product startup.

Rather dishearteningly, my startup ideas quickly lost their appeal. After spending some time soul searching, I decided to start Rocket Partners as a digital marketing agency helping people optimize online ad campaigns.  I had an ad tech background, knew how to leverage technology as a differentiator and thought outsourced SEO/SEM work was going to be my fast path to positive cash flow.

I think one of the interesting things about getting older is that it seems to be getting harder to fool myself and it is definitely harder to fool the people who know me. As soon as I hung out my Rocket Partners shingle, my network started bringing me interesting software development consulting opportunities. I fought it. I told myself I wanted to work on a business not work in a business and that I should stay the digital marketing course.  The evidence was compelling. I was miserable in the SEO/SEM world but loved building custom software and had a waiting pipeline of projects. 

After 15+ years of pivots, it was time for one more. A pivot back home to where the journey began to where I had fallen in love with technology and customer service. I embraced my “why” with a hard won understanding that my “why” is to help other people figure out their “how.”  

Two years in, the Rocket Partners team has grown to include world class cloud architects and software developers. Happily, we have been so busy working for a growing stable of amazing clients that we have not had time to change our website or tell the world what it is that we are actually passionate about.

So here it is – Rocket Partners is an enterprise cloud consultancy based in Atlanta and Denver. We are passionate about solving complex technology challenges for our clients and the power of the cloud to accelerate creative solutions. Rocket Partners cloud experts help companies launch and love their big ideas. 

If you are interested in moving your critical IT assets to the cloud for the first time or if you just want a fresh look at your architecture and spend, get in touch. I would love to see if Rocket Partners can help you next year.

Entrepreneurship

Manage by Leading Measures to Achieve your Wildy Important Goals

If you have ever struggled to get a high-performing team to achieve what everyone believes is a top priority, I highly recommend you read The 4 Disciplines of Execution (4DX).

If you are like me, after reading the first few pages, you will think, “Of course!”  Here it is in a nutshell:

  • Achieving your wildly important goals (WIGs) is difficult primarily because people get lost in the whirlwind of their everyday jobs.
  • Your team can only focus on one or two WIGs at a time (think one or two a year).
  • Define your one or two WIGs with lagging measures, e.g., “Increase profits from X-Y by Z date.”
  • Hold your team accountable to leading measures, e.g., “Make 10 new sales calls each day.”
  • Create a regular cadence of accountability in which team members report on their leading measures.
  • Keep a compelling scoreboard that tracks leading and lagging measures.

To me, the difference in measuring and acting on leading vs. lagging measures is the insight here. The leading measures you choose must be highly correlated to achieving your lagging measures, and they must be something your team knows they can execute on today. Think of the old sales adage “calls + presentations = sales.” If you are just measuring sales, you are always looking in the rearview mirror. When you track calls and presentations, your team knows what game they are playing, they know what to do right now, and you have a good understanding of where you will end up with your trailing WIG measure. To be clear, 4DX is not just about growing sales; it is about helping you achieve the WIGs you choose.

In one of my “big company” positions, a new CEO regime tried desperately to institute a scorecard system for everyone in a leadership role. Each month, top executives and their lieutenants spent a week or more preparing exhaustive PowerPoint decks detailing dozens of key initiatives with red, yellow, or green status indicators. After reading 4DX, it is obvious why this system failed and company performance suffered miserably. When everything is important nothing is important, and the only measurements individuals were held accountable for were lagging measures.

I can think of a few occasions when action and accountability against leading measures were intentionally used and very effective. In 2013, my team was responsible for a growing network of digital advertising devices deployed in retail stores around the country. Ads were targeted at shoppers, but cashiers were responsible for interacting with the device, so they were our primary “users.” We had a major problem with cashier engagement. They did not seem to trust the device enough to spend time and effort on using it. We had tons of data, but it was really hard to tell when cashiers believed the device failed to meet their expectations, resulting in a loss of confidence.

Our WIG became “improving cashier engagement.” The leading measure we adopted focused on decreasing the number of merchandise bar codes that our device did not recognize or act on. At that time, we had a daily standup, and we focused the end segment on what we called “making a difference.” Each team member was responsible for reporting on how they moved the needle of unknown bar codes. It was not long before people saw the compound effect start to take hold, and engagement from my team and our cashiers shot through the roof. In retrospect, I got lucky in that situation.

4DX will arm you with a simple but effective vocabulary and methodology. I challenge you to read it and NOT immediately identify where you were trying to lead through an exclusive focus on lagging measure accountability when you should have been focused on leading measure accountability.

Entrepreneurship

Hostages to the Grind

My good friend Charlie Paparelli recently posted to his awesome entrepreneurship blog, Life Imbalance Is Essential to Birth a Company.

My two startups definitely took an outsized effort to birth. When selling my second startup, the night of the closing my wife called at 9:00 PM to tell me that we had to go the hospital to delivery my daughter. I brought my laptop so that I could “press the button” at 7:00 AM to convert the branding on our website as part of a coordinated PR announcement. Luckily it was a false alarm and Margaret was born peacefully nine days later with a fully focused father. She was sweet and understanding even before she was born.

Being on the mentor side of startups right now, I often see entrepreneurs who feel like they are not doing their job if they are not what I call “hostages to the grind”. This blind belief often creates the patently false hope that “if I am grinding it out I must be making progress.” Wrong. You are not starting a company to work hard. You are working hard to get results.

This may seem obvious but many entrepreneurs don’t realize that their toil may be masking incorrect product market fit, bad strategy, poor delegation, or poor team makeup. They think that a startup must be super hard so they don’t question the weight of the effort soon enough. Of all of these, I think understanding and admitting poor product market fit is the hardest for many entrepreneurs. You are always going to grind for sub par results when product market fit is off. When product market fit is right, you are working hard just to hang on.

With rare exceptions, a startup is going to be nearly all consuming. Good leaders need to keep enough brain power and emotional energy in reserve to honestly and continually evaluate the difference between the unavoidable work that is part of the journey and inefficient grinding that should be signaling you to underlying problems in your business.

Entrepreneurship

Delaying Employee Equity Agreements is Bad Business

As leaders we must make sure we are not taking unfair advantage of the trust and faith people put in us.

Yesterday I heard a troubling story about a high-potential Atlanta startup. The CEO had created a situation where equity agreements for key executives had been left to a handshake deal for far too long. This situation should have been easy to resolve but had started causing significant problems.

My first reaction was something like, “Boy, I’m glad that would never happen at an ATDC company. They all know better.”

After thinking about it a bit more, I remembered all of the struggles I had with equity and operating agreement terms when I started my first company. I only avoided countless major mistakes because I got experienced advice along the way. In truth, it’s easy for even the best-intentioned leaders to let bad decisions creep along while they focus on what feels like more urgent needs.

When I started my first company, I had two co-founders. We eventually brought on three more folks with high-equity positions. Every time we brought on someone new, we all battled for hours over where the equity would come from. Bringing on new team members should be seen as an additive proposition, but it can be darn near impossible to get around the emotional gut wrench of seeing your own paper percentage share decline. Of the six major shareholders, only two stayed with the company until the exit. If we had not had a strong operating agreement, a thoughtful divesting schedule for departed founders, and completely buttoned-up paperwork, we might have just folded. Some cap table sins, you can’t recover from.

At my most recent startup, I had three other co-founders. Again, we did not all make it to the exit, but we all knew the ground rules from the start because they were spelled out in black and white and signed in blue ink.

I can think of no greater responsibility as a leader than to make sure we are not taking unfair advantage of the trust and faith people put in us. It is a CEO’s responsibility to never put the company or employee in an ambiguous situation when it comes to compensation and fair play.

Every second you leave equity undefined, you are fostering a breeding ground for divergent self-entitlement and conflicts of interest. You are unwittingly treading somewhere between very bad management, in the best case, and, at worst, morally bankrupt leadership.

Equity loose ends communicate that you either don’t trust your own abilities and valuation, don’t trust the future contributions of your partners or employees, or straight up want to wait to get discounted labor and a better strong-arm deal for yourself down the road. I’m not saying that is what you are trying to do. I’m saying that is what delayed equity deals signal to others. Instead, be a clear, inspiring leader who creates trust by letting everyone know where they stand at all times.

 

Entrepreneurship

Customer Churn and Tootsie Pops

The other day, I was working with an entrepreneur who seems to have everything going for him. He has a growing customer base, happy investors, and plenty of runway.

When we started talking about various challenges and opportunities, he mentioned that although he launched over a year ago, he still did not feel like he had proven the “sticky” value of the product. This was a mature observation that showed real product management chops.

Imagine for a second that your high-tech piece of awesomeness is actually a simple piece of candy. When customers chew your product up, does its delicious flavor quickly fade like a stick of Juicy Fruit gum? Hopefully, you are more like a Tootsie Pop, which keeps customers engaged in the long run and makes you keep finding new reasons to love it (apologies to those readers who have forgotten their candy-eating childhood).

Many products are super slick, but for one reason or another, they just don’t keep users or buyers engaged. Many times, products that don’t demo well become invaluable, continuing to surprise and delight customers long after the sales team has gone home.

Excellent user experience design is like camouflage for this problem. Weak products with bad UX quickly end up as roadkill. Uncompelling products with a great UX can fake it for a while, only to end up with customers who don’t renew their contracts.

High customer churn equals death for a SaaS business. Churn can happen for many reasons. The hardest to admit and fix is that a product that performs as designed is simply not as compelling as product marketing thought it would be. No amount of account management, limitless sales incentives, or improvements in call-center training will fix it. Put your hat in your hand, go back to your defected customers, and instead of simply asking them why they left, ask how else you can help.

Press

LIFT Wins Customer Experience Awards

Screen Shot 2015-07-06 at 8.14.31 PM

After 6 years and 10,000 retail outlets, it is amazing to see the product I literally built in my basement continue to grow.

So proud to see my old Verifone/LIFT team win two ICX Association Excellence Awards for top customer experience.  Top DOOH Kiosk and top DOOH Mobile Solution! (Verifone rebranded LIFT as “VNet in Store”)

The sky is the limit for data driven interactive customer engagement at the Point of Sale (POS).  Bring on the digital shopper marketing revolution!

The ICX Association earlier this week handed out its 2015 Excellence Awards to 14 winners in the categories of digital signage, kiosk and self-service and mobile, as applied across many vertical markets.

Source: Top customer experience tech honored at ICXSummit15

Technology

The Great iBeacon Hunt 2015

For the past few months, I have been researching businesses that make use of Bluetooth beacon technology for mobile app geo-location and proximity services. It is a bit of the “Wild West” for this particular flavor of technology right now, but some standards, like Apple’s iBeacon, are emerging and have the ability to “wake up” an app on your phone that is completely off. No, not sleeping, not in the background, but off.

From a marketer’s perspective, that is really cool stuff. You have an app on your phone that you have not used in months, but when you walk into my brick and mortar store . . . BAM, the app turns on, tells me you are there, and opens up a world of two-way interactive opportunities.

My mind was running wild imagining all sorts of creative customer experiences, but after a while, I decided it was time to fact check where iBeacons were being used in the real world today. After all, I carry a smart phone with seemingly every app known to man, but I can’t really name you a time when I, as an informed techie, believed an iBeacon was used to augment my physical world commerce experience. Were there any iBeacons out there in the wild in urban Atlanta? Were beacons driving in-app experiences that I was just missing? Were they there but just passively tracking my movements, collecting data, and lying in wait for their moment to spring into action and wow me into spending more money? It was time to find out.

Finding iBeacons in Atlanta – The Plan

My plan was seemingly simple. I would walk every isle of retail I could find with a iBeacon-capable phone “recording” all of the iBeacon signals it found. Interestingly enough, Apple, which created the iBeacon spec, makes this difficult if not impossible to do with an iPhone app. Android to the rescue. After a few hours of weekend Android hacking, I had an iBeacon “radar” app ready to go. The app would make the phone vibrate every time it detected a new iBeacon signature and would then record the signature, time, latitude, and longitude.

Let’s Go Shopping

The iBeacon hunt was on. Over two days, I walked every isle of every store at a large indoor mall and an outdoor retail district, visited several strip malls, hit as many big box retailers as I could find, and visited a trendy new urban retail district full of band new point of sale technology. Surely I would find a treasure trove of iBeacon goodness.

First Stop, the Mall

By the time I parked my car, I was already strung out with anticipation—like only a geek can be. I was clutching my phone wondering why it had not gone off ten times already since driving into the parking deck. Was the app working? Had I made a mistake programming or testing it? Was my sweaty palmed phone death grip blocking the Bluetooth signal? I did not have to wait long to find out. Twenty feet from the front door, my phone gave a triumphant buzzing sound, having found its first bounty. Now satisfied that I had not sacrificed my wife and children’s weekend only to be shut out on my first “Great iBeacon Hunt,” I quickly decided the most fun part of this game was going to be to try to figure out who in the mall was operating each newly discovered iBeacon. My phone could tell me when it found a signal, but information identifying the retailer is not part of the spec. For this first sighting, I had three choices: first, the mall operator could have put iBeacons near the entrances; second, there was a conspicuously large interactive Coca-Cola vending machine just inside the doorway . . . hmmm; and lastly, there was a Victoria’s Secret store in the running, too. This was getting fun.

Having been so immediately gratified, I absolutely expected to walk into a tornado of iBeacon activity. But of course, as I rounded the corner into the main section of the mall, nothing. Then I passed by a few more stores, and BANG there was another iBeacon. Another entrance and another Coke machine. I walked down a few more stores and nothing. Then all of the sudden, my phone erupted. It was like a volcano of iBeacons being detected all at once. What retailer could be so forward thinking to have already adopted this technology with such gusto? The Apple Store of course. OK, time to keep going. About this time, I noticed an ad for the Simon’s Mall app. If I installed the app, would it trigger offers and helpful advice based on my route through the mall? Disappointingly no. I opted into allowing the app to track my every move, shedding any expectation of digital privacy, but I got nothing in return. If Simon’s was indeed operating iBeacons at the entrances or other places in the mall, the benefit to me as a consumer was not yet obvious.

On to the department stores. If anyone can take advantage of beacons, you would figure it is a department store. Beacons are fabulously suited for informing a mobile app that I am, or at least my phone is, in the shoe department vs. the home goods department and so on. Someone at Macy’s had definitely figured this out. Multiple entrances and transitions between departments contained enough beacons to make my phone vibrate like a massage chair from Brookstone. Interestingly, Brookstone did not seem to have deployed any beacons yet. The two other department stores, Bloomingdales and Niemen Marcus, were a beacon desert—not a single one in either store.

Rounding out my trip to the mall with a visit to the food court yielded absolutely nothing until . . . yet another Coke machine and another iBeacon spotted. While this was not conclusive evidence, I decided Coke must be the early innovator. How is Coke going to use iBeacons to drive sales? Your guess is as good as mine, but I’m sure somebody at Coke is thinking a great deal about it.

The Wilderness

After making some initial interesting findings, the long middle section of my hunt was a very slow go. Big box after big box retailer turned up no beacons. Wal-Mart, Target, Dicks Sporting Goods, Pet Smart, Office Depot . . . all yielded nothing. Abandoning the big box hunt, I went to a new retail district known as Krog City Market. This is the type of place where all the merchants run new fancy tablet registers. I thought surely some of these innovative small merchants would be experimenting with high-tech marketing. Alas, nothing. Not a single beacon.

The Mother Load

My last trip was to Atlantic Station, a large outdoor retail district with everything from Banana Republic to Old Navy to Dillard’s. As soon as I stepped away from my parking meter, my phone spotted a iBeacon, but I was not particularly close to any specific storefront. That pattern repeated again and again. My phone was constantly buzzing but seemingly never near a specific store. Pretty soon, I started to suspect that iBeacons were placed on the property info maps, which were strategically located on most street intersections. I thought perhaps this was part of a mobile app navigation system to help shoppers move from one store to another. I downloaded the Atlantic Station mobile app to see whether I was correct. Nope, I was close but wrong again. One of the coolest features of the app was a “find your car” parking app. Excellent! In an outdoor mall where parking can be challenge, the app tagged iBeacons strategically placed in the parking deck and stairways so that it could automatically route your walk back to your car from anywhere on the property. What a brilliant use of iBeacon technology to provide excellent customer service.

Conclusion

In all, I visited about 200 different retailers, and my phone spotted a grand total of 77 distinct iBeacons. Although that number might appear anemic, in my mind, it is actually a great indicator that retailers are experimenting with and searching for ways to take advantage of this emerging technology. I think I’ll take my phone for a spin in six months to see how many more iBeacons are out there. I’ll bet the number at least doubles with two more leading big boxes joining the fray.