Building communities

I have been a communities person for a long time. Not necessarily in the sports club type, but in the learn from one another, sit and discuss type.

I started my professional career reading, learning and then contributing back to newsgroups. It’s been technical newsgroups at first, so people would post their problems and challenges, others would chime in, ask questions to explore the problem space, and find possible solutions. It was a fascinating way of learning: by observing people asking questions and otheras chiming in and asking questions back, you could learn a lot about people’s though process – and dependencies they knew about they asked for. And … clearly the answers and at times, an explanation for why something may have happened.

It satisfied my curiosity in multiple ways:

•  I learned about technology, what can go wrong, and how to fix it
•  I learned a lot about dependencies to the technology, direct and indirect with other systems, solutions, etc.
•  I learned a lot about others’ ways of approaching a problem and narrowing it down
•  I learned to appreciate an exchange of experts, who free of charge share their knowledge with others.

Through this, I grew – and soon, I was able to give back, which served a multiplier effect for the technology and the newsgroups community, as there was one more person to contribute in. And also – I was able to apply the knowledge professionally and through other channels than the newsgroups alone.

I carried that on with web forums, when the newsgroups died out. However, slowly but surely, my focus shifted and my depth in tech in a specific ares/product started to decrese – for other things becomeing more foreground that I needed to focus on.

However, I never forgot the value of communities.

Even in product management, communities have a fantastic value for the PM, Engineers, and customers/users. If you are working on a cloud-connected or true cloud service, you know that the days of long development cycles, compiling code to put them on CDs, DVDs or floppy discs have gone. The turnaround time is just too long. The world will have changed before you can react. Communities can help with that.

Imagine you had a group of enthusiasts that know you and your product. A group that  you could work with and call on, when there’s a decision to be made, or a design to be reviewed – or a pre-release to be tested and validated. A group that you’d build a relationship with, beyond the “customer – supplier or “customer-supplier” link that automatically exists. because your company sold stuff to another company. This is about mutual care for moving the problem space, product, or feature set. Care enough, to be willing to engage in regular, open exchange in progress and what’s next – because there’s a joint belief that the product can and will evolve. Wouldn’t that be a community of customers, partners, subject matter experts, dreamers and enthusiasts, you’d want to build and stay close with?

Such a community could:

• bring the time to test and validate new features significantly down, if you could tap into a pool of regulars
• allow for very fast turnaround polls for priorization of features, impact evaluation of defects, bugs, a missed capability
• yield honest feedback about a design, it’s pros and cons – from the potential customers it’s intended for.
• help set up trusted SMEs early in your release cycle, to they can spread the word early and fast, as soon as you release.
• serve as a temperature thest – for yourself, Engineering and also marketing, to safely and honestly test the waters with your ideas and design.

The idea isn’t new. I have seen it a few times in different flavors in the past, but it doesn’t appear to be strategic. Also, most likely cut when there’s a resource constraint. It’s trested like a cost center, not an asset. 

There’s a few key things I believe need to be present to pull it off – that were present in the communities that I participated and the communities that I am trying to build now:

REPSECT: I think this is the core value that must be designed for. I people spend time from their valuable work day – or off hours if it’s a hobby or heart project. You want to handle that community in a professional manner and respect people’s time, commitment, opinions and willingness to contribute. No hard feelings if people leave or tell you it’s no longer of value for them – accept that people may dedicate their time to something else, at some point.

DESIGN FOR MUTUAL VALUE THROUGH LEARNING: among all participants. Don’t be a freeloader. There should be true value for all participants, that you design. You are getting valuable insights that may help you validate/falsify ideas and assumptions you have, or move your design along, based on feedback and discussions in the community. In exchange, participants should be able to learn from one another, and you may be able to give them product insights and give away parts of your plan moving forward, so the community can plan ahead and set themselves up for when your product is ready. If you plan to give the community access to pre-release code to test and validate, that’s a fantastic way of designing for mutual value as well: while the community gets to learn about a new product early and go through the thinking of how to introduce this and operationalize very early int he process, you get to extract the pre-release learnings and feedback on blocking issues, technical challenges and problems in wrapping operations and support around your feature.

TRUST THROUGH TRANSPARENCY: Be open with your plans, the context of what you want to know and the discussions that you’re driving, and be clear about your intentions. What you won’t be doing or won’t be designing for, is equally important as what you will do and design for, if that’s a topic space for discussion.

CONTINUITY: Design for a community that’s not a one-off event or happens whenever you need something specific. Make it a regular event so members can get acquainted with you and the rest of the community and make enough room for recurring feedback, open discussion and “other topics”. Don’t try to entertain your community – that’s not your goal, but ensure the topics you bring up are relevant – and make sure it’s clear how they belong to the greater set up problems you want to solve.

HAVE FUN: this is a personal recommendation. If you’re having fun and it shows, and you are discussing something relevant, that’s 70% of what you need to look for already. If you can then transport your fun and positivity to your community, the conversations will be fun and good as well.