The company formerly known as Convoq, and later as Zingdom Communications, closed its doors Friday, November 30th. It was the end of a five-year run that saw three rounds of capital and a comparable number of CEOs and product strategies. While the company was an innovator in on-line meetings, and had a core group of enthusiastic customers, it never achieved the traction that would have provided the necessary return on capital, and the investors, patient as they were, eventually called it quits.
Founded as Applied Messaging by Chuck Digate and myself, the original idea was to use presence and instant messaging to bring people together for on-line meetings. The initial product was named ASAP after one of the key features, which started a meeting As Soon As Present, i.e. when all the desired participants were on-line and available.
There were two parts to the ASAP product, the Console and the Meeting, both implemented in Adobe Flash and connected via the Internet to the ASAP service. The Console displayed a list of contacts similar to the buddy lists of AOL, MSN, and Yahoo Instant Messenger. Indeed, one could import contacts from those services and monitor their presence in real-time. Clicking on one or more contacts would start a meeting with those people. If they were ASAP subscribers themselves, a toast would pop up at the bottom of the screen inviting them to a meeting. If they were not subscribers, a URL would be sent to them via one of the instant messaging services or via email. In any case, answering the invitation would open a seperate meeting window which provided audio, video, text chat, screen sharing, file sharing, and a host of other real-time activities. Since the meeting window was a Flash movie, participants did not need to download or install anything - an advantage over WebEx that our customers greatly appreciated.
There were a number of sophisticated tools for initiating a meeting, for which we applied for several patents and have been awarded three so far. In addition to the aforementioned ASAP feature, a subscriber could designate a stand-in - someone who would receive the invitation if the subscriber was unavailable. Alternatively, one could submit a meeting request to a lifeline which would pick the first available designated recipient, e.g. someone Sales or Support. The above methods were subject to an access control mechanism that would provide different stand-in depending on who was requesting the meeting, and allow subscribers to designate other individuals for special treatment, either as VIPs to get preferred access or to be blocked from issuing meeting invitations at all. In addition to the console, meetings could be initiated by clicking on an icon that could be embedded in a web page, by invoking a Web service, or by scheduling a meeting in advance in Outlook.
In hindsight, we spent far too much time iterating the above features in the conference room before we tested them in the marketplace. This was partly a function of a management team that had yet to embrace agile development techniques (the Agile Manifesto was only a year old at that point) and partly a function of how Flash in those days before Flex was difficult to program and impossible to automate testing. As it turned out, our customers were less interested in ad-hoc videoconferences and instead used the product for scheduled on-line sales presentations, distance learning, and day-trading "squawk boxes." While our customers appreciated how much easier it was to hold a meeting in ASAP than it was in WebEx, and our price was considerably lower, it was hard to keep up with WebEx in features. To add insult to injury, Macromedia, from whom we'd licensed Flash's screen-sharing technology, declined to license the companion remote-control feature, preferring to keep that for their competing Breeze product, and they fell behind Skype in the quality of the interactive audio and video. Then Citrix acquired GoToMeeting and started a price war with WebEx.
Convoq continued to innovate, signing up as one of the first developers in Saleforce.com's AppExchange program and solving the remote-control problem by adapting code from VNC, but by the Fall of 2006 it was apparent that Convoq was not going to win in the Web conferencing business. After a brief exploration of a consumer video product, Chuck Digate departed and Convoq began its second phase, renaming itself Zingdom Communications.
As Zingdom, the company's first offering was a set of Javascript widgets and web services to enable a visitor to a web site to communicate via phone calls and instant messaging. By cutting and pasting a bit of HTML, the operator of, for example, a dating site, could give subscribers a way of defining a profile that included their phone number and instant messaging handle.
A visitor to the web site could click on an icon and be offered a choice of contact methods (e.g. office phone, cell phone, instant messaging) and then be connected to the subscriber. Instead of requiring either party to divulge their phone number or IM handle, the system provided its own numbers and names. Thus when the phone rang, the caller-ID displayed was a number on the Zingdom service. Either party could make a follow-up call by dialing that number, subject to the permission of the other party, thus establishing a communication path that was unique to those two people and could be terminated at will by either one. Similarly, if the conversation took place via instant messaging, the requesting visitor would type the messages into a Javascript window and the receiving subscriber would get those messages via an AIM 'bot. The visitor would not need to have an AIM account at all, and the recipient did not need to divulge his or her screen name.
In embarking upon the Zingdom project, the engineering team adopted an agile software development model, with daily builds, bi-weekly iterations, and six to eight week releases and automated testing. Progress was swift and the product was working by April. Unfortunately, the business development did not proceed so swiftly. It turned out that for people who communicate through web sites, voice is the least attractive option, a phenomenon that has been observed by Omfut, Jim Courtney and Andy Abramson. We proved point this even more conclusively with a set of Facebook apps at the end of the summer.
By September it was apparent that we had formed a highly functioning development team and had built some very advanced technology (including an AJAX app that pushed the state of the art and some powerful tools to automate the plumbing that holds the code and database together), but we needed to connect directly with consumers and not rely on the good graces of partner sites to incorporate our technology. After some spirited discussion, my proposal for a Facebook communications app was adopted and I was put in charge of the third phase of the company.
Our idea was to leverage the social network of Facebook to create a powerful communications application, but we needed to move beyond the lackluster click-to-call apps that weren't getting any traction. One of the architects of the project, Mark Waks, came up with the idea of building an application around conversations, and Spark was born. Spark was based on the observation that many human activities involve extended interactions that take place at varying tempos. For example, a group organizing a car pool may exchange some emails on Friday about arrangements for the following week, then some instant messages on Monday morning about last minute changes, and perhaps some frantic phone calls at 5:00 when someone doesn't show up on time. Similar techniques can be useful in endeavors as mundane as college students deciding where to go partying to public safety officials planning for a natural disaster. As one Air Force colonel put it "The time of an incident is not the time to exchange business cards," i.e. the social network is best established when things can proceed at a leisurely pace, but then is valuable in times of stress.
So now we had a vision, and a product concept, but the sand was running out in the hourglass. By the end of November the basics of Spark were up and running - there was a Facebook application that allowed people to contribute and access information from the web, from AOL Instant Messenger and from a mobile phone, and a framework was in place to add photographs and voice. The company is no longer developing the application, but the source code and patent portfolio are up for sale and the engineers, especially Mark, are eager to continue the project should a suitable purchaser emerge. That's one task upon which I am working, in addition to "the meta problem."
In the meantime, some lessons learned:
- Iterate in the marketplace, not the conference room. Agile is the only way to go.
- Just because you are using agile methods doesn't mean you don't have to plan. Write your stories before you begin an iteration, but don't waste a lot of time on the details that aren't needed until later.
- Don't spend a lot of time and money naming the company until you have the product and positioning figured out.
- If you are depending on paid search to generate traffic then your marketing is broken.
- Raising too much money is almost as dangerous as raising too little - it sets high expectations which then drive high expenditures to deliver the results on time.
- If you want to do a consumer-facing product on the East Coast, stay engaged with the community in Silicon Valley. By the time you read about something in TechCrunch it's too late.
- Remember the three stages of building a web property: 1. Attract, 2. Engage, 3. Monetize. Don't skip a step.
P.S. Both ASAP and Spark benefited from very talented designers, Alan Osman did ASAP and Jesse Morano did the Zingdom apps and Spark. The development team comprised some of the finest engineers with whom I've ever had the privilege to work. If you are in need of either, or are interested in purchasing the IP, please get in touch with me.
