tibbr®: How to leverage Use Cases to increase adoption
Social software, such as tibbr®, is unstructured and therefore needs clearly defined business use cases to succeed. There is a chicken-and-egg situation: there needs to be value to build adoption, but there needs to be adoption to build value. Use case building can be a guiding light in creating a path that ractchets up both of these elements.
But a common mistake is starting with very abstract use cases at a broad, general level. The issues from this are:
- Users do not have a clear direction on how to contribute or use the platform
- These contributions go beyond their daily duties and responsibilities which users generally don’t have time for
- Senior managers are likely not to participate
- Users Lack incentive to contribute as value is often uncertain
As a result, value comes in very slowly, causing user fatigue, and drags out the adoption.
(Above: Layers of abstraction of use cases. Focus early use cases on the ones with least abstraction.)
So how do you create immediate value in such a platform?
A better approach is to start at the core, with use cases that require more focused communications:
- Start with core use cases where abstraction is at its lowest level.
- Identify simple, frequently used business processes that can be ported into the platform.
- Engage senior managers and business champions to drive the processes in the platform with users.
It's useful at this stage to define your organization's processes for intra-group (processes / collaboration usually done through emails, meetings, custom tools / applications) and inter-group business (these are the collaboration points which usually require cultivation – weak in most organizations).
(Above: Examples of intra-group communications)
(Above: Examples of inter-group communications)
Think about the content that is developed by team members that can be shared regularly with broader group of people. And think also about areas where no additional knowledge sharing is required initially – through regular conversations, knowledge will emerge within the vertical.
Let's imagine what some intra-group use cases could be in an example, using product development.
Core – processes / communication
- weekly project planning / update from PMs
- daily progress updates from team leads
- issue resolution
- product documentation review
Peripheral - knowledge
- product strategy
- competitor analysis
- product know how / expertise
Now let's think about the interactions that product development team might have with another group, like folks in marketing.
In today’s enterprise, any processes are loosely defined across verticals. Inter department knowledge sharing is usually very weak within most organizations – this is where an enterprise collaboration platform like tibbr can really help with discovery of information. Focus on identifying collaboration areas and informal processes actually help drive desired behaviour across teams. Stronger knowledge sharing is developed when both teams collaborate effectively in the desired spaces. Inter group use cases then might look like these:
Core – processes
- sharing market requirements / reports
- defining product positioning / strategy
- specifying product features
Peripheral – knowledge
- competitor information
- market trends
- Roadmap insights (perhaps pull in sales engineers here, as well)
As a result, by building use cases--and the underlying trends and interactions, it's possible to more quickly build adoption in a phased approach that focuses on high-return value.
- Users know how and what to contribute during early days
- Sustainable content is created without the need to go beyond everyday activities and busy schedules
- Users see immediate value through effective communication
- Engagement occurs at all levels
- Adoption starts spreading immediately as more teams start to port business processes to tibbr
- Inter-group uses cases start to develop
- Longer term value emerges as content builds up and peripheral use cases develop
These tips can be helpful even long after launching, because boosting adoption and re-engaging user groups can happen at anytime.
Viral adoption--including in areas far removed from the defined use cases, is free to happen at any time of course. But it is easier to cultivate the adoption that helps with that, from the early focused attention and direction.