Previous month:
July 2011
Next month:
September 2011

August 2011

Change or Die

You hear the word "pivot" used a lot in start-up discussions these days.  What does the term mean?  "Pivot" is a fancier way of saying "change your direction".  It extends from Steve Blank's dictum that start-up's are "organizations in search of a repeatable and sustainable business model".  So "pivoting" means changing your business model when you've figured out that it's not going to get you where you want to be.

Pivoting requires that a company is a) paying attention to what's going on around it and b) willing to change course when circumstances warrant it.  Which brings us to Evergreen Solar and the news of its bankruptcy filing. Here's a link to the article.  What I found interesting was that the company's business model was based on two market conditions, both of which changed.

  • Evergreen's solar cell design was intended to minimize use of polysilicon, offering producers a cost advantange.
  • Photovoltaic demand was being encouraged by government subsidies in markets like Italy and Germany.

There's nothing wrong with betting on either of these market conditions... until they change.  Price decreases in polysilicon have driven down Evergreen's cost advantage.  And reduction of subsidies in Italy and Germany has driven down demand.  The combined effect has been a "perfect storm" of reduced demand and world over-supply.

I have no way of knowing if management at Evergreen did everything they could to change their business model, or were paying enough attention to market conditions, or tried to change their business model in a timely way.  It's an unfortunate ending for employees and investors, but it illustrates the importance of asking--on a regular basis--whether the assumptions of your company's business model still hold water.

When I worked at iPass, the business model was built on the assumption of a steady flow of revenue from dial-up Internet access users.  When that condition changed--and it did so quite rapidly--it left the company scrambling to replace the revenue that was being lost to broadband Internet access providers.  iPass eventually plugged that revenue hole by acquiring a managed broadband service provider, but it failed to recapture the growth that the company had when it went public.   Working through this transition at iPass taught me a lot about the importance of testing your strategic assumptions on a regular basis.


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.