The ‘Let’s Try It Ourselves’ Problem
Every few months a prospective client, working on a new community, will invite us to submit a proposal, see the cost, and reply along the lines of:
“Thanks, we’re going to see how it goes and we’ll let you know if we need your help”
Which makes perfect sense if you feel you can make it work without help.
But looking at the list many months (and years) later, just 1 of the many dozens has succeeded going it alone. This might be the Dunning-Kruger effect. No-one realizes how difficult building a community can be until you’ve been through the wringer a few times.
Many organizations make the same mistakes without realizing they’ve been encountered many times before. These include:
- Not testing different messaging appeals in small groups first and refining a powerful community concept.
- Not building strong relationships with prospective customers prior to the launch of the group.
- Selecting community platforms which integrate badly with current systems.
- Spending too little time on technical details (or trusting vendors/implementing partners will deliver on sales promises). Related, failing to set-up the features or functionality of the platform properly (notably SSO).
- (Massively) overpaying for a community platform.
- Spending too little time gaining internal support for the project (notably in legal/PR for what you can/can’t say within the group).
- Promising too much to gain support and later struggling to satisfy expectations.
- Neglecting existing groups or top members who already feel a sense of ownership over engagement platforms.
- Failing to onboard newcomers effectively.
- Hiring a community manager who has never built a branded community from scratch.
- Sending out mass emails to members announcing the community.
- Trying to do far too many features at once (gamification, ideation, top contributor programs etc…)
All the above is relatively easy to overcome if you know about them in advance. We’ve consistently chopped 3 to 6 months off development time and time to critical mass just by addressing issues much earlier in the community lifecycle. When you factor in platform fees and staff costs, this usually means a saving in the six-figures.
This doesn’t mean you shouldn’t try doing it yourself. Consultants who have been through this process many times aren’t cheap. Many organizations manage to do it alone and succeed.
But be aware it’s very difficult to spend your budget, lose organizational support, and squander the attention of your audience and still succeed. Getting any of these back is extremely hard.
So if you do go for it alone, make sure you start small. Run a small pilot on a cheap platform and learn quickly. See if you can drive and sustain engagement. If you can, gradually spend more time on it. If you can’t, get help.
And make sure people and colleagues know it’s a trial program.
I’ve always thought about this. We recently had a similar problem. One of the things we realized was that we should do is to start billing the client for the time put in on the project.
For the proposal you mean?
You bill clients for the time you spend putting a proposal together?
I’ve never heard of that before.
Wouldn’t you need a proposal to get approval to do that?
Just realized that this reply might not be directly relevant to the topic.
Well, so here’s the scenario-
We are into the business of doing developer conferences and community events. By virtue of consistently doing this for the last 6 years and because of the quality of the content, developers who’ve attended our events usually recommend their companies to sponsor or ‘be a part of our events’.
Last week, we had a company reach out to us because some of their employees had attended our event and had asked the marketing team to get in touch with some possibility of doing events together. Usually, when the marketing team takes over things, we’ve had some really bad experiences because they think that we are an ‘events’ company and they can just put in money, sit back and relax. We, on the other hand, spend so much time and effort coming up with topics for meetups, outreach mechanisms, surveys and a lot of meetings to put together a meetup. Now, they refused to change the dates for the meetup because ‘they don’t work on weekends and their office space won’t be open’. The problem here is that developers here attend events only on weekends, and that too specifically on Saturdays. The conversation didn’t seem to go very well mostly because all that team cared about was checking off that event from their list of things to do and not understand the idea behind why they’re doing an event.
It has consumed so many hours (we use Toggl to track time spent on different projects) of the editors & community manager for putting together the topic and list of speakers+format of the event. Now they tell us that they can’t do an event on a weekend, and at some point, might tell us that they’ll do the event themselves, in which case the entire effort is wasted.
So, from now on, we’ve decided not to do third party events. But in case there’s an instance where we can’t avoid the request, we tell them upfront that they will be billed for the event from the time we start the conversation, regardless of whether they choose to do the event with us or not.
Make your own comment on this post at FeverBee Experts