We never set out to build visual collaboration software. My cofounder, John, and I started out building giant touchscreens in his basement in Delaware. This was late 2008-2009 when no one knew what multitouch was. There were maybe 10 or 15 million iPhones in existence but they were still somewhat of a novelty and the iPad was over a year away [fun fact: the touch technology used in the original iPhone was created in the computer labs at the University of Delaware. Good job, Wayne]. Back then a Microsoft Surface was the size of a coffee table and cost as much as a car. Our touchscreens were even more expensive.

We marketed our touchscreens to the only companies that could afford them - large, Fortune 500 enterprises. We just knew that multitouch technology was going to transform the way people interact with computers and we were going to be the ones to bring it into board rooms across the world. We were right about the impact of the technology but so very wrong about who was going to deliver it.

I think we sold two.

It wasn't a problem with the technology. We were using then-state-of-the-art tech to design and build bespoke, fully integrated systems. They were awesome. It also wasn't the price. Companies had the budgets. The problem was that you couldn't do anything with them. Nobody was building software for large format multitouch screens. This was, admittedly, a pretty big oversight on our part. We believed that the tech was so cool, the apps would come.

The aha! moment came about a year later when, burned out and frustrated by our fruitless attempts to sell high technology to IT departments weary of yet more useless hardware, we took a week-long roadtrip to visit my mentor in Illinois. He works for a global manufacturing company and one night, over beers, he told us about something called "obeya" - a Japanese term that literally translates to "great room".

He described the obeya room to us: a large conference room with every wall covered floor to ceiling with print-outs and sticky notes. His company uses one of these rooms to visually manage the status of every product they build. Cross functional teams meet once or twice a week to discuss the status of each project and make sure that everything is proceeding according to plan. Issues are visible to everyone and can be resolved expeditiously.

The problem, he explained, was that while the rooms were fantastic for facilitating communication and collaboration when all of the team members were in the same room, the process broke down when people weren't physically there. His teams were spread across multiple facilities; even across multiple continents.

"You know," he said, "what would be really cool is if you took all of that information and put it on your touchscreens. Then people could participate no matter where they were. That would be really awesome." Entrepreneurs dream of these kinds of moments.

We worked late into the night, discussing usability and feverishly sketching out the architecture for such an application. At one point during the early hours of the morning, as I looked at the table full of notes and wireframe sketches, I was struck by the realization that this was a pivotal moment for our company. We were about to turn away from being makers of tools and become, instead, creators of solutions.

We drove home, excited about this unexpected turn of events yet uncertain about how to proceed. We wanted to dive right in and start building immediately. The lessons of our previous failure, however, curbed our enthusiasm. The first step, we decided, was to understand the problem from the perspective of the customer. We needed to be certain that the problem was real and that it was big enough to justify the considerable investment of resources it would take to build.

I immersed myself in the mysterious and esoteric world of visual management. That was the generic term for what my mentor had described to us. I discovered that it is more than just a working wall or a set of tools or processes. These artifacts simply provide a tangible and contextual framework through which the real value of the visual management can be extracted.

Visual management is a holistic methodology and an important part of the methodology is the structure of the meetings that happen around them. Visual management practitioners are the high priests, the working room is the temple, and the meeting is a ritual designed to promote common understanding and mutual accountability across the entire organization and along the entire product development life cycle.

Whoa. This was heavy stuff.

Whatever we built had to preserve the spirit of the methodology yet allow for the kinds of spontaneous change and innovation that lie at the heart of continuous improvement and lean product development philosophy. We learned that no two visual management systems are the same. Companies establish best practices to provide structure and standardization, but allow them to evolve over time as better tools and processes are created or discovered.

This thesis proved accurate as we spoke to more and more practitioners and consultants. The consistent feedback we got from them was that the technology could not be allowed to get in the way. The success of any implementation would be measured by how seamlessly organizations could transition from the analog pen-and-paper system to our proposed digital system. Preserving the meeting structure was paramount.

These considerations were piled on to a growing list of other constraints. For instance, we had to support real-time, simultaneous user actions. Any kind of turn taking or queuing would stifle user engagement. Each user needed their own view of the workspace, independent of everyone else. This, combined with the previous requirement, would allow teams to break up into smaller groups and work simultaneously on different parts of the canvas. We also had to support a wide-range of interaction modalities. This meant support for touch - because the IRL version was very tactile and intuitive - as well as support for traditional mouse and keyboard inputs.

Altogether, these requirements necessitated a radical design approach. We couldn't simply abstract the process into 2-dimensional grids and call it done. It was necessary to consider all of the human factors involved - both physical and social. We had a fair bit of knowledge about multi-user groupware design from our experience building large scale multitouch devices and this, combined with what we learned about visual management methodologies, gave us the confidence that we could actually do it. We were ready to start building Cnverg.

To be continued...

Recent Posts