Socialcast Reach – Development In Context
The Enterprise Conversation Engine
My initial meeting as a new employee of Socialcast was with Tim Young, CEO and Founder, who welcomed me aboard and assigned me to the project codenamed “Enterprise Conversation Engine,” that would later be named “Reach.” Tim described the opportunity with “Employee knowledge and actions are being locked in silos across applications like CRM, ERP, and SharePoint, forcing critical discussions to take place out of context via e-mail. We need to enable enterprise employees to communicate and collaborate inside the applications they work in, giving all applications a social layer,” and outlined the goals for the project:
- Enable employee collaboration from within their existing workflow by extending all Socialcast activity streams into any Intranet application.
- The integration would need to be compatible with any system, regardless of platform.
Executing on Vision
As is common with such large-scale and exciting projects, one of the most important decisions was where to begin. The first priority was outlining a list of core tenets and high-level requirements that would stay constant throughout the life of the project, such as:
- Company IT/Web teams should be able to designate individual pages or ranges of web content to be Reach-enabled with reasonably minimal effort (copying & pasting code)
- Access to activity streams should be secure; data must be inaccessible to parties outside of the company
After collecting these (and other) core tenets, the team set an aggressive target for a prototype that would embed a Socialcast discussion within Atlassian’s JIRA, the issue tracking system in-use within our company. The integration would serve as an internal proving ground for the concept and enable Socialcast developers and managers with the ability to discuss, plan, and update ticket progress in the context of a specific issue.
At the development kick-off, one of our Senior Engineers recommended leveraging the existing Rails codebase to build the prototype client. This decision resulted in a demonstration of a static JIRA/Socialcast integration within a week of kick-off and set a rapid pace for a project that would undergo multiple iterations over the next few months.
As development continued, Reach found a unique balance between prototype feature and core aspect of our internal workflow, as the JIRA integration was being used by or exposed to all Socialcast employees on a daily basis. Posting a comment on an Issue page resulted in metadata (ex: issue title and description) being brought back into the Socialcast community, adding context and linking the Issue to the conversation. Reach was enabling our teams to collaborate directly on resources that were relevant to the conversation instead of just referencing them.
During the dog-fooding phase, Reach benefited from integration within Socialcast’s workflow and the internal feedback resulted in many of the features included in it’s release. To fully understand the different use cases and constraints for integrating Reach with an enterprise Intranet, we opened an early access BETA program and partnered with customers to work through test deployments. These partnerships led to valuable feature recommendations and feedback that influenced the direction and scope of the project.
A key customer feature request was to expand our existing SharePoint offering to support a library of configurable WebParts that were more tightly integrated with SharePoint host pages. To accomplish this, the team broadened the Reach product scope to include making every extension exportable as a 2007 or 2010 WebPart, via the configuration wizard. After a great deal of testing, the end result was a collection of customizable WebParts that are able to access metadata from SharePoint and bring the information back into Socialcast, adding valuable context to the conversation.
Reach evolved into the full-featured product it is today because of the extremely talented and focused team at Socialcast. Some of the lessons I learned while working on the project were:
- Temporarily narrow the project’s scope to achieve rapid prototypes (when possible)
- The sooner you have a prototype, the sooner you can demo to project owners
- Building a prototype may reveal edge cases, new interactions, or technical hurdles that were not factored into the original design and requirements. The sooner those are identified, the better
- Expose the product to key audiences at each stage during development
- Starting with an internal dog-fooding process is a safe way to collect initial feedback (be sure to manage expectations for existing deficiencies and bugs)
- Make it convenient for the audience to use the feature – tight integrations with existing workflows will result in more usage and thus more valuable feedback
- Partner with interested customers – their feedback and concerns should be addressed during development, not after release
- Adapt to changes in the requirements and feature roadmap
- If you are collecting feedback early, your requirements are going to change (at least slightly) during development. If you anticipate this, you’ll be able to execute on the broader vision without getting stuck on “what the product was” in the past.
The following are a few examples of features that originated from feedback (internal and external) and required adapting to change in a short period of time:
- The library of Reach Extensions growing from Discussions and Home Streams to include Recommend/Like buttons, Analytics/Trends, and Custom, Group, and Company Stream Extensions.
- Enabling Reach Extensions to adjust in size and structure when embedded in sidebars and other narrow areas.
- Creating an advanced technical documentation wiki to support developers and custom integrations:(https://scdevresource.pbworks.com/w/page/30861831/Getting-started-with-REACH).
We’ve got some exciting post-launch features in the works for Reach and are looking forward to the next phase of development. Along the way, we are always collecting feedback from users, IT departments, and Socialcast administrators to improve the product.