Cook 'em Dan-O

What Caltrain Could Learn from Staples

One morning I looked out of my window and watched as a woman just missed the train. Experienced riders know that when they hear the "caution, the doors are about to close" announcement, it's already too late. The doors are closing, and unless you want to dive onto the train before they shut, you're out of luck. (And I wouldn't try the stick-your-arm-in-and-the-doors-will-reopen trick.)

This would-be rider looked like a new passenger, not one of the "regulars" who get on the train in Gilroy. And as we rolled away from the station I wondered, will she be back?

When a for-profit business sees that its customer base is in decline, its costs are up and its revenues are down, it faces a "code red" moment of decision:

• Can we reverse these trends? At what cost?
• Do we "double down" (I hate that phrase) and work to turn things around? Or do we determine that these trends cannot be reversed, and exit the business?

Notice that nowhere in this line of thinking does the business say, "hey! I have a right to exist!" or "but look at all the good I do!"

When a non-profit organization faces these same challenges of declining customers, growing costs and sliding revenues, the moment of decision often revolves around raising prices, cutting services, and asking for more subsidies.

I won't get into the discussion of whether organizations that provide a public good (like transit agencies) should be fully funded, fully self-supporting, or something in between. That's a discussion best left for others.

First You Commit, Then You Make it Work

My main point is that transit agencies, in this case CalTrain, need to think about the problem from their customer's point of view. Why do people ride the train? You could probably come up with a set of reasons.

• It's cheaper than driving.
• It's my only transportation option.
• It's good for the environment.
• It's less stressful than driving.

In most cases, few of these answers are valid justifications.

• Given my commute, gas has to be priced above $4 per gallon before the gas-vs.-train ticket option tips in favor of the train ticket (lately, that's been the case).
• Most people have transportation options, especially a car.
• Riding the train is probably better for the environment that driving a car.
• Riding the train is definitely less stressful than driving.

But it's also true that

• Riding the train takes longer than driving… in my case it's about two hours each direction, when you include getting from the train station to/from work. Driving time can be anywhere from one to two+ hours depending on traffic conditions.
• Riding the train means you have to work around the train schedule. You have certain windows of opportunity to catch the train. If (like many people) your day has undefined starting and (especially) ending points, you have to work to incorporate a fixed train schedule into your day.

My point is that the decision to ride the train, especially on a regular basis, is a lot less rationally based than you might think. Sure, if you happen to live and work near a CalTrain station you can just fall into the habit. But for everyone else, riding the train means making a commitment to it. You have to think about your work schedule, how you're going to get to/from the train station, arrange to purchase tickets and so on.

What Were Once Vices are Now Habits

Department of Obscure References

So when that woman missed the train, you have to wonder: how committed is she now that she was unable to take that first step? And what could CalTrain have done to make it easier for her to follow through on that idea of riding the train?

I remember when I figured out why the old book and record clubs were willing to sell you 10 books or CD's for a penny. It wasn't about marginal cost vs. marginal price. It was about the requirement that you buy a certain amount of product over a certain number of months. And that was about establishing a habit of purchasing. These companies knew that once they got you into the habit of at least considering a book or CD purchase each month, they were more likely to get you to buy.

Hitting the "Easy" Button

So here are some free tips for CalTrain, ones that would focus on encouraging the budding commitment of passengers to ride the train, and that would reinforce the decision for more established passengers.

Simplify Ticketing

Today you have three ticket options:

1. Buy a ticket at one of the CalTrain vending machines.
2. Buy an "8-ride" pass and use your Clipper card (a reloadable debit card) as your ticket.
3. Buy a monthly pass and use your Clipper card as your ticket.

The first option is challenging because only a few stations have working ticket counters, and some of the ticket vending machines don't work. One of the two machines in Gilroy has been "temporarily unavailable" since at least 2007. Also, the vending machines sometimes will bill your card twice for a ticket, or fail to authorize your card for no clear reason. There's nothing like the pressure of trying to buy a ticket while the queue behind you builds and you're mentally counting down the seconds until the train is ready to leave.

Oh, and buying a ticket on the train? What do you think this is, 1990?

CalTrain has begun moving to a reloadable debit card, the "Clipper Card" as an alternative to ticketing machines. This is a good move, but is way behind the curve when it comes to simple, mobile payments. If you have less than $1.75 on the card, it gets screwed up (and the conductors think you're freeloading). If you try to use it to travel between other zones than the ones you specified when you charged it, the card is inoperable. You can load funds onto it automatically, but you have to wait up to three days for the funds to transfer and clear.

Imagine how much easier it would be if you just loaded a specific dollar amount onto your Clipper Card, and then had it deduct the right amount depending on the length of your train ride. And if you want to offer discounts for multi-ride sales, just offer a flat percentage discount.

Maybe the architecture of the Clipper Card makes it hard to deliver a more flexible payment experience. But here in the heart of Silicon Valley, many CalTrain riders carry smartphones, and there are any number of mobile payment companies—startup's and established companies. So why not partner with someone to offer a smartphone-based payment option?

Convert Unticketed Passengers to Paying Customers

As I mentioned earlier, you can't just walk onto CalTrain and buy a ticket. CalTrain is a "proof of payment" system, meaning you have to be able to prove you've purchased a ticket or face the possibility of a large fine.

In all the time I've been riding CalTrain, I can't recall an interaction with an unticketed passenger that was the result of someone trying to get a free ride. Inevitably, the offending person had a problem getting a proper ticket, got frustrated/confused, and boarded the train anyway. Then there's a discussion (sometimes tearful) between the train conductor and the passenger. The conductor has to play the "heavy" (a role they don't enjoy) and threaten to write a ticket, but they don't have an incentive to do this as they're busy checking everyone else's tickets and making sure the train runs on time.

A much better solution would be to have a way of selling a ticket to the ticketless passenger. CalTrain could make the ticket very expensive as a disincentive to relying on this method for buying tickets. Companies like Square offer very simple card-reader capabilities that work with a smartphone to process payments.

Partner with Large Employers

Remember the "80-20 Rule"? How about partnering with large employers, like Google, Facebook, LinkedIn, Lockheed and so on? Give these companies some incentive to encourage ridership among their employees—special shuttles, discounts, etc. Getting a few of these companies lined up gets you to a large portion of the potential ridership.

Make it Hip

Department of Obscure References

How about giving people a reason to feel good about riding the train? Some of the riders who bring their bikes are making a statement about avoiding oil consumption and the like. How about letting people know how much CO₂ emissions they've avoided by riding the train?

Focus on Your Customers, and the Funding Will Follow

Maybe agencies like CalTrain focus on making sure they can serve all constituents equally. For instance, perhaps the idea of paying via smartphone was rejected because not everyone has a smartphone. I'm in favor of making sure that everyone has access to public transportation. But implementing programs that require everyone to be served equally doesn't work. Or it works too well—everyone is served equally poorly. It makes much more sense to provide a great experience to those riders that are choosing to ride, and let their ridership subsidize those that are riding the train out of necessity.

If you're a non-profit or other ortganization dependent on goverment funds as well as paying customers to survice, how do you want to succeed? Do you want to convince the public and your funders that y ou deserve to exist? Or do you want to make people feel like they can't live without you, that it's easy to say "yes"?

Social Media: DVR Killer?

I remember (from my visits using The Wayback Machine) when certain hit shows like MASH and Friends had their final episode, and people would gather at someone's house to watch together.

Then along came the DVR—Digital Video Recorder, the collective noun version of TiVO—and forevermore we were "time shifting"… recording shows and watching them whenever we wanted, as opposed to when the networks wanted. Media people wrung their hands and worried that this was the end of television advertising, since viewers now had the opportunity to fast-forward past the commercials.

Fast forward to the world of social media. People at an event are "live-tweeting", meaning you're getting a stream of messages that are directly or indirectly telling you what's happening at the event. So for instance, you didn't have to be watching or listening to know how the Stanford-Oklahoma State football game was going… Cheer, groan, cheer, etc.

And if they're not tweeting, they're using Facebook. Or texting. Or using any of a number of other commenting and sharing services. What's happening here is that the community that at one time would have gathered in someone's house, or a bar, or at the event itself, is now gathering in a virtual way. We're all watching, and social media gives us a way of staying connected and sharing the experience.

And here's where the traditional media people should pay attention. The trick is, you can only connect and share as the event is happening. If you recorded the Stanford-Oklahoma State game for later viewing, all this sharing is going to ruin the ending. And if you want to connect and share, you have to do it live. Which means you have to watch the commercials.

So if the traditional media people are on their game, they'll be creating all kinds of opportunities to share their shows, games, tournaments and so on as events.

Fast-forward that.

Road Show Road Kill

I'm doing some consulting these days, and one of my assignments is to help a small managed service provider transition into selling cloud-based services. It's fun work, as it puts me at the intersection of sales and product.

As part of this work, I attended a "road show" put on by one of the (very large) companies whose products/services we currently sell. The focus was on their "cloud" service offerings, and the audience was schmo's like me looking to figure out how to sell these kinds of services… without drowning in a sea of collateral and sales documents available on the company's web site.

I'm well-acquainted with the "road show," at least from the presenter's side. You barnstorm through a bunch of cities, pitching your particular product/service to the audience of customers or salespeople that have been assembled and coerced into staying by the free food and the prize given out at the end of the event. The days are long, the travel numbing, the presentations become increasingly difficult to do with enthusiasm. On the other hand, you're bonding with co-workers and drinks are on the house.

This was one of my first opportunities to experience a road show from the audience side. The free food was fine, a little light on the fruit and vegetable side. The give-away at the end (a video game console) was also fine, though it didn't hold my interest. And some of the presentations were really well done: focused on the needs of the audience, simple but still informative, and delivered with enthusiasm and humor.

But the presentation that stood out, of course, was the one that seemed to break every rule of presenting—in seemingly sequential order.

• The presenter started with an apology, having to do with not having the usual technical support person available to handle the really tough questions. She may as well have started by saying, "you're not going to get much out of this, but it's not my fault".
  • Don't EVER start with an apology. You immediately take yourself out of the "driver's seat" and undermine your own credibility. Better to wait until you actually have something to apologize for.
• The presenter's slides had WAY too much information on them. And apparently much of the information wasn't that important, because the presenter made no attempt to communicate it.
  • I've harped about presentations elsewhere, but here's the main point: do you want people listening to you? Or reading your slides? And by the way, are you saying anything interesting that's not already covered on those slides?
• The presenter said, in so many words, that "Version 1" of the product sucked.
  • NEVER bad-mouth your own product. I've seen presenters do this, thinking it's their way of bonding with the audience. All it does is make the audience wonder, "What kind of a loser would want to work for a company that put out such awful products?"
• The presenter went on to say (again, I'm paraphrasing), "Eventually, we'll be best in class." So, am I supposed to check back when you actually have something worth selling? It turns out that what she meant to say was that the cloud-based product would eventually offer the same features as the locally-hosted product. But that's not what I heard.
  • It's OK to have a better product later. But don't imply that your product is bad right now.
• The presenter talked about the product's "agility" and in the next breath discussed six-month (!) release cycles. I'll admit this is more of a nit, as "agile" has special meaning to those in the product development world. And it's true that this product's release cycles are much faster than the locally hosted version's cycles. But most people looking to do "Agile" product development are planning for weekly release cycles, not half-yearly ones.
  • Be careful with your language. You don't want to claim you're something (e.g., "Agile") when the evidence isn't there to support it.
• The presentation (slides and spoken words) was filled with company-specific jargon and acronyms. Your TLA's are your own. I no more want to adopt them than I want to order a "Venti" sized coffee.
  • Circle every acronym and piece of jargon on your slides and ask yourself, "Do I really need the audience to use this term or know what it means?"

If you don't want this to be you, pay attention to your presentation: its message, focus, and delivery. Or you could make sure I'm not invited to your show.

How Not to Get the Sale

This happened to me on Saturday. I had just stepped out of my house and was walking down the street when I saw what I took to be a new neighbor, standing outside of his house, smoking a cigarette. After Jerry and I shook hands and said hello, we had this conversation:

Jerry: Do you need any yard work or gardening done? I could do that and I don’t charge much.

Me: No, I’m renting my house and they already have a gardener.

Jerry: How about hauling or other work? You might need that, being old and everything.

Me (smiling): No Thanks. But ask my neighbors, they own their houses so maybe they could use your help.

Jerry: OK, well let them know, OK?

If you’re going to attempt to sell something to me, make sure your selling point isn’t something I’d find insulting or at the least not true.

And if I offer you help in identifying sales prospects, don’t thank me by asking me to do more work for you.

What Do You Want From Life?

Department of Obscure References

I found this posting on Tech Crunch interesting, as it highlights one aspect of a decoupled mobile platform architecture:  managing OS updates.

The chart nicely illustrates the difference between the Android and iOS device platforms.  Apple regularly updates their iPhone devices with current versions of their iOS operating system.  Google?  Not so much.  In fact, the chart shows that some Android-based mobile devices ship with out-of-date versions of Android from the date of introduction.

You can imagine the company reactions.

Google: "Hey, what do you want? We just make the OS and ship it."

HTC/Samsung/Motorola et al:  "Hey, we just take the latest OS release, put it on the device, and ship it."

Verizon/Sprint/AT&T et al:  "We don't know how to keep devices current."

I'm not going to weigh in on whether Apple or Google's strategy is better (and for whom). But the situation does illustrate the choices you face as a device maker, OS provider, and mobile carrier.  If you're Apple, you've built a company that obsesses over every detail of a customer's experience with your product.  So naturally you're going to control both the hardware platform and the OS that drives it.  And you're going to spend more than a little time checking out the applications that other people are developing for your product, but that's another topic for another time.  If you're Google, your model is quite different.  You're trying to build share as quickly as possible, so you're going to give away the OS (subject to patent infringement limitations), kick-start the third-party applications community, and get your OS on as many smartphones as possible.  Since you're Google, you're going to bring out a new OS version every quarter (although the release schedule is anything but smooth, with six months between some releases and one month between other releases).  And since you're not in the hardware business, the need to test OS versions on a variety of current and recent devices is Someone Else's Problem.  If you're the mobile carrier, you may or may not care... but you're ill-equipped to manage this kind of hardware-software lineup.

When I worked at iPass, in order to aggregate and resell what we called "Mobile Data" services, we had to supply the 3G modem card along with the other bits that made up the service.  Suddenly, we were a hardware as well as a software company.  We had to manage inventories of modem cards... different cards for different mobile data networks, with different device and OS dependencies.  And this was our problem, because the mobile carriers were unable to manage it.  A mobile carrier might take six months or more to qualify a particular device, train its Sales and Support teams, and roll out the service.  In an Android type of world, this means the service would launch with an OS one or more releases behind the current version.  So we managed the lineup of OS releases and target devices, and in some cases provided the OS update function on behalf of the mobile carrier.

So what does this mean if you're Research in Motion, trying to maintain relevance in what people want to tag as a two-horse race between Apple and Google?  It means you can add value by 1) ensuring everyone knows what versions of OS work with what devices, and 2) making sure that you provide OS updates.  This doesn't put you ahead of Apple, but it does put you in a better position vs. Google.  Google would have a hard time keeping OS versions and devices straight, even if it wanted to do so (and it doesn't).  Apple will do this because they're Apple, so RIM has to find other ways to compete against them.

Some people would respond that keeping the OS on a device up to date doesn't matter, and they're right--until it does matter.  It's a bit like saying that insurance doesn't matter.  As a consumer, you want the device--including the applications you've downloaded onto the device--to just work.  You don't care how or why, just that everything works.  And if you're RIM, you're in the best position to make sure this happens.  And that's good for your customers, and good for you.

Great Presentation Advice

I saw this post on Forbes about presentations that I thought was great. The posting describes a simple test by Vinod Khosla:  show someone your slide for five seconds, then ask them to describe its content.  I had the good fortune to learn this from Yuri Shtivelman, when he and I worked at Nortel Networks.  Yuri would have me step through my slide presentation, spending a few seconds on each slide.  For each slide he would ask, "what's the message?".  Then we would write down each message, look at them in sequence, and determine whether they told the story we were trying to tell.  It was an approach that worked quite well, especially during strategic planning season.

What are the take-away's here?

• You have to create presentations for the right side of your audience's (collective) brain--the side that processes images and ideas vs. words and arguments.  That's because people don't read your slide, they absorb it.
• As the Forbes post describes, when you put up a slide people focus on it... and stop listening to you.  If you don't believe me, try putting a picture of a puppy in your presentation, in some random spot, and watch what happens.
• The presentation is for your audience, not you.  If you need cues to remember your key points, write them out on index cards.
• Tailor the slide material to the preferences of you audience.  Your CFO will want to see numbers in a table more than a chart.  Your CTO will want to see a diagram.
• As always, less is more.  Guy Kawasaki's 10/20/30 rule is still the best!

 

A Tweet-ful of DreamForce

I took advantage of a free offer (not offered by Groupon, FYI) to attend DreamForce, Salesforce.com's annual tradeshow and love-fest.  I've been thinking I have skills transferable to the SaaS industry (a view yet to be endorsed by hiring companies) and figured I would head up to San Francisco to see what companies were part of the salesforce "ecosystem".  Here are my observations, in tweet-sized bites.

• I'm glad I drove to Moscone Center, vs. taking the train.  Three hours of travel for an hour or so of walking around would have seemed like a waste.
• To the parking lots that doubled their rates this week:  way to keep it classy!
• It's always a treat to find free parking in San Francisco; my Dad would have been proud!
• You have to love Larry Ellison.  He hires people to walk around outside Moscone Center with cloud-shaped balloons proclaiming "Oracle, #1 in CRM".
• Confidential to Larry:  sorry about that $1.3B smack-down from the Court of Appeals.
• Apparently this is the ninth year of DreamForce, leading to the cute and inevitable "Welcome to Cloud 9".
• Salesforce's force.com, data.com, service.com and so on... very confusing.
• Interesting to attend a trade show with no Oracle, SAP, or Microsoft.
• BMC's "Remedy for Salesforce" or whatever it was called... why do I have the feeling this looks like the old DOS programs that ran in a Window?
• Accenture, Deloitte and CapGemini here looking for business.  That seems like a tough sell.
• iPads way outnumber laptops.
• Most of the exhibiting companies are involved in the various stages of the marketing-sales process:  quote, order, customer engagement, marketing analytics, customer service and so on.
• All my favorite Identity Management companies were there: Ping Identity, Okta, Symplified.  Still an idea looking for a market.
• Box.net exhibited, but not Dropbox.  I guess that confirms what market each company is targeting.
• Saw Neal Young on the rebroadcast of Benioff's keynote.  Don't know if that was hip or sad.
• Most over-the-top exhibit:  the guy dressed as the "For Dummies" character.  Second place: the exhibitors dressed with green wigs.
• Gamification... really?
• I finally understand that iPass isn't SaaS; it's IaaS.  Or MaaS (mobility-as-a-service) if you want to make up another acronym.
• A day like yesterday makes it easy to love working in San Francisco!

Energy Efficiency--What is Plan B?

I read a great post today from Steve Blank, about having a "Plan B".  You should read the post, because it also contrasts the mindset of people who realize the need for a Plan B vs. those people that put their mental energies into execution.  But what I found interesting was relating it to a recent post from GigaOM on Cisco's exit from the energy efficiency business.

As GigaOM pointed out, the issue is getting someone to pay for energy efficiency software (we'll get to hardware in a minute).  Or, to use Steve Blank's language, there's no sustainable business model here. 

Cisco, Google, Microsoft, and others have all attempted to market energy efficiency to households, with little to show for it.  Yes, people want to save on their electric bills.  But people haven't demonstrated any willingness to pay for tools that will help them save money.  Utilities would love it if people were more energy-conscious (it's easier to avoid the need for an additional megawatt of power than it is to plan for production of that megawatt), but they don't want to subsidize home energy efficiency solutions either.  You could argue that households don't understand the benefits, but I'd argue that if the utilities (who have lots of smart people doing cost-benefit calculations) don't see the cost-effectiveness of paying for household energy efficiency, then there's no argument to be made in its favor.

One product-related problem is that it's expensive to measure energy consumption at its source--meaning the individual appliance.  You know you're using more electricity between 10 AM and 5 PM on a hot day when the kids are home on summer vacation.  And you can presume that the air conditioner is the culprit.  But what about the electric clothes dryer? the always-on television?  Knowing where you're using electricity requires monitoring and measurement--which is costly to accomplish (compared to a software-only solution) and can only be done if there's a way to measure energy consumption at each appliance.

But back to "Plan B".  If you've developed an energy management software application, how do you monetize it?  Selling it to electric power utilities means having to approach just a small number of prospective customers, each of which would be committing to a large-dollar purchase.  But (as we've seen), utilities don't want to shoulder this cost.  And (as Silver Spring Networks' balance sheet shows) utility buying cycles are very long and complicated.  Start-up's looking for a way to "disrupt" the industry are more likely to focus on selling to households; there are millions of them!  It's my Law of Large Numbers: any number multiplied by a large number is another large number.  But as we've seen, consumers aren't taking the bait.

So what's Plan B?  If you're a utility, you're looking for Someone Else to pay... whether that would be the government (via some kind of subsidy) or the customer (by burying the charge in a billing line item).  If you're a software company, you might exercise the "Google Reflex" ("we'll make our money off of ads!").  But really, how often are people staring at their thermostats or some kind of energy usage dashboard?

I might go after the appliance manufacturers.  They would have to build (or at least accommodate) energy consumption measurement into their goods to make energy consumption management more than a time-of-day phenomenon.  And they know how to sell to household decision-makers.  Appliances that don't normally have a consumer UI (such as air conditioners or overhead lights) would need some kind of customer-facing UI to communicate usage anyway.  Energy efficiency could be bundled in with information on appliance maintenance (such as a notice to change the furnace filters) that household customers would find useful.

That's just one idea.  As always, it's about figuring out who benefits and making sure they have a motivation to pay for that benefit.

Getting CIO’s to Buy Into BYOA

"The Consumerization of IT"—have you heard this phrase? Probably. Given that I first heard of it in 2006, one can presume that it's jumped the shark at this point. So what does it mean, and what's the point? I like the way Matt McIlwain put it in his post for Forbes (see it here). McIwain says it originally referred to "BYOD"—Bring Your Own Device—and now increasingly refers to "BYOA"—Bring Your Own Application.

It Followed Me Home... Can I Keep It?

When wireless carriers started offering Blackberry smartphones to consumers, employees at enterprises started going out and getting their own Blackberries.  They brought them to IT, saying "make this work". Blackberries supported a mission-critical corporate application—email—so it was hard to argue against supporting them. Further, employees were becoming increasingly mobile, meaning that company-issued laptops weren't always sufficient to support this new desire for always-available email.

Since that time, employees have moved on, and now bring in iPhones, iPads and assorted Android devices… all with the same support request for IT. That has spawned an industry around mobile device management, starting with Bigfix (since acquired by IBM), Sybase's Afaria (now part of SAP) and iPass' Endpoint Policy Management, and more recently blossoming into all sorts of hardware, software, and services solutions. And smartphone makers have gotten better about providing the kind of support (remote wipe, device lock) that CIO's need to properly support these devices… Although securing data on mobile devices is still a concern.

Thanks, I'll Use My Own Application

And now, enterprise employees are increasingly introducing their own applications into the enterprise: file sharing and collaboration (YouSendIt, Dropbox, Box.Net, and others) note taking (Evernote), document viewing (GoodReader), and project management (Smartsheet). Cloud-based delivery models, outstanding UI/UX, and "freemium" go-to-market models are all enabling this trend. CIO's recognize that blocking or refusing to support these applications are not winning strategies; the horse is already out of the barn. That said, smart application providers recognize that they'll be more successful if they embrace the needs of the CIO and not simply sell into the enterprise over the CIO's objections.

Work With Me, People!

So what does this mean for application requirements? There are two classes of requirements: what users need and what CIO's need. The user needs are generally well-addressed by the time a CIO sees the application. These cloud-based applications start life outside the enterprise, in the consumer and prosumer market segments. Here, functionality and usability are the lead requirements and are usually the focus of BYOA initial product releases. When these offerings enter the enterprise, the needs of CIO's become paramount. What are those needs?

Data security is a key need. CIO's are increasingly looking to file-based data security as they recognize that the solutions for securing data at the device level aren't always robust enough to pass CSO evaluation. Pure cloud-based (read: no local storage) services can rely on user authentication and session encryption to protect data. But the more common application model is a blend of cloud-based and device-based file storage. In this circumstance, authenticating against the file (via local application or via a corporate authentication server) is necessary for security.

Auditing and event logging are also important. CIO's must be able to demonstrate that they have appropriate procedures in place for safeguarding sensitive data. Audit logs (e.g., showing all activity for a given user or a given file) serve to demonstrate that a procedure is in place and can be monitored.

Automated safeguards have to be provided to reduce the risk of compromising sensitive corporate information. This is important because end users can't be relied upon to regulate their own behavior. CIO's want to know that sensitive information can't be shared with competitors and would therefore want a solution such as a "whitelist" of domains that can be included in sharing requests—with all other domains blocked by policy.

McIlwain argues that integration of these "imported" applications with existing corporate applications is important. I don't see CIO's focusing on this need, at least for some time. What makes these applications work is their simplicity—they stick to a single problem, solve it well, and do so with a minimum of end user training or behavioral change. Asking these applications to integrate with other, custom-configured applications such as those supporting HR, Sales, and Finance is asking for trouble. I would envision "islands" of data being used by small work groups within the enterprise, and any integration with corporate information stores happening in the background, orchestrated by the IT/IS organization using enterprise-focused database and content management applications.

As McIlwain suggests, the BYOA phenomenon is a savvy way into the enterprise for an aspiring cloud-based service provider. Savvier still are the startup's that find a way to partner with the CIO in encouraging enterprise adoption. Services that are loved by end users and embraced by the CIO are the ones that will see the best success in the enterprise.

In-App Payment Billing: What's In It For Me?

Anyone who's worked with wireless operators (and carriers generally) knows that billing systems are the spiral galaxies of these organizations:  ultimate supporters of life, seemingly millions of light-years across, and occasionally prone to becoming black holes that suck all matter into them.

So I was interested to read this article pitched as a discussion about the merits of billing for in-application purchases (think Farmville credits) via use of a credit card vs. the consumer's mobile phone account.  As the article points out, in-app billing is becoming the dominant form of generating payments, vs. the up-front ("buy before you try") purchase model.  That makes sense, especially given the trend toward the "freemium" go-to-market model (something I've written about previously) and the recognition of engaging consumers in your application before asking them to put down their cash.

Unfortunately, the article doesn't deliver on its promise of explaining why use of a credit card (or debit card) vs. a mobile phone number might be more useful... and for whom.  Just having the capability to handle billing for these kinds of purchases doesn't mean that consumers or developers will adopt carrier-based billing over credit/debit card-based billing.  There has to be an answer to the WIIFM--What's In It For Me--question.

For Consumers

Do you care how you're billed if you decide to make a purchase in the middle of a Mafia Wars session?  Maybe not.  But maybe you don't like having your credit/debit card information stored in someone's Application Store.  Maybe you want to make a purchase without setting up an App Store account.

What matters more to you is how problems are handled.  When you get the bill from your carrier, can you easily tell that the 99 cent charge was for the Farmville credits you purchased? How is dispute resolution handled? What happens if you get a bill for $1000 worth of in-app purchases? Can parents put a cap on the amount of payments charged in a day?

For Developers

The obvious first question for developers has to do with margin:  does the developer get a better financial deal working with the carrier vs. the App Store provider and downstream payments vendors? Does the developer need the App Store for marketing and distribution purposes? Does the developer have to develop a variant of their application for each of multiple carrier billing systems? What are the payment terms?

Building Compelling Value

Developers have seen that, under the right circumstances, they can publish applications that will generate real cash.  The success of Zynga and others hasn't been lost on this community.  The key need for anyone wanting to offer a billing system to developers for in-app purchases is answering the WIIFM question.  How (and how easily) matters as well.  But, especially given that a solution to billing already exists, the first need is to understand how a carrier's billing system is better for all parties involved in the in-app purchase transaction.