I started my trek designing, developing, and managing social / collaboration platforms in 1996. Over those years I've been part of a lot of different projects, development of platforms, long term and short term strategy and planning with vendors in the space, and in recent years back helping design, and product management (from an advisory role and mentoring). I have also been framing product needs and flows for new systems (either plugging into existing social platforms for new major releases, adding these capabilities into existing platforms with distinctly different focus to augment them where other existing services can't fit, and / or building platforms from scratch). I have also been continuing to advising organizations by helping them understand their needs better and problem sets they are trying to resolve before they get into the selection process, so to best fit product to their actual needs.
The focus of this piece is for organizations looking at social and / or collaboration platforms or services for internal and / or external uses. This is to help provide some understanding when considering a build versus buy consideration, but also some background on platform and services design and development
Lessons Learned
The lessons learned aren't new lessons learned for me, but I'm finding they are still relevant and haven't shifted all that much in the last 7 to 10 years.
Build vs. Buy
The build versus buy question is oddly still asked. I had figured about 15 years ago that by 2010 organizations would mostly just consider buying a service or platform to use. Many organizations still are considering building, as social and collaboration seems easy. But,nearly always you want to buy a service or platform rather than building.
Why? Time. This is comparison is for getting things up and running and working smoothly at a somewhat foundational level.
On average, after going through needs assessment and right fitting a purchase decision a service or platform can be up and running optimally in around 9 months, with the usual range being 6 to 18 months. That is getting the service running, getting test groups in the service, optimizing and iterating the service, modifying the design and UI to meet needs, building taxonomies that work, getting onboarding created and honed, work through some lasting workflows based on needs, and getting community managers comfortable working with the service and patterns honed for the cultures they are working with. Most services and platforms can be up running and functional in 48 hours for very basic functions, usable in 2 weeks, working through initial groups and integrations in 3 to 6 months, and iterations and scale often span the 3 months to 18 month difference.
If you are building your own it is 2 years to 3 years on average to get something up and running and working smoothly. This 2 to 3 years is the comparison to the 9 month mark. Many well funded product development attempts are getting to feature parity with something they could buy in that 2 to 3 year span.
Why Build?
There a few reasons to go down the longer and more painful build path: 1) There isn't a product that remotely covers the complexities you are experiencing and have documented in your needs assessment (more than likely a good chunk of what you need to build can be bought); 2) The identity model and adaptive needs aren't supported by existing offerings (this is one of common reasons as identity models with adaptive use on most platforms are limited - most often limited on the free or bundled services - and in many platforms rather stiff and restrictive); 3) You are building or integrating a large collection of services that don't interconnect well and collaboration, social interactions, communication in and around them is essential; 4) The social components are internal to another platform you own and have built end-to-end. There are a few other edge cases to build rather than buy, but these four are the most common of the rare cases where buidling makes sense.
If building what is needed? The most important things needed is teams who have done this before a few times (yes not a team as this isn't a light effort). Building social platforms is hard and complex, it isn't adding commenting to content on an existing site, nor building a simple messaging system, but dealing with adaptive systems that will need to embrace and support many cultures and sub-cultures that intersect with their different mental models. See the roles needed in Team Roles Needed for Social Software Projects. If you have those covered, particularly the social sciences, and with people with serious depth on these, not just watched TED Talks, nor read light blog posts, nor the TLDR versions, but actually had years doing this on top of serious depth of understanding, then you may be ready.
How Can This Still Be So Lengthy?
Social software is hard and complex, which is the simple answer. There is a lot to build and account for. I've watched and worked with teams who have built a few platforms for social and collaboration in the past and sold them off. They have started anew and getting to a good platform with basic feature parity with some new functionality to move things forward it has been 2 years at a minimum.
In the past couple of years there have been quite a few new services surfacing that have design and development teams with nearly all members having 5 to 10 years of prior experience building and managing social platforms and in 6 to 9 months they have something decent, yet still a clumsy beta. The product isn't open to everybody. It normally goes through heavy iterations and most of them shut everything off for a few months for rebuilds and reopen beta again. A decently good and useable service and platform often hits that mark at the 2 year point, if not farther out.
Another reason it takes time is the adapting to changes and norms of use. Most organizations are looking at systems that will be relatively easy to understand for their employees and or customers so they spend minimal amount of time training and onboarding. The interaction patterns that are common and norms are rather fluid and shift a little or a lot every 9 months to 18 months or so. Patterns that were fine at the product development start, may have changed quite a bit in a year.
Social Interaction Design / User Experience is Complex
A few years back I framed out 20 social roles for different interaction model roles people fall into in social platforms / services. When I started talking about it vendors responded that they were lucky if they had two: User and Admin. In the past 6 years things have changed a little for vendors as they are trying to embrace more social roles. But, for community managers they are commonly working with 6 to 12 different roles and or personas, which has vendors working with a broad set of personas, sometimes beyond 15 (the social role is just one element of a persona and it is common in reality to have people with 4 or 6 different social roles they embrace across a few groups in a community or network.
Having those designing and developing a platform working from this understandings helps smooth some of the complexity. But, having solid familiarity with this diversity has become essential if building a service or platform that is expected to work broadly, which is what social platforms do.
The Wrap
Hopefully this helps a tiny bit when thinking through "should I build or buy" or "why is my social product development taking so long" questions.