Research Agenda of Larry Hawes, Lead Analyst

Greetings! As my colleague Stowe Boyd announced yesterday, I am part of a fabulous group of smart, well-respected people that have joined the rebooted Gigaom Research as analysts. I was affiliated with the original version of Gigaom Research as an Analyst, and am very pleased to be taking the more involved role of Lead Analyst in the firm’s new incarnation, as detailed in Stowe’s post.
For those of you who don’t know me, I’ve spent the last 16 years working as a management and technology consultant, enterprise software industry analyst, writer, speaker and educator. My work during that time has been focused on the nexus of communication, collaboration, content management and process/activity management within and between organizations ─ what I currently call ‘networked business’.
I intend to continue that broad line of inquiry as a Lead Analyst at Gigaom Research. The opportunity to work across technologies and management concepts ─ and the ability to simultaneously address and interrelate both ─ is precisely what makes working with Gigaom Research so attractive to me. The firm is fairly unique in that aspect, in comparison to traditional analyst organizations that pigeonhole employees into discrete technology or business strategy buckets. I hope that our customers will recognize that and benefit from the holistic viewpoint that our analysts provide.
With the above in mind, I present my research agenda for the coming months (and, probably, years). I’m starting at the highest conceptual level and working toward more specific elements in this list.

Evolution of Work

Some analysts at Gigaom Research are calling this ‘work futures’. I like that term, but prefer the ‘evolution of work’, as that allows me to bring the past and, most importantly, the current state of work into the discussion. There is much to be learned from history and we need to address what is happening now, not just what may be coming down the road. Anyway, this research stream encompasses much of what I and Gigaom Research are focused on in our examination of how emerging technologies may change how we define, plan and do business.

Networked Business

This is a topic on which I’ve been writing and speaking since 2012. I’ve defined ‘networked business’ as a state in which an interconnected system of organizations and their value-producing assets are working toward one or more common objectives. Networked business is inherently driven by connection, communication and collaboration, hence my interest in the topic.
While the concept of networked business is not new, it has been gaining currency in the past few years as a different way of looking at how we structure organizations and conduct their activities. As I noted in the first paragraph of this post, there are many technologies and business philosophies and practices that support networked business, and I will do my best to include as many as possible in my research and discussions.

Networks of Everything

This research stream combines two memes that are currently emerging and garnering attention: the Internet of Things and the rise of robots and other intelligent technologies in the workplace. In my vision, networks of everything are where humans, bots, virtual assistants, sensors and other ‘things’ connect, communicate and collaborate to get work done. The Internet, Web, cellular and other types of networks may be used in isolation or, more likely, in combination to create networks of everything.
I’ve had a book chapter published on this topic earlier this year, and I’m looking forward to thinking and writing more about it in the near future.

Microservices

How do we build applications that can support business in a heavily networked environment? While the idea of assembling multiple technology components into a composite application are not new (object-oriented programing and Service Oriented Architecture have been with us for decades), the idea continues to gain acceptance and become more granular in practice.
I intend to chronicle this movement toward microservices and discuss how the atomization of component technology is likely to play out next. As always, my focus will be on collaboration, content management and business process management.

Adaptive Case Management and Digital Experience Management

These two specific, complementary technologies have also been gathering more attention and support over the last two years and are just beginning to hit their stride now. I see the combination of these technologies as an ideal enabler of networked business and early exemplars of component architecture at the application level, not the microservice one (yet).
I’ve written about ACM more, but am eager to expand on the early ideas I’ve had about it working together with DEM to support networked business.

Work Chat

Simply put, I would be remiss to not investigate and write about the role of real-time messaging technology in business. I’ve already called work chat a fad that will go away in time, but it needs to be addressed in depth for Gigaom Research customers, because there are valid use cases and it will enjoy limited success. I will look at the viability of work chat as an extensible computing platform, not just as a stand-alone technology. Fitting with my interest in microservices, I will also consider the role that work chat can play as a service embedded in other applications.
Phew! I’m tired just thinking about this, much less actually executing against it. It’s a full plate, a loaded platter really. The scariest thing is that this list is likely incomplete and that there are other things that I will want to investigate and discuss. However, I think it represents my research and publishing interests pretty  well.
My question is, how does this align with your interests? Are there topics or technologies that you would like to see me include in this framework? If so, please let me know in a comment below. Like all research agendas, mine is subject to change over time, so your input is welcomed and valued.

Real-time Messaging in the Enterprise: Here We Go Again

There was a good Wired article, published yesterday, that bemoaned the rapidly-growing plethora of communication applications centered around real-time chat. Its author lists consumer-oriented applications to demonstrate the situation:

“I bounce through a folder full of messaging apps. I talk to a few people on Hangouts, a few others on Facebook Messenger, exactly one person on WhatsApp. I Snapchat all those people, too. I use Twitter DMs, GroupMe, HipChat, Skype, even Instagram Direct a couple of times. Livetext, Yahoo’s new app, is fun; I’ve been using that. Oh, and there’s email. And iMessage. And, of course, good ol’ green-bubble text messaging.”

The same problem is beginning to develop within businesses as their employees self-adopt enterprise-first chat tools from startup vendors that have been in-market for a while, including Slack, Hipchat, Wrike, Flowdock and others. Oh, and let’s not forget that many employees use the consumer-grade applications mentioned in the Wired article to conduct business, even if it’s against company policy.
Of course, all of these newer chat tools compete with IT-approved enterprise real-time messaging offerings for employees’ attention and love. IBM Sametime, Microsoft’s Lync and Yammer, and Salesforce Chatter are just a few well-known examples of longer-lived, enterprise-grade messaging applications and services that support real-time exchanges. To further compound the clutter, we are also seeing new chat offerings, from established enterprise collaboration software vendors, that mimic their consumer-oriented cousins. Jive Chime and Microsoft Send are real-time chat apps that have been released in the last four months to support organizations’ increasingly mobile workforces.
There are a few problems created by this overwhelming collection of enterprise real-time messaging options. First, these applications are largely siloed from each other, so employees have to remember in which one a certain conversation occurred or know in which application they have the highest probability of gaining a specific coworker’s attention. Second, some can interoperate with other enterprise applications via RESTful APIs, while others require more costly, time-consuming integration efforts. Third, some messaging applications support information governance initiatives such as records retention and disposal whereas other offerings essentially assume that chats are throw-away conversations that do not need to be archived and managed.
There are so many other issues that they will be better dealt with in another post. But they are bound by one clear fact: we’ve made all of these mistakes with previous generations of enterprise messaging technology.

The BIG Problem: Why?

The biggest problem facing the newest wave of enterprise chat tools is an existential one. It is not clear why they are needed when existing real-time messaging tools satisfy the same use cases. I voiced this in the following mini-tweetstorm on the day that Microsoft Send was announced. (read from the bottom of the graphic to the top)
Larry's Enterprise Chat Tweetstorm
That’s right. You can hold my feet to the fire on that prediction. Enterprise real-time chat is destined to quickly fail as a market segment and technology with significant, positive business impact. Just like the combination of status update and activity stream features in enterprise social software failed to displace email, instant messaging and other, well-established forms of business communication.
Insufficient technology is not the cause of poor communication within organizations. We have had at our disposal more-than-adequate messaging technologies for decades now. The real reason that employees and their organizations continue to communicate poorly is human behavior. People generally don’t communicate unless they have something to gain by doing so. Power, influence, prestige, monetary value, etc.
Well-designed technology can make it easier and more pleasant for people to communicate, but it does very little to influence, much less actually change, their behaviors. So the latest enterprise real-time chat applications may offer improvements in user experience, but they won’t measurably increase communication frequency or effectiveness in most organizations unless their deployment is accompanied by change management efforts that include meaningful incentives to communicate.
I intend to track and chronicle the rise and fall of enterprise real-time chat as part of my research agenda at Gigaom Research. Stay tuned over the coming months as we watch this drama unfold.
 
 

On the way to $220M in funding, Instacart quietly changed its business model

In its early days, grocery store delivery startup Instacart made its money two ways: Through delivery fees and product markups. It charged customers more for individual groceries than their in-store price.

But in the last year, the company shifted its revenue strategy. It is allowing some grocery store partners to price their own goods on Instacart. In return, the grocers pay Instacart a fee to service their locations.  It explains why for some grocers the products cost the same on Instacart as they do in store, but for others the price is more (or, confusingly, less).

“We don’t want to be in the pricing game,” Instacart’s head of business Nilam Ganenthiran told me. “There’s exceptions, but that’s generally true. Retailers outsource their e-commerce to us for a fee.”

Although there’s variations in how each partnership is structured, Ganenthiran said the fee, charged to grocery store retailers, is now the company’s “primary model.”

Instacart never made any official announcements about its change in business strategy. I didn’t find out until questioning Ganenthiran about its profit margins. As a result, earlier this week when Instacart received its spate of news coverage over its $220 million funding and reported $2 billion valuation, some outlets misreported Instacart’s business model.

“There has been a perception of the markup model being our primary economic engine due to how we started 2.5 years ago,” Ganenthiran told me. “Our model actually has been evolving.”

Most publications didn’t realize that. The Wall Street Journal went so far as to write an additional story, separate from its funding brief, breaking down a potential Instacart profit on a typical grocery store transaction. The numbers didn’t look good, suggesting Instacart might make as low as $1.40 on an order of 15 basic items.

But since Instacart’s revenue isn’t primarily tied to product markups anymore, that may not be representative of its profit margins.

Instacart wouldn’t tell me whether its grocery store partner fee is calculated per item, per order, per customer, per month, or some other variant. It also wouldn’t disclose how much that fee is. Neither would Whole Foods when I reached out to them for comment, and Safeway didn’t respond. Without knowing what grocery stores are paying Instacart, it’s hard to deduce the company’s potential profit margins on each delivery. “There’s different strategies with different partners,” Ganenthiran explained.

In theory, it’s much smarter for Instacart to charge grocery stores a fee than for it to eke out profits on product markups. That kind of partnership makes grocery stores more amenable to improving Instacart’s efficiency (like offering the company its own personal checkout line). It also shields Instacart from the risk of variable food prices. Ganenthiran said, “Most grocers are past the tipping point where they understand consumers want this service.”

Flywheel has finally figured out its secret weapon against Uber

A few weeks before New Year’s, I received a pitch from Flywheel that I’ve been waiting for since I started using the service in 2013. It said, “Flywheel Battles Uber with #FairFare.” The email inside proclaimed “Flywheel is the no-surge pricing alternative to get a ride around town.”

flywheel email to me

It looks as if Flywheel, the booking app for taxis, has finally figured out its secret weapon against the likes of Uber and Lyft: Reliable pricing. It’s not a new feature for the company. From its inception in 2009 Flywheel has never had surge pricing in the cities it operates in — now SF, LA, Seattle, Sacramento, and San Diego. But for the longest time, the company didn’t seem to understand that this was the best way to lure people back to the taxi system. Instead, it touted Flywheel’s legality, its use of regulated taxis, the number of car companies on its app. None of those were big enough draws.

At the end of the day, people vote with their wallets, and if there’s anything that will get people to move to Flywheel, it’s cost.

Is price part of reliability?

Town car ride-hailing Uber

Uber and Lyft argue that surge pricing makes their services more reliable because it gets more drivers on the road during a time they might not otherwise drive — like New Years or a hostage crisis. There’s truth to that.

But these companies miss the fact that for many non-wealthy customers, stable price is one of the factors in determining reliability. Without the assurance of a fixed fee, people will turn to other services for backup.

Although people have been complaining about surge pricing for years, this New Years showed the first sign that they are willing to stop using Uber and Lyft as a result. The SF Examiner found that on New Year’s Eve in San Francisco there was little to no surge pricing, because of either low demand or too much supply.  The lack of surge upset drivers who gave up their New Year’s to make money.

Tweets from passengers suggest that people planned ahead, deciding to walk, take public transit or flag taxis to avoid the ridesharing surge. Ironically, that resulted in little to no Uber or Lyft surge pricing because there wasn’t enough demand to drive it there. “It was an incredible sight to see all the cabs full and the rideshare cars empty,” one driver told The Examiner. “I was laughing and crying at the same time.”

Another potential reason there was no surge pricing on New Year’s Eve in San Francisco is because so many drivers took to the road in the hopes of making money. With such a flood of supply, there wasn’t enough demand to cause surge pricing.

It’s worth noting the story isn’t bulletproof — it’s based on anecdotal evidence. When I asked, neither Uber nor Lyft would confirm specific SF surge rates in 2014 compared to previous years.

In other parts of the country, where the Uber service is still relatively new, surge pricing was common, according to this CNN data.

Passengers wise up and avoid the surge

The difference between SF and other cities suggests that over time, passengers get smarter about using ridesharing services. Although they may put up with surge pricing initially, they eventually expect and avoid it. As a result, Uber and Lyft could lose customers, and the resulting profit, on some of the biggest travel nights of the year.

It’s clearly not hurting Uber at the moment — the company saw 2 million rides on New Years Eve alone. But the service is new in a lot of places, so passengers are just starting to feel the pain of unpredictable surge pricing. By New Years Eve next year, will Uber users in other places get smart about avoiding the surge, the same way San Francisco residents did?

I suspect surge-avoidance will slowly trickle down to day-to-day travel. I live near Union Square in San Francisco, so I’ve already learned I can’t rely on Uber and Lyft from a pricing perspective, because they’re nearly always operating with surge pricing here. Without that reliability, I prepare alternative options for travel and develop new habits, lessening my ridesharing addiction. That’s where a competitor like Flywheel or Sidecar could come in and do really well.

There’s been plenty written about how surge pricing is a broken system, but there hasn’t been much ado about the fact that it’s also Uber and Lyft’s biggest weakness. It’s the one area where other companies can easily beat them.

The Tinder for crime-fighting might just be Tinder

Well this is unusual.

Buildzoom, an application for finding home contractors, is turning to the crowds to ID a woman who has robbed it multiple times. Specifically, the crowds on Tinder.

The Tinder profile Buildzoom created for its burglar, using an image from the security camera

The Tinder profile Buildzoom created for its burglar, using an image from the security camera

Camera footage caught a pretty good shot of the woman’s face, so Buildzoom turned her into a Tinder profile. Founder David Petersen photoshopped a reward message on top of the image that said “I rob offices in SF. $5000 reward for identifying me.” He told me police gave him permission to do so after their other leads went dead. Although he only created the Tinder profile yesterday, he said it has already generated a few leads.

When asked where the idea to use Tinder came from, Petersen said, “I was trying to figure out, ‘How can we get this face in front of people?'” Most might turn to Twitter for that, but Petersen had already tapped the Twitter mob. He thought a face-focused app, like Tinder, might be another solution.

Other businesses in the area had been robbed by the same woman. The companies shared a similar digital lock for the door, which this person figured out how to hack. Petersen estimates that ten of them have been hit, and the robber has walked out with tablets and Apple computers. “She left behind the PCs, which we all felt was funny,” Petersen says.

This isn’t the first time that the crowds have been used to identify a criminal. In September Twitter users crowdsourced the identification of suspects who attacked a gay couple in Philadelphia. Crowdsourcing criminals can also go awry: Reddit users famously “exposed” the wrong Boston bombers and the picture went viral.

But this might be the first time anyone’s attempted to find a criminal via Tinder. I couldn’t find any other examples online of this happening. I reached out to the dating app company to fact-check if this is the first.

The mis-measure of Netflix

In Netflix’s subscription-based on-demand world, viewership is cumulative. Measuring it at any given point in time might give you a number, but that number has little correlation with the content’s value to Netflix.

Regulating peering

One of the most puzzling aspects of the peering disputes that have arisen — principally between Netflix and a handful of the largest ISPs — is how little money appears to be involved.

HBO, CBS and net neutrality

Underlying much of the debate of interconnection fees and paid prioritization is an unspoken and largely unexamined assumption that the current power dynamic between ISPs and content providers is both inevitable and immutable. It isn’t.

The number of 9s don’t matter, but business metrics do

Technology organizations use percentage uptime as a key performance metric. Unfortunately, it is very technology focused in a time where business metrics are the norm. Which business metrics can IT focus on and how can the CIO help lead the charge?