There's an App For That. Does Anybody Use It?

By Mad Tatu (cropped) [CC BY-SA 4.0
 (http://creativecommons.org/licenses/by-sa/4.0)],
via Wikimedia Commons

In a really smart Vox piece, Ezra Klein peers into the future and predicts that many media companies will look more like wire services in the years to come. Along the way, he comments on how rapidly digital media is moving and how what seems like the hot new trend one year looks silly just a year later. "Remember, for instance," he asks "When the iPad launched, and apps were going to save journalism? Lol."

That observation is just an aside in his piece, but it struck a chord for me, for I've seen far too many media companies (and companies in other industries, for that matter) stumble down the primrose path when it comes to creating apps.

Gimlet Media, a start-up podcast production company, offered an interesting example a little while back, which they chronicled as an installment in their podcast series "Start Up" (episode #13, in this case.) Gimlet already has a small lineup of really good podcasts and was trying to figure whether they should make an important business shift and, instead of just producing content, create an app to deliver that content to listeners. (And potentially, to try to doing something even bigger and become "a platform." All the investors in Silicon Valley seem convinced that you can't just make whatever application it is you are trying to make but you must build a platform and even better an ecosystem—all the better for getting that hockey-stick hyper-growth.) 

So the Gimlet team set about trying to figure out what their app should be, and they teamed up with Google Ventures to create a quick prototype, which they demonstrate in a cool video. In their design sessions, they narrowed in on the following ideas for what the app might do—its features, if you will: 

• Let the podcast creators share content (like documents and visual artifacts) that they can't "show" in an audio-only podcast
• Provide a "talk to us" function to let listeners record their own stories
• Provide access to members-only content and allow people to purchase a membership
• Let listeners more easily support their favorite podcast by clicking a button to purchase the host's book or a sponsor's product without having to go to a web site and punch in a promo code (as you have to do with most podcast sponsors these days.)

The results are what we see all too often when it comes to apps. We start by deciding first that we want to build an app (or, our marketing people run into our offices and shout, "We have to have an app! Now!"). Then we try to figure out what the app should do, and when we start grasping for features, the natural tendency is to try to make it solve our own problems, not those of potential users. 

What pressing needs of podcast listeners, after all, does the prototype app describe above solve? There are already plenty of apps (like the Podcasts app that comes free and pre-installed on iPhones) that satisfies the pressing immediate need of most podcast listeners. Are listeners really itching to look at "bonus content," especially of a visual sort? Are they really saying, "boy I wish I could record a story for these guys" or "I really, really want to buy one of those Harry's razors but typing in a URL and promo code is too hard?"

I doubt it. Most of these features seem aimed more at solving the problems not of the podcast listener but of the podcast creator ("I want to make money by having my listeners buy things through affiliate links and if it's easier maybe more people will do it.") Despite my best efforts, I can't come up with a podcast listener problem out there that's so pressing that someone would shell out even 99 cents for an app that solves it or even, in a world where so many dozens of apps already clog our smart phone screens, bother to download it for free.

Yet I see that again and again when media companies try to come up with a "game changer" app that's going to save their bacon. Like (speaking of bacon) the New York Times's Cooking app. The rationale for its existence? It provides "inspiration on what to cook" and "helps you find, save and organize recipes." But is that a problem that cooks really have these days on the Internet? I've certainly never heard anyone complaining about it, and Google (not to mention Pinterest) does a wonderful job of helping cooks find inspirations and recipes.

It all comes back to one of the fundamental principles of application design, and it applies whether that application is a big one for desktops and web browsers or a small "app" for tiny screens. You have to start first with a problem that needs to be solved and choose the proper approach (web, mobile-enabled web, device specific app) that bests suits the problem.   

And if the main problem we are trying to solve is that "we need to make more money somehow" or "we just need to have an app," well, in the words of Mr. Klein, "Lol." 

Walking Before Running When It Comes to "Big Data"

The ComputerWeekly.com's Developer Network blog recently reported on the results from a Rosslyn Analytics survey that shows, among other things, that only 23% of businesses closely align their business strategy to the data that's available to them. What I found particularly interesting was not that statistic but the way that the CW blog, in both the headline and lede of the post, managed to shoehorn the Rosslyn findings into a Big Data story: "Gut instinct drives more firms than big data analytics."

But the Rosslyn report is not about Big Data specifically but rather just data in general. When asked to identify the top issues keeping their organizations from getting value out of their data, those surveyed cited not the lack of advanced analytic skills or adequate technology but rather the scattering of data among disparate systems and the poor quality of that data. For all the powerful things that Big Data technologies can do, they don't provide a silver bullet for these fundamental data issues.

Most tellingly, fewer than half the business leaders Rosslyn surveyed considered their data to be a strategic asset, indicating a lack of executive sponsorship for data initiatives.

Which, as always, reminds me of a story. Several years ago I was helping an organization implement and drive adoption of a sales automation solution. The CEO was convinced (by instinct) that the reason the sales teams weren't hitting their numbers was that the reps weren't out in the field making enough face-to face-calls. He kept hammering on the sales managers to increase the field activity, but without a way to measure how much was going on the discussions quickly devolved into finger pointing and rear-end covering.

The sales managers maintained that their teams were already knocking on every door they could. The data needed to support or disprove the activity thesis was scattered in Outlook inboxes and calendars and, more than anything, verbal reports—and the sales reps had gotten quite proficient at rattling off a stream of "updates" during weekly team calls that made themselves sound very busy.

The solution was simple. We created a basic weekly activity report out of the new sales automation system—just a simple grid that broke out, week by week, the number of prospecting emails, phone calls, and in-person visits that each sales rep on each team made. The data was only as good as what the sales reps had entered into the CRM system—and, despite training and weeks of evangelism to try to get the sales reps to record their activity, we knew that it was incomplete at best.

But that didn't really matter. Once the numbers were side by side, the CEO could immediately see which teams and which reps had a lot of activity and which ones didn't (or, at least, weren't recording their activity regularly.) It didn't take machine learning or complicated correlation analysis to see the conclusion. The leadership team knew who the top performing sales people were (they were the ones taking home big commission checks each month), and they could see right off that those same reps were the ones with the highest activity logged. The CEO turned to his VP of Sales and laughed. "How did we ever run the business without this report?" he said.

The business decision was clear: get the teams out in the field more. With the CEO inspecting the report each week, the sales managers were on the hot seat and pushed their teams to record their activity faithfully. As the numbers got better, the organization was able to identify and settle upon the right level of field activity that drove sales—and field activity rose and so did overall sales.

That's one reason why all the hype around Big Data can actually impede an organization as it tries to  transform itself from instinct-driven to data-driven. If you can't get from your house to work because you live on a rutted, weed-choked dirt road, the answer isn't to sell your old sedan and buy a faster car. You probably should to start by fixing the road. And that doesn't mean transforming a dirt road into a multilane highway in one big burst but rather by fixing enough of the ditches and potholes that your car can pass over it.

When it comes to business data, fixing the road means taking the data you already have and using it in a way that has tangible business value—enough tangible value that decision-makers will want to see more of it.

Taking Hadoop and pumping a bunch of data into a massive repository and creating a lot of colorful charts and graphs won't do much if the decision-makers don't trust the number underneath the analysis, so data quality is important. Even worse, though, is if the organization's leaders aren't able to immediately see how the "insights" contained in the analyses offer concrete guidance on what the organization should do. In other words, if the data doesn't help them make decisions, they won't adopt it.

And that's where focusing on the technology first is a mistake, and focusing on the data first isn't much better. Rosslyn's survey respondents believe that "product data" and "customer data" are the types of data that are most valuable to organizations. But what's not discussed is why that data is (or, at least, could be) valuable to decision-makers.

By definition, decision-makers make decisions, and if they don't have the data they need to make those decisions they are going to do it the way they always have: by their gut.

What are the key business decisions that your decision makers are trying to make? What is that one report that you could hand to the CEO and give him or her a view that makes them say, "How did we ever run the business without this?"

Start with that and you'll be well on your way to creating a data-driven organization, which is the necessary prerequisite and motivating force—not the result—of unlocking the potential value of Big Data.

Give 'em the Business

Increasingly, I shudder every time I hear someone in a technology role talk about "The Business."

You know, like this:

We need The Business to give us the requirements.

Or, we need to get someone from The Business to weigh in on this.

Or, if The Business can just tell us what they want and stop changing their minds we could get this project delivered.

Embedded in the very term is an old, outdated way of thinking. It implies that technology is somehow separate from the main line of work that a company does. We're an office supply store. We have IT systems to help us order products, manage inventory, and track sales, but that's not "our business." Our business is selling office supplies to customers.  

If such a stance was ever really tenable, it ceased to be so once customers started ordering all their office supplies online instead of going into brick-and-mortar stores and suddenly the online commerce system became the very center of the business.

In 21st century companies, technology is no longer a back-office support role. The IT/Business divide is one of the biggest sources of friction within organizations, and it prevents them from being able to innovate and adapt to rapidly-changing markets. For innovative companies today, technology IS the business, and vice-versa.

This isn't to say that should be no distinctions in roles within teams. Being able to write effective, efficient software code or diagnose a network failure takes a different set of skills and temperament than, say, understanding why customers want to buy one product and not another or how competitors are charging for their offering. But these days the people with those differing skills and abilities need not to be isolated in different parts of the building—or perhaps even in entirely different cities—but instead sitting side by side together, collaborating to constantly redefine and drive forward the business (with a lower case 'b').

I can think of no better way to get started than to forbid anyone on a technology team from referring to other groups as "The Business." This is more than a symbolic thing. Just the mental gymnastics of having to come up with a different term to describe non-technical counterparts should go a long way toward bridging the pernicious IT/Business gap.

So what do we call "The Business" instead? Referring to individual roles would be a start: we need a marketing analyst to review this text. Perhaps better would be just to say Bob or Sally should help us revise this text. Even better would be to just lean across the work table and say, "Hey, Sally, how does this look?"

More than anything, though, companies need people in roles who can cut across traditional boundaries—that is, individuals who can both understand the company's market and customers and their needs as well as see the potential for enabling how products are delivered to those customers through technology.

I won't even bother to see if "The Business" will approve this idea.