Empathy, Market Research, and Product Design

Product Development: Real-World Examples

Over the years, I've had the good fortune to work with many different software development teams, all populated with bright, talented people. While equally smart, these teams sometimes took very different approaches to designing and developing products.

• Flying blind. One group of developers had really no idea how customers used their complex software product. The developers understood the basic idea of the product, and some of them had a thorough understanding of the technical minutiae underlying certain screens and tools, but over the years, as features accumulated and screens became ever more cluttered, the developers themselves lost track of what was important, what was useful, and how the customer, trying to solve a problem quickly, would use the various features of the product in a particular sequence. They were grateful whenever a field engineer spent an afternoon showing them how customers would actually go about using the product to solve a specific problem. Even with this understanding, though, it was difficult to undo the complex product architecture that had evolved, or accreted, rather, over time. The product remained a cluttered collection of screens that often bewildered new users.
  
• Academic certainty. Another group of developers based their product design on ideas from their academic research and from a very early Beta test of the product that occurred two years earlier. They were certain that the product's interface couldn't be improved, until a seasoned UI designer was brought in as a consultant, questioned their assumptions, and showed them how their pretty good interface could be made even better.
  
• Proud of complexity. Another group of developers was very proud of how complex and sophisticated their software was. Company slide presentations would boast, "Over 500,000 lines of code!" The software was so sophisticated (or perhaps so complex and finicky) that even whip-smart sales and marketing engineers had trouble getting it to work without assistance from the engineering team. Because the software was so complex, it had to be sold with lots of consulting. When the price of consulting equaled the cost of the software, and when deal sizes began reaching six figures, customers balked. Deals fell through. Complexity meant difficulty, and that didn't serve the business goals of customers.
  
• Experience-focused. Another group of developers had the privilege of working from a thoroughly designed and discussed stack of PowerPoint slides that walked users and developers through all the common tasks the application needed to support. How did they come up with slide deck? The company's founders interviewed CIOs at major companies, looking for an important problem to solve. Once they identified the problem, they began designing the interface and software architecture. Coding didn't begin until the interface had been thoroughly designed. By then, the team knew what was needed on the back-end to support the features customers would be accessing through the UI. Because the UI was "finished" relatively early in the process, documentation and training materials could be developed in parallel with the software itself. Customers knew what they were getting, and management knew that customers wanted the product being built.
  

Of all these approaches, I liked the last one—the experience-focused one—the best. The company did follow a Waterfall model of development, which doesn't offer the flexibility of more modern agile development methods, but by focusing on the end user's experience, it ensured that every software release delivered a complete set of features for performing important tasks.

This latter team certainly avoided the problems of the first team, who wasn't sure about the workflows the customer would use, and who allowed the software interface to become cluttered and confusing. Ultimately, this clutter limited the appeal of the product. Technical people didn't mind it, but non-technical people did. Even though the product had real potential as a reporting tool for management, its busy, nuts-and-bolts-first interface restricted its user base to technical end users. That limitation proved to have economic consequences.

Empathy

One of the biggest challenges all kinds of businesses face is really understanding what their customers need and want. We all approach this problem with our own particular skills and work histories which illuminate some aspects of customer needs and obscure others. And, off course, customer wants and needs are not static. They change, as technology and markets change, and as customers themselves develop new capabilities, becoming more Web-savvy, for example.

The challenge for vendors is to find a way to systematically see through this clutter and find, not merely what customers will tolerate or find useful, but what they will find empowering, indispensable, and worth paying for with hard-earned cash.

It's all too tempting for company founders to sit around a conference room, discuss their past experiences, throw up some feature/benefit charts, and decide what to build right then and there. Mostly likely the arrow they design will hit somewhere on the target, rather than flying off into the trees, but it probably note strike the bull's-eye itself. Instead, there will be enough interest and heading nodding from prospects, reviewers, and journalists, that the company will proceed with its plans, which are only 65%-75% right.

A better and more cost-effective approach is to step out of that conference room and live with customers for a while. Here's a table offering a hierarchy of investigative approaches for better understanding customers.

Research Method	Advantages	Disadvantages
Online Survey (e.g., Survey Monkey)	Fast, cheap, and easy	A poor format for questioning underlying assumptions or reading visual cues from live responses. Provides at best limited insight into physical, cultural, and political factors that may ease or retard adoption of your offering. Also, requires a good list. If you're a social media expert, and you're surveying the people who follow you on Twitter, you're really learning about yourself, rather than the vast pool of potential customers who are not like you.
Phone Interviews	The more free-form format allows you to dig deeper, explore tangents.	More time-consuming, and you'll likely have to pay the person you're interviewing for his or her time.
On-site interviews and presentations of prototypes at your office	A good chance to see how people really react to what you're building. Richer, more accurate data than you can get from a survey.	Time-consuming and more expensive. Again, you'll likely have to pay people for their time.
Interviews at the customer's site (office or home)	The best way to research a product or service to understand the customer's world. Being there is the best way to gain that understanding. You may also discover other factors and business opportunities that you would have overlooked if you had kept your distance and communicated only through surveys and forums.	Expensive and time-consuming.

What's ironic (and somewhat frustrating) is that founders and investors will often dismiss face-to-face interviews and prototype-testing as too expensive and not worthwhile. Loic Le Meur, for example, for whom I have a lot of respect, once compiled a list of suggestions for start-ups that included:

7. Don’t spend time on market research. Launch test versions as early as possible. Keep improving the product in the open.

I think this approach can work with public applications like Twitter applications and social media networks like LinkedIn. I don't think it will work with more complex applications, such as business workflow or, say, healthcare payment acceleration applications, where the number of variables to get right is high, and the development costs are likely to be significant. And obviously, if your solution involves on-site hardware, giving away free test versions is expensive, even if customers agree to install them, which is doubtful.

Another limitation of this approach is that more or less consigns you to a freemium business model, because it requires lots of users testing a product to refine it. This strikes me as the tail wagging the dog. Companies should select their business model (how they'll make money) independently of how they'll conduct research. I would advise against automatically adopting a freemium model merely to avoid the expense and hard work of upfront research. Yes, by all means, always listen to customers and improve your products and services accordingly (as the freemium model encourages). But adopting the freemium model—or any other revenue and distribution model—should be considered a strategic and game-changing chess move, made at the proper time and the proper circumstances, not simply a default behavior (like P-K4 [a conventional chess move, for you non-chess players]) of young companies.

A third problem with this approach, as I mentioned in an earlier blog post, is that refining over time takes time and money. It might be more cost-effective to sit down with prospects up-front, really narrow down what the product or service should be, then refine it over time, having started from a position much closer to the bull's-eye.

A fourth problem is that some customers are simply not going to try your offering, even if it's free and it looks cool. Good luck getting someone in upper management or on a busy factory floor to even look at what your small, unheard-of company is offering. More likely, you're going to have to approach them, perhaps in the company of a third-party research or design firm, and there's going to have to be a financial incentive. You're going to need to buy their attention, but chances are, the expense will pay off for you handsomely. You'll reduce development costs and bring your offering to market faster, perhaps even with some endorsements from the customers you've interviewed.

The goal, here, is empathy. Not just a list of features, but a real understanding of the environment in which your product or service will be used, an understanding of the pressures your customers are facing, the cultural factors driving or inhibiting adoption of what you're offering, and the best language and visual interface with which to present your solution. No matter how talented a founding team is, they're simply not going to derive all that from a few long days locked in a conference room. Getting in front of customers repeatedly, gauging their reactions to prototypes, and really listening are what's required.

Outcomes

So how did the companies I mentioned back at the beginning end up faring?

• Flying blind. This company's core technology that the business continues, though opportunities have been missed, and a major engineering project (developed by a senior programmer who was unfamiliar with the market) ended up getting scraped. Recently, though, under new management the company upgraded its old flagship product and aced a major product review. So, somehow, they're soldiering on.
  
• Academic certainty. Product delays, in large part caused by outsourcing to the wrong company, resulted in lost sales, dwindling revenue, and dwindling staff. Eventually the company was sold. The product had to be rewritten (mostly from scratch, I believe) to catch up with current technology trends.
  
• Proud of complexity. The impressively complex product never turned out to be a big seller. Fortunately, the company had acquired other related products, and the company's engineering team developed these into the best products in its industry. However, the company itself never became profitable. It had gone public during the bubble. It stock price hovered in the $1-3 range for many years. Eventually the company was acquired.
  
• Experience-focused. Within a few years, this start-up, while still private, was acquired by a major Silicon Valley technology company. A happy ending.
  
  

Twilight for Ad-based and Freemium-Model Start-ups

A recent article in the New York Times breaks the news that "Angels Flee From Tech Start-ups": angel investors (wealthy individual investors) have lost money in the stock downturn and are no longer as willing to fund early stage companies. Angel investors typically make investments ranging from $10,000 to $1 million to help companies when they are just beginning. Once a company, applying its angel funding, has built a functioning prototype and perhaps even won a few customers, it can proceed to ask for more substantial funding—perhaps $1-5 million—from venture capitalists (VCs).

But, of course, getting VC funding is getting a lot harder, too. Ask anyone in a start-up these days, and they'll tell you that the spigot of VC funding has been turned almost entirely off. VCs like Sequoia Capital recognize that difficult times call for tight fiscal management (see Sequoia's famous Presentation of Doom to get a sense of the VC community's apprehension about the economy).

Even aside from the plummeting economy of the past few months, the angel/VC model for starting a company has been becoming increasingly problematic. Angels and VCs put money into a company, of course, hoping to get a substantial return, often 10x or more, on their investment. But as Om Malik pointed out in his recent post, "IPO Drought Hides Bigger Tech Woes," only a handful of companies from any industry have gone public over the past few years. He writes:

Look at some of the numbers: in 2008 there were nine IPOs in the technology, telecom and media (TMT) sector vs. 77 in 2007. In 2008, there were only six VC-backed IPOS and only one from Silicon Valley.

Without a viable IPO market, the only way a start-up can deliver a big return to investors is by being acquired. But if acquirers know the start-up has no alternative but to be acquired, they can stall negotiations and work out a low price. And large companies, of course, can only acquire so many small companies. Many small, worthy companies will likely go begging for suitors. Which is another way of saying that many VC investments, however well managed, will not deliver their expected returns.

The classic Silicon Valley model of investing in a company, growing it over some number of unprofitable years, and then exiting through an IPO or M&A activity is looking increasingly sketchy.

Here, then, is the lunar landscape start-ups find themselves inhabiting:

• A moribund IPO market
  
• Declining consumer spending
  
• Business spending curtailed
  
• Inventories growing
  
• Non-essential purchases by consumers and businesses deferred indefinitely
  

No wonder VCs are holding onto their cash. Pouring $5-20 million into a company that remains unprofitable for years just doesn't make a lot of sense in this environment.

Web 2.0 Business Models

The lack of angel and VC funding for has several implications for the types of business a software start-up can pursue. Or perhaps, without wanting to sound too catty, I should say that the lack of angel and VC may force a growing number of start-ups to behave like traditional businesses.

Far too many start-ups these days build technology (typically a Web site) and assume that they'll find the business model later, maybe much later, years later, if ever. I'm not opposed to this approach outright. Twitter came about this way because a company was willing to invest in a technology without a clear business case, and I think the communication on Twitter can be powerful and useful. But I think the high tech industry loses something—more than a lot of money, I mean—when the normal model for launching a business is, "We'll figure that out later, and besides, we can start selling ads next quarter." The industry's business acumen is becoming dull or at least severely constrained.

A friend recently directed my attention to a blog post, "Web 2.0, Revenue Models and Profitability: A Web 1.0 Comparison," which summarily points out that the Web 2.0 Emperor of Revenue is looking a tad bare:

"As we recently learned that Digg was still losing money on revenue numbers that look quite paltry, it occurred to me that Digg and some of Web 2.0's other hot young startups really aren't hot young startups anymore.


Facebook was launched in February 2004. Digg was launched in November 2004. Twitter was launched in July 2006. Facebook is almost five years old, Digg is just over four years old and Twitter is two and a half years old.


They all share a common trait: none has developed into a self-sustaining business whose financial future seems assured.


One of Web 2.0's biggest myths: it's far easier and far cheaper to get a startup off the ground today than it was a decade ago.


Citing the wide range of mature, open-source technologies and the abundance of talent available today, Web 2.0 proponents have told us that taking an idea from concept to reality, getting it launched and growing it can be a cheap affair.


If that's the case, one would logically assume that today's Web 2.0 startups would have developed into lean, mean revenue-generating machines. Instead, we see the exact opposite."

The ad revenue many of these companies generates almost seems like an afterthought to me, as though the management team was saying, "Well, we've got all these users on our site. We might has well make a little money off them by advertising." Revenue isn't built into the business; it's tacked on, literally as far as HTML goes, in the form of banner ads and text ads. These companies have a technology model, they also probably have service and community models, but they don't really have a business model, per se. The business aspect of their businesses is decidedly an ancillary concern.

Risks for Freemium Businesses

A popular business model among Web 2.0 companies is the so-called freemium model, based on a coinage by Jarid Lukin of Alacra. As Amy Shuen explains in her book, Web 2.0: A Strategy Guide, the term "freemium" was first introduced by venture capitalist Fred Wilson on his blog, A VC, where he described the model this way:

Give your service away for free, possible ad supported but maybe not, acquire a lot of customers very efficiently through word of mouth, referral networks, organic search marketing, etc., then offer premium priced value added services or an enhanced version of your service to your customer base.

The word "freemium" is a portmanteau word combining free + premium. Offer a free service, then charge for Pro services you develop over time.

From a business point of view, the freemium model has clear advantages over simple ad-based models, in that Pro features can deliver real value that customers will pay for, regardless of whatever's happening in the pricing and ROI of online ads.

But the freemium model poses its own risks, which are exacerbated by the tight money market and the widespread disappearance of discretionary spending:

• It can take quite a while to develop services to the point where add-on Pro features are worth paying for. If it takes a start-up 12 months to develop its community, 6 months for its Pro features to mature and begin gaining traction, and another 6 months for the Pro features to catch on with users (in an economy where much non-critical spending is being cut), does the start-up have enough money in the bank to survive? Have its investors run out of patience?
  
• While the company is growing its community to attract enough purchasers of Pro services, its data center needs and operating costs continue to grow. If not managed shrewdly, these mounting costs, along with increased tech support costs for Pro services, may erase any financial gains realized by revenue from Pro services.
  
• The company has to find the right dividing line between free and Pro. Give too much away, and the company won't make enough money from the Pro. Give too little away, and the company won't attract a sufficient number of free users to sustain the community and its services in the first place.
  

I think there's lots to admire about freemium sites like Flickr, but less mature, freemium-based start-ups may find themselves racing against an unforgiving clock.

What Start-ups Founded in 2009 Will Likely Look Like

Without the luxury of $5 million in the bank (or even $1 million in the bank, courtesy of angels) to grow a user base that doesn't cover its own costs, new start-ups will have to focus intensely on revenue generation and profitability from the get-go.

This is not a bad thing. It is, oddly enough, an unfamiliar thing to many people founding start-ups. The requirement for short-term revenue might even strike some founders as mind-bloggling, unfair, and needlessly constraining.

To me, such a reaction signals how dependent the high tech industry has become on VC funding—on having a sinecure, more or less, for creating and selling advanced technical solutions. I'm not against VC funding by any means, but I think it's troubling that so many people in technology have difficulty even considering building a company that, like most companies in most other industries, actually makes money sooner than later. And I think, as the Centernetworks author noted above, it gives lie to the Web 2.0 idea that it's faster and easier to build a business thanks to LAMP stacks, affordable hardware, etc. People using those technologies aren't building profitable businesses. They're delivering services to growing communities, and often as not losing money hand over fist.

Striving for short-term revenue (perhaps, 6-12 months, based on the credit limits of the founders credit cards and the balance in their savings accounts) and possibly even short-term profitability (12-24 months!) will require significant changes in the thoughts and actions of founders.

But the high tech industry has worked through transformations of similar difficulty over the past decade or so. Remember when you could take 18-24 months to develop your first product? Now it's weeks or a few months, at most. Remember rigid waterfall development cycles? Now agile development is becoming the norm. Remember lavish tradeshow booths and offset-printed brochures? Now you if you market through tradeshows at all, you're likely using a popup booth and telling people to download the PDF. Or you're reaching customers through Web seminars, forums, Twitter, and Skype. I expect that, having endured the brutal realities of 2009, a growing number technologist will come to embrace the new, old way of thinking about business and revenue.

Focusing on proximate or even immediate revenue generation has several implications for a company's business model and its founding team.

1. The company may need to begin with consultative selling, so the founding team may need to include one or more people who can sell services and manage client interactions. Instead of waiting 6-12 months to hire a salesperson, the company might include one in the founding team.
   
2. Companies will not have the luxury for long iterative development cycles; they'll still likely use agile development and iterate, but it now makes more economic sense than ever to invest in customer experience analysis, really analyzing what customers need and want, rather than trusting the founders' hunches and correcting misperceptions over a matter of 6-9 months.
   
3. Faced with curtailed spending by businesses and a wealth of sophisticated technology offerings from both large and small technology vendors, a start-up's best bet may be to focus on narrow problems specific to a particular industry. might be a good idea to tackle a difficult problem that requires domain expertise and tenacity—more expertise and tenacity than large vendors have been willing to contribute. Implication: the founding team will likely then include one or more members with deep expertise in a vertical market.
   
4. If start-ups have adequate resources, they should consider a blue ocean strategy, creating a new uncontested market that solves problems not addressed by other products and services currently available.
   

These implications and market pressures apply to start-ups that don't have the luxury of having millions of dollars in the bank. They obviously don't apply to existing companies that are already well funded. And I'm far from expecting or hoping for the demise of any big-name Web 2.0 companies like Digg or Twitter. In fact, I expect Digg and Twitter and other big-name Web 2.0 properties to survive, in part because they're important enough in the technology ecosystem, which includes the business managers who effect M&A transactions, to last until they find some sort of shelter. (I'm titled this blog post "twilight," not blackest midnight and not noon. Some entities will linger for a long time. But things that were possible earlier, will likely not be possible again soon.)

But for every Digg or Twitter, there are probably dozens of smaller, less well-known Web 2.0 companies that will find it increasingly difficult to survive. I wish them well. At the same time, I hope that most of the teams founding start-ups this year will not follow their example. Instead, I would encourage founders of new start-ups to think more like traditional business people.

If you're not taking in VC funding (because you can't get any), you don't have the pressure of delivering a 10x return in a few years. Instead, you face the different, but still daunting challenge of growing a profitable business. That's hard to do in any market, but it's a worthy undertaking, no less noble, and no less difficult.

Founders, listen: Business is hard. You're smart and motivated. Get on with it.

Tips for Running a Successful Web Seminar

With travel budgets tight and the need for lead generation more pressing than ever, I expect that this year we'll see more interest in Web seminars than ever before.

In the late 90's, I worked for one of the first Web conferencing companies, so I have over a decade's experience seeing what works and what doesn't in Web seminars.

Here are tips I've picked up over the years. Feel free to comment and add your own.

1. Inform, Don't Sell (Well, Don't Sell Too Much).

People attend Web seminars to learn something: news about market trends, tips for using a software program, best practices for their profession—something that's genuinely useful. They might assume that you're going to do some selling in the course of your presentation, but if you lay on the sales pitch too heavily, you'll turn off your audience. And they'll show it by hanging and disconnecting from the session.

If you're presenting genuinely interesting information is a compelling way, you'll lose only a few audience members in the course of a 30-60 minute presentation. If you're dropping audience members every few minutes, it's time for you to go back and rethink what you're presenting and how.

2. To Inform, Present New Information That's Not Readily Accessible.

This is where guest speakers come in. Opening your Web seminar with a 20-minute presentation by an analyst or expert sharing new research is a great way to drive up registrations and keep your audience engaged.

The other advantage to guest speakers is that they often have their own mail lists and promotional materials, which can dramatically bolster the size of your audience.

3. Keep the Format Lively and Varied.

Studies show that audience members begin to lose interest in a presentation after hearing only one voice talk for seven minutes, so never let one person talk for more than five or six minutes straight. Be sure to have at least two people in the seminar, even if one is a moderator who only introduces the main speaker, then interjects comments and questions from time to time.

Some of my most highly rated seminars followed the format of a radio talk show: a conversational tone, real back-and-forth dialog, a little humor. (After all, what would you want to listen to for 45 minutes in your office? A dry presentation of a script or two people really engaged in conversation?)

Here's a format that's worked well for several of my clients:

• 1-2 minute introduction and overview by moderator
  
• 20-30 minute presentation by guest speaker with comments and interjections by moderator or another speaker
  
• 10-15 minute product and service overview by sponsoring company; if the company is promoting software, a live demo is worth a thousands words of narration
  
• 5-15 minutes open Q&A with audience members
  
• 1 minute close by moderator; if the seminar is part of a series, point audience members to a Web page listing other events
  

4. Give Audience Members a Chance to Ask Questions.

Whether they type questions into a Q&A feature of your Web conferencing software or ask questions at the end, do give audience members a chance to ask questions, express doubts, and dive deeper into the subject matter.

5. Give Audience Members Extra Time to Get the Software Started.

Inevitably you'll have audience members racing to join your event after getting out of a meeting or coming back from lunch. Some of them won't have downloaded or tried out the seminar software ahead of time. Give them a few minutes to get through the download and start-up process. Greet your audience a few minutes before the event, and then every minute or so let them know that you're going to start a few minutes after the hour to give everyone a chance to join the event.

6. Always Let Audience Members Know They've Come to the Right Place, and Where to Go for More Information.

You don't want audience members wondering if they've come to the right place when they connect to your seminar. Fifteen minutes before the seminar starts, post a welcoming slide identifying the title and time of the event, along with contact information for technical support or questions.

In the final moments of the seminar, display a slide or Web page offering phone numbers, email addresses, or URLs where people can get more information or contact the presenters.

7. Avoid Interruptions.

Always mute the audience's phone lines during the main presentation. Otherwise, you'll have some audience members conducting side conversations in their offices, ignoring your requests to mute their lines, and turning your carefully planned event into a cacophonous jumble. That ping-ping-ping sound is the phone system letting you know that other audience members have lost patience and are hanging up.

So keep the audience phone lines quiet until the Q&A session, and do everything possible to keep attention focused on the presentation itself.

By the way, be wary of those free conference call services. I've found them to be unreliable. One of them—a popular, free service used by many IT companies—disconnected our main guest speaker, just as he was beginning his presentation. It took him several minutes to rejoin the seminar. The other speakers and I were able to cover for him, but it was nerve-wracking (and potentially a waste of a speaking fee).

8. Rehearse. A Lot.

I can't stress this enough. I recommend at least three complete run-throughs of any seminar. In the course of rehearsals, you'll discover that the flow of your presentation can be improved, that some material is redundant, and that other material is cryptic. Especially if you have two or more speakers, you'll want to rehearse transitions from one section to another.

I ran a Web seminar series for a client last summer. We had different guest speakers every week for several weeks in a row. (We had just launched the company, and we wanted to make a splash.) We rehearsed daily, sometimes twice daily. Everyone agreed that these rehearsals dramatically improved the quality of our presentations. They also gave us an opportunity to get to know our new business partners and to better understand how they presented their offerings to customers.

That's my list. What's on yours? Post a comment, and let me know.

Green IT: Now More than Ever

"Each day brings further evidence that the ways we use energy strengthen our adversaries and threaten our planet. . . . We will build the roads and bridges, the electric grids and digital lines that feed our commerce and bind us together. We will restore science to its rightful place and wield technology's wonders to raise health care's quality and lower its costs. We will harness the sun and the winds and the soil to fuel our cars and run our factories. . . . All this we can do. All this we will do."

— President Barack Obama, Inauguration Speech

In yesterday's historic inaugural speech, President Obama set a new direction for America, or perhaps I should say he returned America to its true direction—a course where progress is achieved through responsibility, trust, compassion, creativity, and hard work.

Like many people, I was pleased to hear Obama's pledge to restore science to its rightful place. For the past eight years, the federal government has rejected science and its demonstrable truths for ideological talking points and purblind dreams of grandeur. One of the areas where the administration's suppression of science has been most publicized and most perilous is global warming. The administration has stalled on policy and questioned what no longer bears questioning.

If you would like a vivid reminder of just how compelling the evidence is, how fraught the dangers to human society and natural habits, and how galling governmental inaction has been, I strongly recommend a short, highly readable book written a few years ago by New Yorker writer Elizabeth Kolbert: Field Notes from a Catastrophe.

The title might strike you as alarmist, but by the time you're done reading this book, I suspect you'll be alarmed—and frustrated, too, by our country's inaction.

As the phrase "field notes" suggests, Kolbert reports on research being conducted in the field: in Alaska, Greenland, England, the Middle East, and elsewhere. And the findings of this research are damning:

• The earth is now warmer than it has been for hundreds of thousands of years.
  
• Since 1979, the perennial sea ice in the Arctic has shrunk by roughly 250 million acres, an area roughly "the size of New York, Georgia, and Texas combined." The loss of this ice reduces the earth's ability to reflect sunlight; instead of reflecting light, the exposed seas absorb sunlight's energy, further heating the planet and melting more ice.
  
• After studying satellite data, James Hansen, a NASA official, has warned that if greenhouse gases aren't controlled, the Greenland ice sheet could melt, potentially, in time, raising sea levels 23 feet.
  
• Nineteen biologists from around the world studied the effect of global warming on eleven hundred species of plants and animals. If the species proved to be mobile, 15 percent of them would be "committed to extinction." If the species were stationary, the extinction rate rose to 37 percent.
  
• Heavy rainfall is expected to intensify in some of the most densely populated areas on the planet, such as the Mississippi Delta and the Thames basin. By 2080, England will likely be experiencing so-called century floods every few years.
  

The data goes on and on. The consensus among the scientific community is, for all intents and purposes, universal. The earth is heating up, the heating process has acquired a momentum of its own and will continue for decades, even if we were to curtail the emission of greenhouse gases immediately. But we're not curtailing them, and the Bush Administration had no interest in doing so.

I recently read the Harmon translation of Kafka's The Castle, and the evasiveness and circularity of Bush administration officials in their interview with Kolbert reminded me of scenes out of Kafka, minus the droll humor.

"[Under Secretary of State for Democracy and Global Affairs] Dobriansky began by assuring me that despite how it might appear, the Bush administration took the issue of climate change 'very seriously.' . . . At one point, I asked the undersecretary if there were any circumstances under which the administration would accede to mandatory caps on emissions. 'Our approach has been predicated on: we act, we learn, we act again,' she said. In response to a question about how urgent the problem of stabilizing emission was, she replied, 'We act, we learn, we act again,' and in response to a question about what would constitute a 'dangerous' level of CO₂ in the atmosphere, she said, 'Forgive me, I'm going to repeat myself: we act, we learn, we act again.'"

I take it back: I've been unfair to Kafka's characters. Their evasions are far richer and more subtle than anything offered by Dobriansky and other Bush-era flacks.

But here's the thing: what are you doing about global warming in your business? Don't fall into the trap of "I read, I groan, I read again." Take action. Make green IT and green practices part of your strategic plan this year.

And if you need motivation—if you want a good jolt of pursued-by-a-grizzly-bear variety adrenalin for your and your staff—buy and read Kolbert's excellent book. It's available from Amazon, Powell's, and probably your local independent bookseller, as well.

Questions Worth Asking at the Beginning of the Year

Strategic Planning

1. Has my company identified 6-10 major objectives for the year and identified 3-6 supporting milestones for each objective? (For more about this, click here.)
   
2. Has this list of objectives and milestones been broadly communicated throughout the company?
3. Are directors and managers using this information to drive their departmental planning and budgets?

Product and Services Development

1. Has my company identified the user experiences that our products and services should provide?
2. Have these experiences formed the basis for development of products, including the identification of features and benefits?
3. Does my company have a process in place for assessing customer experiences and ensuring they meet our goals?

Strategic Communications and Customer Management

1. Does my company have up-to-date messaging guidelines available for all relevant parties, including not only executives, marketers, and sales people, but also all the other employees who might be interacting with customers and the public through forums and other social media?
2. Does my company have a systematic approach for monitoring social media interactions and responding promptly to situations that arise in these ad hoc communications channels?
3. Does my company have IT systems in place to integrate outbound communications with CRM and other internal IT systems?

Two Predictions for Open Source Software in 2009

Prediction #1: The adoption of open source will accelerate in 2009.

Open source is on a tear. It's being adopted more quickly and more widely than ever before. Evidence: In November, Gartner announced survey results that found that 85% of enterprises are already using open source software, and the remaining 15% plan to start using it soon. (And my guess is, a good portion of that 15% are already using it, but management doesn't know.)

On the Optaros blog, Bruno von Rotz offers a good summary of what's happened in 2008 in the world of open source, and a lot of it is encouraging news for open source vendors (sales growing faster than expected, more rounds of funding, etc.).

With companies in all industries hitting the pause button on spending, open source should prove especially attractive in 2009. If you're a project manager, and you're being asked to do more with less or even with practically nothing, you're likely to take a good, hard look at open source, at least for a pilot project, even if you've had qualms about the maturity or stability of open source products in your area of expertise.

Earlier this month, Gartner analysts advised their clients to prepare two IT budgets: one with a 2% increase in spending, the other with a 20% decrease in spending. If your IT budget really does get slashed by 20% or more, you'll have little choice but to consider software products that offer a basic version for free, and whose paid products have prices that will turn out to be highly negotiable.

Bottom line, then: 2009 will create many new opportunities for open source vendors to get their feet in the door.

Prediction #2: Many open source vendors will continue to struggle, and some well-known vendors will shut down.

Unfortunately, getting your foot in the door is no guarantee of success. Despite the impressive adoption of open source and the continued rounds of funding, many open source vendors are struggling to make money—in some cases, even after receiving many tens of millions of dollars of VC investments. The sad truth is that even some of the well known names in open source—companies with good products and impressively high numbers of downloads—are having trouble converting those downloads and installations into a viable business.

Part of the problem is that the free version of products are often good enough to satisfy customer requirements. If customers don't have to spend money to get features, and if the product is reliable enough (or not mission-critical), customers won't spend money on licensing and support.

Part of the problem is that while the download numbers are growing, the company has yet to find a repeatable sales model for converting downloads to sales; end user requirements are simply too varied to build a profitable business.

Part of the problem also is that free has to compete with cheap (or at least comparatively inexpensive). On the Open NMS blog, Tarus Balog recently pointed out that open source network management products have to compete with low-cost, easy-to-use products like Solar Winds. He's absolutely right. And Solar Winds has been on its own tear for many years, now. Another up-and-coming NMS platform is AdventNet's ManageEngine, which knits together network management and service desk functions into an easy-to-use, highly affordable whole. AdventNet now has tens of thousands of paying customers for its network management products—an enviable achievement from the point of view of many open source vendors. If price is what's driving you to open source, and you're not particularly interested in having access to a product's source code, you may end up choosing one of these highly affordable non-open source alternatives instead.

Another part of the problem with open source companies comes down to simple execution: building what customers really want rather that what the core development team feels comfortable with (especially if the company is VC-backed and has real targets to hit); solving customer problems promptly and effectively through support, documentation, and training; marketing well; etc. Most open source companies are developer-led organizations, and some (decidedly not all, but some) developer-led organizations fall into the trap of expecting their potential community to share the internal team's own predilections and priorities. (If you hear an engineering manager saying something like, "That should be reasonable, it shouldn't be that hard for the customer to figure out," stop the design discussion right there: customers should have to figure out almost nothing.)

A few vendors may find financial salvation by converting or substantially augmenting their open source business with a SaaS business and close deal that are SaaS subscriptions rather than on-premise software licenses. But for other vendors time will eventually run out. Investors will shift new funding other more viable ventures. Staff cuts will paralyze progress. Projects will be left to linger on SourceForge.

This is why I expect 2009 to be a mixed year for open source vendors. It will be a year of unprecedented opportunity for most, and a year of hard reckoning for some.

Zoho CloudSQL: An interview with Rodrigo Vaca

Earlier this week, Zoho announced CloudSQL, a new SQL interface to Zoho Reports, its popular Web application for online reporting and business intelligence. Zoho applications (in case you haven't heard of them) are credible alternatives to Google Software-as-a-Service (SaaS) applications such as Google Docs. Launched three years ago, the suite of Zoho applications has grown dramatically in number of applications, richness of features, and size of its user base. The company now boasts over 1 million users for its 19 applications. More applications are on the way.


Here's how Rodrigo Vaca, Zoho's Director of Marketing, described CloudSQL in a blog post earlier this week:

Zoho CloudSQL is a middleware technology that allows customers to interact with their business data stored in Zoho through the familiar SQL language. Customers are able to access Zoho cloud data using SQL on both other cloud applications as well as through traditional on-premises software.

At a high-level, Zoho CloudSQL serves as the bridge between the external application and the data stored inside Zoho. It receives the query in SQL, interprets it, delegates queries and aggregates results across the Zoho services.

There are in particular 3 things that stand out about Zoho CloudSQL:

• It's the first technology that allows customers to interact with their data on the cloud, from another cloud application or from an on-premises one through real SQL.


• It supports multiple SQL dialects. We support all the major (and even some not so major) ones: ANSI, Oracle, SQL Server, IBM DB2, MySQL, PostgreSQL and Informix.


• With our JDBC/ODBC drivers, developers can access data in the cloud just as easily as if it were stored in a local database.
  

A Quick Interview
I got in touch with Rodrigo Vaca to ask him a few follow-up questions.

JB: From your announcement, I'm gathering that CloudSQL is a SQL-based service for accessing data in Zoho applications. The interface will be of interest to engineers working on integration projects where they would like to simply work with SQL queries, rather than dealing with JSON or RESTful data access. Is this an accurate characterization?

RV: Yes, that's accurate. Zoho CloudSQL is about making the data in the Zoho cloud more accessible for our customers. SQL is something that most corporate developers know and are familiar with.


JB: The diagram on your December 2 blog post shows CloudSQL being able to access other Web services. Are there non-Zoho Web services you plan to support? Say, any Web services from StrikeIron, ProgrammableWeb, or even Google, etc.?

RV: Ah! You were paying attention! You noticed something that most other people missed. Yes, Zoho CloudSQL can be extended to non-Zoho services. At this point we're not focused or actively pursing that, since we need to first make sure that other Zoho services are accessible through CloudSQL first.

JB: Finally, I was intrigued to see that you're doing entity-mapping, which makes sense. It makes me think of the work Microsoft has been doing in its Project Astoria group (creating a framework now called ADO.NET), where they're using entity mapping to present a non-SQL-based interface to SQL-Server data. Do your RESTful APIs make use of this entity mapping? Does Zoho have plans to publish an Astoria-like interface to Zoho data?

RV: Our REST API should provide all the necessary details for developers, so we don't have plans for entity-mapping like Astoria. We would recommend CloudSQL, as the standard interface for developers, especially as we increase its coverage across Zoho applications.

To learn more about CloudSQL, visit this Zoho wiki page here.