This is a high-level written version of a workshop I did for London Community Week. It's long, you probably need to read it online.
One year ago, I started contemplating the idea of the AI MVC. Would it change how I would go about starting community efforts? What aspects of my general strategy would I keep? And which ones no longer made sense?
I took the idea to a workshop to further expand on my thoughts. I appreciate the commitment of doing a talk or a workshop as a way to force myself to show up and put pen to paper.
MVC Before AI (BAI)
Without sounding too dramatic, or feeling like I'm hyping up AI (I am not), as I was reviewing my past work, I kind of felt that there's been a big enough shift with AI to start making a case that how we can, are or will be building community from an MVC mindset will look different than BAI (Before AI).
This doesn't mean throwing away everything that we've done in the past away. That is not my message. It's more that we can do certain things better with AI. We can most certainly do better, or more efficient, or more cost effective. And once you discover you can do that, then it would be daft to go back to BAI. It would make no sense.
To better understand how things were before AI, it made sense for me to dig up what I'd previously written on MVCs. I'll highlight some of it in what follows, but feel free to read my previous guide to building MVCs.
I reviewed my work and asked if it still made sense in today's world. And whilst parts did, it definitely felt like it needed an update.
So, for context, BAI in 2022, this is how I defined an MVC.
And then I had The MVC Framework.
I encouraged people to think about what they have access to that might help them on their journey. We all have access to something, even if it's just the internet.
Then there was the idea of containers. If you're just starting in community, containers will be really small and simple, but if you have an existing community, your container may look much bigger in comparison. We can always be MVC'ing at any part of the community lifecycle. The size of the effort is small in relation to the size of the community project.
Community containers usually require community activities, so I would encourage people to explore these types of activities. This list is not meant to be a complete list, just one to get people thinking.
And then examples of containers, where the community activities help make them happen is also helpful to think about. Again this is not meant to be a complete list.
Then comes MVC AAI (After AI)
So what changes when AI comes into the picture with MVCs?
First, some mindset shifts
It's ok to push back against the focus on conversations and gathering. It's good to talk in community, it's also good not to talk. I often like to encourage people not to jump straight into conversations. It can feel counter productive to say that in the context of community. I'm not anti-conversation, but I think we have a problem in community where we feel like we have to talk about something to make progress on the thing we are working on. We do not.
And omg, it can be so exhausting and slow us down. It feels like we lack confidence to make decisions, so we keep going back to our people to seek their approval. I see this happen so much and it's so damaging to our efforts. To the extent that it presents real risks of slowing down our community flywheels.
It's about research. But really the pushback on talking is to give focus and space to having more of a research mindset. We don't have to have new conversations to reach a conclusion. Or we can do a bunch of research up front, and save the conversations for later on when we feel more confident about what we are talking about. My Community Discovery basically dives deep into how to do community research.
We are community builders. In addition to not over-relying on conversation, I'll continue to fly the flag that we are community builders. Again, the emphasis encourages us to look at community as something we build. Yes, people and conversations are important, but really we should always be investing in the community infrastructure.
Redefining Minimum Viable Community
I love having a go at defining terms. Take from it what you want and adapt to your own needs. This is what I've ended up with.
Personally, I've moved away from focusing on 'bringing people together' and towards 'community infrastructure'. This is more of a 'community builders' mindset. To build community infrastructure, the focus becomes on the building of something of value, by whatever means we believe will work best. We will end up bringing people together when it is the right time to do so, and it moves us away from the default of "I must gather people" even when we might not need to.
The goal is to build and sustain. Yes, MVCs are experimental and still need to be reviewed as they are being created. But they need to improve the overall community infrastructure, if they are not, then we get rid of them. In that sense, The MVC Framework is still valid: What you have > Community Container > Evaluate.
Also, from a community infrastructure activity, we know we will always need to add, adjust and remove aspects of our efforts. This feels aligned with the infrastructure mindset and it brings an always be MVC-ing vibe.
And then when we bring this into perspective of The AI MVC, we must shift our focus to working smarter. Yes, we must do more than less. Not because of a threat of a job reductions, but because we can and it makes sense to do so.
We should be looking at all our community activities and asking if they are efficient enough. Whether we've learned anything from it. And whether it helps us or our people.
Community across the org
There have been real shifts for community to be seen as not something done in isolation. Community people often talk about it, but putting it into practice is much harder and will take time.
The beauty of AI is that it's a tool that the whole org likely has access to and when we start to see it like that, we can think of the artefacts we can create that will support the whole team to do community better.
In that sense, it's not about figuring out how to automate all the things that always become difficult to manage and maintain, it becomes more of an educational process of showing the whole org better ways. Our goal, or one such goal, may be to empower the whole org.
Applying MVC thinking
My mind is increasingly in the community data aspect. Yes, we can own it. Life changes once you start getting seeing community data from the many angles of existence.
I'm not diving into data here, but I'd encourage you to think about where you may see community data:
- Conversations exist in...
- The daily places I or my people visit are...
- The knowledge I have acquired has come from...
And a word of comfort, everything in the MoTaverse started as a crappy MVC. Overtime it continues to improve. There continue to be many crappy things in existence, if you choose to explore. I'm getting better at accepting it, but I'm always committed to improving over time.
What continues to be true is that we hand crank things all the time. We experiment with ideas. Then we find ways to prioritise to build the thing, if we believe it deserves the investment.
So with the MVC mindset, I wondered how we could create a few of our core features with AI. Of course, none of these are full blown versions, but they start to help us see how it can be used. In all instances, anyone in the team can get involved too if they have access to the same tool you do.
I don't claim to have the best Claude skills, but these have been 'good enough'. If you don't get the result you need, you can improve it, and ask Claude to help you do so.
Claudes Skills are like a saved prompt that can be easily be reused, this makes it very easy to share with other people in your team.
1. Create a profile with AI
Central to our community are profiles. They are central to everything we do. It shows a real investment into our people, we are always trying to improve them, and they really are core to helping us make so many decisions.
You can check out my MoT profile.
So, I wondered, for those that don't have profiles, or even good profiles available to them, what would an MVC version look like? The following screenshot is an output of a profile I created with a Claude Skill.
The output is all based on publicly available data. It somewhat mimics our current MoT Profile. It's definitely not perfect, there's room for improvement, but the point here, and as it should be with AI efforts is that it is likely better than what existed before.
- anyone in the team can spin this up on anyone they may be talking to
- it's great to explore conversation starters
- it gives real information in an instant, which in the past would clearly have taken longer
- it shows how we can be curious about people and consider how they may fit within our community context
It's a useful team tool, not perfect, but it's progress, and I believe helpful.
Download the Profile Creator Claude Skill.
Description: Research a named person, using a LinkedIn profile, personal website, or background description to identify them, and produce a visual "profile card" HTML artifact summarising who they are - bio, location, recent work, years in the industry, badges, qualifications, a public-contribution star rating, and links to what they have made and appeared in. Styled loosely like a LinkedIn, Facebook, Instagram, or MoTaverse profile.
Use whenever a person's name is given plus something to identify them, and the request is for a profile, profile card, "who is this person" summary, or bio card. Trigger on "create a profile for X", "make a profile card", "build a profile page for", "research this person and make me a profile". Different from motaverse-member-researcher (MoT-only, text write-up) and community-company-researcher (organisations) - use this one for any individual when the desired output is a visual card.
2. Create a glossary with AI
A glossary is the most underrated community tool. To the extent that if I were to start a new community today, I'd seriously consider starting with a glossary.
A glossary is research into the lexicon of our people. We have one in the MoTaverse, it's Urban Dictionary inspired, and it's the most beautiful thing. It's co-created, any (paid) member can add a definition, and multiple people can their own definitions.
More recently, we've been using AI to tap into our content and transcripts to help us speed up the creation of glossary entries.
It's been super interesting as it taps into words that a human probably would've have dismissed. When a person defines a term it directly quotes and references it, and we would tag the person in the entry. Other times, when it is mentioned in passing, AI will create a definition itself.
Again, things like this is great for other people in the team. I could quite easily imagine 'marketing' wanting to explore the language they should be using, and being able to align with their people's language is crucial.
Glossary entries in general are quite useful for new members. They can be interlinked across the website, and general it's great for SEO/GEO/AEO.
Download the Glossary Creator Claude Skill.
Description: Extract potential glossary terms and definitions from transcripts, blog posts, articles, links, or any pasted text — for any community's shared glossary. Use this skill whenever someone shares content (transcript, link, or text) and wants to find terms worth defining for a community glossary. Trigger on phrases like "find glossary terms", "what terms should we add", "glossary suggestions from this", "new definitions from this", "create glossary entries", or any time content is shared with the intent of building or enriching a community glossary. Also trigger when someone says "look at this for terms", "what could we add to the glossary from this", or shares a URL to an article or blog post asking for glossary candidates.
Unlike glossary-term-finder, this is community-agnostic — it does not check against the Ministry of Testing glossary — and is meant to be shared with any community practitioner.
3. Do Community Pain Research (CPR)
I took a thing we actively practice and that I've written about in the past, Community Pain Research (CPR), and turned it into a Claude Skill.
In theory, we could or should be applying to this to all conversations we hold. But also, the beauty of this is that we can apply it to any content or conversation that exists out there.
This is so good at getting to the truth of things, it's so good that anyone in the team can use it too! And it's not the first time I've said it, but I do believe a good community conversation combined with CPR is probably more helpful and truthful than user interviews. We can learn to adapt the conversations we have with our people to help cover what is important to us as a business. There is massive room for improving these kind of practices in the context of community.
We may roll our eyes if we are already aware of things it raises, this is something to keep an eye on. Sometimes it can show that you are learning about your industry, other times it can be that the skill is not digging deep enough. Human in the loop, always, use it in combination with your own knowledge, bring insights to your team to have conversations.
Overall, I find it pretty exciting and useful tool to get moving with research and problem solving for the business.
Download the Community Paid Researcher (CPR) Claude Skill.
Description: Surface and structure community pain points (CPR framework) from conversations, posts, transcripts, or notes — then turn them into actionable research. Use this skill whenever someone wants to understand what their community is struggling with, asks "what are my members' pain points?", "how do I find what's frustrating people?", "what problems keep coming up?", "what should I be looking out for in community conversations?", or "how do I turn member complaints into useful research?".
Also trigger when someone shares a forum thread, event transcript, newsletter reply, or set of community observations and wants to extract and structure the pain signals within them. This is Skill 6 of the Community Discovery Conversations series from Rosieland. CPR is care work — understanding pain is how you show people you're actually listening.
Final thoughts..
The above are just 3 examples of using AI in community from an MVC mindset. I've been building up a set of Claude Skills into an online book, it's a work in progress as I convert my writing into a set of Claude tools.
Some takeaway thoughts:
- Everything starts shitty: really, it's ok
- Starting: it's ok to start with external data, the goal is to build your own
- Efficiencies: We have to be more efficient.
- Data: not just in the community platform
- Silos: think about how to break them down
- Enable the team: Create processes/skills that enable the whole org
Has this been helpful? Let me know in the comments, or elsewhere.
🐌
