Creating a framework for document collaboration

Barbal addresses a very real and painful problem for our users; even with all the advances in online collaboration and document management systems, working with others on documents is still really painful — particularly when lots of people are involved in drafting or commenting.

Our technical hypothesis is that we can adapt the version control tools that software engineering teams use to collaborate on code and make them intuitive for anyone working on docs — which we’ve done.

One of the biggest challenges in building the company is nailing our marketing messaging, particularly for early adopters. In some ways, we’re playing in a very crowded space. In others, we’re creating a new category.

Simply, there are certain types of document that Barbal would be very helpful for and others where it would be overkill or unhelpful.

Cases where Barbal is helpful:

* Lots of people from the same or different organisation(s) involved in drafting or commenting

* Style and presentation isn’t the responsibility of those drafting

* Version control is critical to help understand decisions or re-wind changes

* Separate changes need to be discussed and approved independently or by different people

* Versions exist at different stages of maturity for different users (published, for review, work in progress)

Words that are entrenched in business practice have very specific meanings to some people and not to others. The meaning of these words can vary by discipline, team or sector. Types of document is one such example.

Social media is a wonderful tool, but it does mean that I have no control over who is reading words on our feed that might be intended for a specific audience.

For one person a “report” might be a sheet generated automatically from data. For another it is the product of months of effort by several teams to come up with a set of recommendations and justifications.

Sometimes we use deliberately ambiguous language in our marketing to avoid these pitfalls, but often it’s necessary to talk about specific types of documents, especially as we don’t yet have case studies ranging across use-cases.

There’s loads of cool stuff happening in the document collaboration space. Yet we haven’t found any direct competitor that addresses the enterprise-level document collaboration pains that we do. So there’s space for us, but there’s also a lot of noise where we need to get a signal through..

I’m continuously plugging away at a framework to help prospects quickly put us in the right category in their heads and qualify our solution against their needs.

It’s a function of:

• The number of people involved and their relationship
• The intent driving the collaboration
• The requirements they have for auditability and version control

With a background in standardisation, particularly my work with the Internet of Production Alliance and the Construction Knowledge Task Group which sought to make data standards accessible to non-data people, I’ve amassed a lot of experience in balancing technical accuracy with accessible language. It’s hard.

For us this is a marketing outcome, not an information science problem. It has started with a quick flow chart, but in time we will need to build this into a model that means we can talk about use cases by profession > sector > document type, so we can make statements like “If you are a [profession] in [sector] feeling the pains of working on [document type], Barbal can help.”

Collaboration is a messy, intangible problem. Collaboration software is available for any number of use cases (in fact, an ability to share information is table stakes for most business software). Microsoft Word and Google Docs will continue to have their place for professionals. But buyers and users need a way to navigate the other options that are available to solve different levels of complexity or organisational needs and select the best available for their project’s needs.