Friday, February 27, 2009

Socialcast Helps Teams at NASA Communicate More Easily and Capture Tacit Knowledge

NASA, where the hard work literally is rocket science, depends on timely communication: not just between control centers and distant space craft, but also among workers distributed across NASA's ten major R&D centers. Recently the issue of inter-center communication has become especially important, as NASA undertakes its Constellation program to update the Space Shuttle. Previous NASA missions were usually developed at a single NASA center. The Constellation project, a major technical undertaking, spans centers and requires far-flung research and engineering teams to work together efficiently.

So it behooves NASA to find broadly applicable solutions for employees and contractors to exchange information—exchange it, and record it, too, for another transformation NASA is facing is the aging and retiring of its workforce. The average NASA employee is nearly 47 years old and has worked at the organization for 17 years. There's a lot of NASA history and knowledge walking around in lab coats and business casual. And many of those employees are beginning to retire. To preserve the organization's intellectual capital, NASA needs to find a convenient, unobtrusive way for employees to record and share their tacit knowledge.

These challenges were evident to a group of NASA JPL engineers who attended the KM World conference back in 2007. There they heard a talk by Tim Young, CEO of a social networking platform solution called Socialcast. Tim talked about the benefits of Socialcast, a SaaS service that enables company employees to post status messages, ask and answer questions, share documents, and so on.

The NASA engineers were intrigued and decided to launch a pilot project. Celeste Merryman, a pilot manager for Computer Sciences Corporation (CSC) at NASA JPL, and Douglas Hughes, a project manager at NASA JPL, ran the pilot project, which involved customizing Socialcast for the NASA environment. The new SaaS service was dubbed NASAsphere.

Now the results of that NASAsphere pilot are in, and they're quite compelling.

  • NASAsphere participants invited 398 of their colleagues from around NASA, with 55% acceptance rate.
  • Within the 60-day span of the pilot, the NASAsphere community grew from 78 activated accounts to 295.
  • Communications truly crossed geographic centers. When employees posed questions, 93% of the answers came from users at remote locations. By the end of the pilot, at least one person from every NASA center had participated in the NASAsphere community.
  • A survey of NASAsphere users found that 52% recommended the platform be implemented for contractors and civilians, in addition to employees.
  • In the same survey, 45% of users said they expected they would contribute to the NASAsphere platform weekly.
  • Not surprisingly, the report recommends a broader implementation of the Socialcast solution.
For more details about the pilot and its results, check out the NASAsphere SlideShare presentation here or the final NASA JPL report here.

Thursday, February 26, 2009

Cloud Computing Predictions, Revisted

All right, I'm going to strike the tentative tone that had crept into one of my predictions for cloud computing in 2009. When I read about the success of Marketo, Central Desktop, and others SaaS vendors, I can more evidence of young SaaS vendors racking up impressive sales by solving important business problems. So I'm revising prediction #4 to read:

Small vendors who apply their domain expertise to bring the power and convenience of cloud computing to business areas underserved by IT, can gain market traction and growing a profitable business by delivering exceptional operational business value to customers.

I still believe that, as one commenter to this blog put it, "PaaS is a tough nut to crack." But SaaS offerings that are focused and immediately useful should have a very good 2009. Which, of course, is wonderful news.

Tuesday, February 24, 2009

LiquidPlanner Integrates Micro-blogging and Time Sheets with Statistically-based Project Management

In a blog post last week, I cited LiquidPlanner as a SaaS company that was tackling an important business problem—project management— in a new way (applying statistics to change guesses into estimates, thereby dramatically increasing the accuracy of project plans).

Today, the company announced its 2.0 release. I'd like to call attention to a couple of new features in the release.

Integrated Microblogging

LiquidPlanner has integrated micro-blogging in its project management interface. This makes a lot of sense.

Thanks to Twitter, a growing number of people recognize the power and convenience of micro-blogging (posting short messages, perhaps containing links, that can be read by large numbers of people who opt in). Twitter, of course, is mostly a public forum, the exception being any hypothetical network of users who all password-protect their updates.

Internal business communications call for a separate, parallel channel to Twitter. Hence the launch of Yammer, a company that replicates basic Twitter functionality for closed communities, such as companies.

But Yammer's tweets or blog-posts aren't integrated with any other business software. It's unlikely that Yammer users are going to abandon Twitter, so it's entirely possible that someone might end up using:

  • Twitter for the public commmunications
  • Yammer for internal communications
  • 37 Signals or Microsoft for internal project management

with no integration between Yammer and the project management program.

LiquidPlanner offers the advantages of Yammer—secure internal microblogging—with the added advantage of context and linking: I see find all the micro-blog posts related to a specific project, for example. Or put another way: now micro-blogged posts become another convenient information source for tracking the development of projects.

LiquidPlanner calls this feature "workplace chatter." It looks like this:



Users can see everything, including "chatter" and design documents, related to a project.



Time Sheets

Another new feature is time sheets. LiquidPlanner 2.0 offers built-in time-tracking, obviating the need for separate software to track the hours that people are putting into a project. Time-tracking data can be exported in standard formats for use in HR and billing applications.

Putting It All Together

These new integrated features make a lot of sense. In addition to posting documents and status, why not blog about a project and track hours, all in the same program? LiquidPlanner creates a workspace where customers can manage and record everything having to do with a project.

I expect we'll see more integrations like this in the SaaS market.

Disclaimer: LiquidPlanner is not a client.

Postscript to disclaimer: For information on becoming a client, contact me.

Which Do You Offer a Weary Traveler: A Unicycle, a Bicycle, or a Segway?

A guy is walking down a long road. He's tired.

Three trucks pass him, then come to a screeching halt. The drivers hop out. They open the backs of their trucks. They're salesmen!

The first driver offers the traveler a unicycle. It's low-cost and easy to maintain, possessing only half the tires and less than half of the moving parts of a bicycle. It doesn't require any electrical charging system or cables. If you forget to plug it in when you go to bed, it's still ready for use in the morning. Very nimble. Low cost. Agile. And it's pretty cool, too. How about it?

The second driver offers the traveler a bicycle. Of course, everyone knows how to ride a bicycle. Yes, it has more moving parts than a unicycle, but it's easier to use. Yes, you still have to pedal, but how hard is that? It's easier than walking if you're tired.

The third driver is wearing a suit, and he comes gliding up on his Segway. Here's the best choice of all, he says. Turn-key solution. No walking required. Minimal training. The Segway handles all the forward motion for you. You just stand still. Yes, it's more expensive than the other solutions, but you end up doing less work, and you'll have more energy for other activities. Now, let's talk about a charger and a service contract.

Which vehicle does our weary traveler choose?

Which business model would you bet on?

Unicycle Products

Unicycles are exciting and fun, but they require our traveler to learn new skills. I'm going to bet that most people reading this post think that the unicycle is the least likely choice for our traveler.

Yet how many companies bet their business on weary, overworked customers learning new skills (programming languages, complex UIs, etc.)? The novelty and supposed low cost of an approach blinds companies to how things look to a customer. Even if the customer isn't consciously opposed to novelty, he or she is just not likely to get around to learning new skills in order to realize the vision promised by a vendor.

Segway-style Products

At the other extreme, we have Segway-style products. Ingenius. Turn-key. More maintenance overhead. If a novel programming framework is a unicycle, an enterprise software suite from SAP or Oracle is probably more like a Segway. Lots of features. Minimal tinkering for end users. High cost.

Bicycle Products

The bicycle is somewhere in between. Our weary traveler still has to do work to ride a bicycle, but he already has the skills to do it. Yes, there's potentially some maintenance involved, but bicycles are so ubiquitous, there are repair shops everywhere. And maintenance costs shouldn't be exorbitant. So, yes, the bicycle doesn't eliminate all work, but the traveler can begin riding right away without breaking his budget.

My guess is that he hops on the bicycle. (Unless he's also wearing a suit and has the budget and corporate mandate to go for the Segway.)

(In 2007, 18.2 million bicycles were sold in the United States.)

Moral: Even in a tough economy, a bare-bones, low-cost product will have difficulty gaining traction if it requires customers to change their habits and do things they've never done before.

As always, comments welcome.

Unicycle photo Creative Commons Copyright (some rights reserved) by Julian Meade.

Friday, February 20, 2009

Two SaaS Companies that Solve Business Problems for Customers

In a couple of recent blog posts (here and here), I raised the question of what type of cloud computing start-up would be likely to succeed in today's business environment, in which companies of all sizes are interested in cutting costs and minimizing risks. I suggested that business customers would feel comfortable with new programming paradigms (e.g., Salesforce.com's Apex) offered by large, stable companies, but shy away from similar offerings from smaller vendors. It's not that the smaller vendors won't get any customers; they just might have a hard time getting enough to stay in business.

Cloud Computing Opportunities for Start-ups and Other Small Companies

But, aside from infrastructure offerings, there are lots of great business opportunities for small cloud computing vendors. I believe that most of these opportunities share these traits:

business domain expertise + effective execution + cloud technology

Being small and new won't be problems (i.e., risk factors in the eyes of customers) for small vendors who demonstrate that:

  • they thoroughly understand business process problems that are important to the customer, and they are dedicated to solving these problems
  • they have a solution that directly addresses these problems in an immediately effective way

Getting Down to Business

Here are two software start-ups that offer examples of what I mean.

Compli is a SaaS company based in Portland, OR, that offers a software platform that enables car dealers to measure and manage their compliance with industry regulations. Through the Compli SaaS platform, car dealers can deliver compliance training to employees and employee test scores on compliance tests. As regulations evolve, and new state-specific regulations appear, dealers can distribute new compliance content to the appropriate employees and demonstrate "good faith" efforts at compliance.

Compliance is an important issue for car-dealers, an operational head-ache of sorts, and Compli's SaaS solution gives them an easy way to stay on top of the issue in a cost-effective way.

If you visit the Compli Web site, you'll have to hunt hard to find any references to SaaS and cloud computing. The words "SaaS" and "cloud" don't appear on the home page at all, and in the video featured on the home page, President and CFO Lon Leneve mentions SaaS only after discussing the scope and importance of compliance for car dealers. The company is focused on solving a business problem, and they're leveraging SaaS technology to do it. How's Compli doing? Last year was a record year.

I've written about Liquid Planner before, and I'll be writing more about them next week. LiquidPlanner offers a hosted project management solution that brings probabilistic analysis to project planning. In another words, while other programs like Microsoft Project force project planners to give a fixed estimate for how long a task will take, Liquid Planner lets planner input ranges and probabilities, so they identify risks up front. The result is planning software that's more detailed, more accurate, and more informative.

The solution includes other collaboration features, as well, but I'd like to point out that once again we have a SaaS company focused on solving an important business problem—project management—in a new and compelling way. Factoring probability into project planning makes so much sense, I think LiquidPlanner would be an attractive offering even in a traditional, in-house deployment; delivering LiquidPlanner as SaaS, so it can reach all members of a distributed project team while lowering hardware and software costs, only makes it more compelling.

And how's LiquidPlanner doing? Quite well. Business is growing. The company itself is a small, lean-and-mean team of ten people whose founders have extensive experience in data center management from Expedia. Steve McConnell, who has written authoritatively on rapid software development and software estimation, is an advisor to the company.

These two companies, Compli and LiquidPlanner, demonstrate the business opportunities available for SaaS start-ups. Both companies are focused on solving important business problems (regulatory compliance and project management) in new ways. The problems they're addressing will remain important to customers even in an economic downturn. The companies are leveraging SaaS to deliver their solutions broadly and cost-effectively. Both companies share share these characteristics:

business domain expertise + effective execution + cloud technology

Disclaimer: Neither Compli nor LiquidPlanner is a client.

Wednesday, February 18, 2009

Predictions for Cloud Computing in 2009


Short and sweet.

  1. The cloud computing market will grow in 2009.

  2. Most of that growth will be enjoyed by a small number of large vendors (e.g., Amazon, Salesforce.com) with solid reputations for technical prowess, reliable service, and financial stability. (The financial stability part is not to be underestimated; it will win over CFOs and CIOs.)

  3. Despite all the buzz at conferences and the cheery encomiums exchanged in blogs, new entrants and small vendors—especially vendors who try to replicate or enhance in a minor way the offers of the major vendors—will have a tough time closing deals and generating cash.

  4. Small vendors who pursue niche markets and apply their domain expertise to bring the power and convenience of cloud computing to business areas underserved by IT, stand a chance of gaining market traction and growing a small, profitable business by delivering operational business value to customers.

The success of this last group will depend as much on their domain expertise (e.g., about problems with insurance claims processing) and consulting skills as on their particular cloud infrastructure.

Comments welcome.

Coghead's Demise is a Reminder to Sober Up about Cloud Computing's Promise

I was sorry to learn that Coghead, a Web 2.0 Platform-as-a-Service (PaaS) provider, announced it was shutting down.

PaaS is an interesting model: a company offers a hosted service for developing, testing, running, and monitoring new applications. Customers can use the PaaS platform to launch new applications—or scale up existing ones—without deploying any local hardware or software at all. Sounds intriguing. Possibly very convenient. Possibly cost-effective.

It's proving to be too futuristic a vision. First, Bungee Labs, another PaaS provider, ran into trouble in 2008. Now Coghead is shutting its doors.

You wouldn't think this would be possible to read all the hyperventilating blog posts about cloud computing: how the time is right for cloud computing, everything will run in the cloud, what is the cloud—do we include PaaS? SaaS? If we don't define cloud computing properly, the cloud will perish! Many industry insiders are in a lather about these issues. It's as though the lottery has come up with the winning letters, which spell cloud computing, and now we have to scratch off the bonus letters just right to multiply our winnings or be sent home with a PC, jr. Nerves are a-jangle. Fingers are flying.

But if cloud computing is such an obvious remedy to the IT woes of business, why are these vendors in trouble?

Let's come down to earth for a moment. Let's consider this situation from the business customer's point of view. The business manager asks, Do I need PaaS? Is this really the most convenient, least risky way of building and deploying new applications?

I don't want to sound pedantic, but I think many cloud computing services will have trouble overcoming the obstacle that's snared many other technically impressive solutions in other IT markets of yore: just because you can build it and it's cool, doesn't mean that business customers will be comfortable with it. How many business customers in this increasingly risk-adverse environment are really going to adopt new programming paradigms and hosted services from small, evidently risky providers? Not many, I'm afraid.

Businesses want low cost and convenience. They want reliability and low risk, just as much. And (almost) nobody in business likes to learn anything new unless they have to.

I do think there are attractive opportunities for cloud computing in 2009. I'll details those in my new post. (Don't worry. It will be short.)

Note: Thanks to @chris_marino for tipping me off to the sad news about Coghead.

Introducing CodeGlide, a New Open Source Mashup and Data Integration Company

Economic downturn or no, the open source data integration market remains active. In late January, Talend announced a $12 million C round of financing. Over the past two years, the company's open source data integration solution has been downloaded 3.3 million times, and the company now boasts hundreds of customers. Other vendors in the market, such as SnapLogic, continue to add connectors and develop their capabilities.

And now comes a new vendor to the scene: CodeGlide, an open source company with a broad business application platform and big ambitions. I spoke recently with Mauro DeGennaro, CodeGlide's co-founder and Vice President of Software Development. He filled me on the company's approach, offerings, and direction.

CodeGlide was founded in May 2007. The company's goal is to offer a comprehensive suite of open source business applications, including:

  • Fusion, an open source data integration platform for building mashups
  • SnapCRM, an open source CRM suite (with a provocative title, since the company competes against SnapLogic)
  • Rendezvous, an open source collaboration suite, which offers calendaring, document management, and project management features

These three platforms are available in an Enterprise Suite bundle, which is the company's most popular download.

Speaking of downloads, CodeGlide seems to be off to a fast start. The company's Web site came on line on January 15. I spoke to Mauro about a week ago, and already the company had racked up 11,000 downloads of its software. Through its partners, the company has sold its Professional Edition to six different companies.

Partners are also lending their expertise to help the company develop other applications, including an E-learning application, an ERP application, and a Platform-as-a-Service (PaaS) offering that will compete against Coghead", LongJump, and other PaaS solution providers.

CodeGlide has a core development team of ten programmers, who are augmented by free-lancers and sub-companies that offer domain expertise in areas such as ERP. Business people and design experts design new features, which the developers then build. Of course, being an open source company, CodeGlide can expect to receive further enhancements and features from its open source community, as well. The company is small, but global: development is based in Argentina, Q.A. in India, sales in Europe and the U.S.

The CodeGlide Approach

CodeGlide's goal is to offer open source business solutions for the SMB market. It wants to make mashups and data integration solutions available to developers without advanced programming skills and even to business people. Accordingly, the company offers a visual tool for building mashups and creating widgets. For example, using Fusion, it's possible to construct a mashup that reads two Excel files and extracts data for a Sales report. A customer is using the product to read VoIP usage reports for billing. You can watch a video of that mashup being built here.

To keep development simple and straightforward, the company has developed a high-level scripting language, X#. The CodeGlide platform converts X# to Java. Of course, creating a new scripting language is risky: anything new or different can be a barrier to adoption. But if the scripting language really is both powerful and simple, and if the design tools minimize even the exposure to X#, CodeGlide may find that its reach really does extend to less technical users, who may have shunned mashups and Web 2.0 development until now.

To build mashups, users drag connectors and logical functions onto a design pane. Right-clicking on a connector or function opens a dialog box for configuring it. To select content or check for conditional status, developers use a filter function. There's also a foreach component for processing input items in turn.

As far as data integration goes, the company boasts an extensive set of connectors, including connectors for popular databases, including MySQL, Oracle, PostgreSQL, and DB2; common file types, such Excel; email services, such as POP3 and IMAP; and Web services, including WSDL-based SOAP services. A "screen-scraper" connector enables developers to access content displayed on Web pages.

Overall, it's a broad feature set for a young company. CodeGlide software is licensed under GLPv3. The Professional Edition of the Fusion mashup and data integration platform is available for $10,000, which is a one-time fee. DeGennaro points out that this price is far below the price of other mashup platforms, such as JackBe.

Low price. Lots of features. Big plans. CodeGlide could do well in an IT environment where business are looking for lots of bang for their buck.

Monday, February 16, 2009

Not All Data Integration Connectors Are Alike

Connectors are a vital part of any data integration solution. No matter what data sources you're integrating—databases, applications, flat files, Web services, etc.—it's awfully handy to have a preconfigured connector or at least a template to minimize the amount of hand-coding required to move data out of or into a particular data source.

The importance of connectors is perfectly clear to customers. In news stories, such SaaS Integration: Real-World Problems, And How CIOs Are Solving Them, which appeared in InformationWeek in October, customers are blunt about their expectations regarding connectors: vendors need to have a lot of them, one for every piece of middleware being integrated, and vendors better know how to make them work.

[H.B. Fuller CIO Steven] John is asking SaaS vendors lots of questions related to middleware, such as whether they have developed plug-ins for a specific middleware package and whether they have direct experience implementing that middleware. "If they say no to either, it's a strike against them," he says.

Recognizing the importance of connectors to prospects, most integration vendors parade their list of connectors on their Web sites.

And certainly, if you walk the tradeshow floor at events like the O'Reilly Web 2.0 conference or the Enterprise 2.0 Conference in Boston, you'll find vendors rattling off the names of the connectors they have.

"SAP? Oh, yeah. We've got a connector for that."

I've written before about the misleading simplicity of this approach. Data connectors aren't like Converse sneakers. You can't simply amass a bunch of them (red, orange, purple, black), and assume you have what you need for every occasion.

Different data sources have different security and access requirements. Applications integrating with protected data need to ensure that the data remains protected. You certainly don't want to bypass all the security and access controls protecting, say, a SAP ERP system, simply so that social platform users can pull ERP data into their wiki pages. These requirements become even more pressing when you're dealing with data in the cloud, where it's outside the perimeter of an internally secured and controlled data center.

Another integration requirement, above mere "connectivity," is transformation. Data might need to be transformed ("groomed") or narrowed before being presented to a group. For example, if I'm pulling in sales numbers from the Tokyo office, I'd probably like to see the amounts in yen converted to dollars. It would be nice to have the integration solution do this, so that I know I'm using a tested conversion tool that the company officially endorses.

Beyond merely connecting, then, connectors may need to work as part of an integration solution that supports access controls, transformation, auditability, and orchestration (e.g., before providing data set X, ensure than operation Y is complete, so that X is valid and up-to-date).

The NetSuite Example

The other fallacy of the "Converse sneaker" approach to connectors is it assumes that all integration endpoints and APIs are more or less alike. There's a DB interface or a middleware API. You write to it. You're done.

Not always.

Some APIs are more interactive and complex.

NetSuite, the hosted provider of mid-market CRM, ERP, and accounting solutions, now has 6,600 active customers. So lots of people have reason to connect to NetSuite data.

Integrating with NetSuite, however, is more involved than integrating with other SaaS applications. Why? Because NetSuite provides a great deal of flexibility in customizing their basic record schema and in defining custom records. You can query meta data to discover some, but not all, aspects of the customization. So a connector cannot rely on an automated process for discovering how an account has been customized and access its data.

Ideally, a connector should mask as much of this complexity as possible from the IT user creating the integration, so a good NetSuite connector will take advantage of the flexibility of the NetSuite API, while hiding as much of its complexity as possible from the user building or using the integration.

SnapLogic, an open source data integration company, offers a NetSuite connector that automates as much of this discovery as possible, while supporting integration that works with custom NetSuite records. Here's an explanation from the SnapLogic documentation pages:

NetSuite allows customization of its schema by allowing users to define custom record types and by adding custom fields to existing records. This extension package can automatically discover all the custom record types in a NetSuite account at install time. However, NetSuite does not provide interfaces which allow the extension package to discover custom fields have been added to all existing record types. The extension package is able to do this discovery for some kinds of records (like entity records, item records and CRM records), but not all. For this reason, a manual approach has been provided for specifying the custom fields of records. The user can use the NetSuite UI to browse the records and find custom fields that are of interest. The user can then use the utility: netsuite/resources/customize_resources.py (provided by the extensions package) to manually add custom fields to the SnapLogic Resources that represent a given NetSuite record types.

The connector automatically discovers of the accounts data schema as possible, then supports one-time additions for custom data. Once this set-up work is done, the user has a collection of ready-to-use, snap-together building blocks for building integration pipelines.

Because the connection reads the NetSuites schema, generates components, and supports customizations, it's able to provide NetSuite customers with a flexible solution for integrating NetSuite with other applications and data sources.

A more perfunctory connector would look just as good in a check list of available connectors, but it wouldn't serve users nearly as well.

Thursday, February 12, 2009

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 MethodAdvantagesDisadvantages
Online Survey (e.g., Survey Monkey)Fast, cheap, and easyA 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 InterviewsThe 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 officeA 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.

Monday, February 9, 2009

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.