 Thank you. How's everyone doing? All right. I know I don't look it, but I live in California and people are like, how's everyone doing? That's more like it. All right. So first of all, I wanna say a big thank you to Ian, to Dennis, to everybody who invited me to come and speak. It's funny when I walked in today, I was thinking this place looks really familiar and I realized I did a talk on this stage about 20 years ago. I can't remember what conference it was, but it's great to be here. So I was born and raised in Northern England, which until this morning, I thought was in this picture. And we had a conversation over there and we realized that this is in, I think, Oxfordshire. So I've been lying to people for the last three or four years about where this is. But I had a very rural upbringing and I didn't have any cows when I was growing up. But when I was growing up, people would always say to me, people don't know their neighbors like they did back in the good old days. It was this kind of refrain that the internet and movies and video games were kind of rotting our brains and ruining this kind of natural essence of what makes us people. But what was interesting to me is that around that time in the years since, we've seen all kinds of examples of communities forming. We've seen Wikipedia, where people have come together to document the world around them. We've seen the huge growth of open source. This is something that I feel very fortunate that I've been a part of since 1998. It's been amazing watching this movement form. We've seen the maker evolution, where we've been bringing together bits and atoms, where people can create all kinds of different devices and businesses and inventions. We've seen the democratization of funding with crowdfunding, which in many cases fuels those makers to start little businesses and build technology. And there's all kinds of examples of this, right? Harley Davidson built a community of 1,400 local groups all over the world where people get together to talk about their bikes. Ubuntu, this is a project that myself and my team at Canonical led for a number of years, where we built a community of about 50 million users and about 250,000 active participants in Ubuntu. People writing software, creating documentation, creating local user groups. There's Airbnb. They've built a huge community of hosts who get together to share insight and expertise about how to rent out your properties. Star Citizen, they raised $150 million in funding to build a video game that apparently no one really likes. Lego Ideas, this is pretty cool, which is where people can actually submit ideas for Lego sets, and if they're upvoted enough, then Lego actually builds them. And HitRecord, this is one of my favorites, why weirdly I was actually speaking at a conference and one of the other speakers was Joseph Gordon-Levitt, the Emmy Award winning actor. And I had an opportunity to speak to him for about five minutes, and he is obsessed about community. He set up this website where people create kind of shared creative work. Somebody does the green screen, somebody writes the script, somebody makes the music, and some of these things have been showcased at Sundance. So there's all kinds of amazing examples of community in action, and the tech world is filled with them. Linux, AWS, CNCF, Sneak, all kinds of examples of where communities are making a real impact. So clearly it works. There's something intrinsic in the human condition that makes this work, and the OSDU Forum is a great example of this, and everybody's trying to bite off a different piece of what they want to accomplish with communities. The tricky thing is how do you do it, and that's what I wanna talk about today. Now in the tech world, we see all kinds of great examples. GitLab, HashiCorp, Ubuntu. Part of the reason why these work is because developers fundamentally are interested in spending time in a collaborative environment. This is some data from Slashdata who do all kinds of kind of market and developer research, and they identified when they interviewed about 17 and a half thousand developers that open source communities, social media, which is kind of a type of community of sorts, and community websites and forums take up a huge amount of how developers go, stay up to date, source information, and build software. So the reason why this works is that fundamentally, a community is a network of minds, right? If you think about this room, every single one of you has had a different background, different upbringing. You look at the world through a different lens. You've got different types of experience, different perspectives. You've had some successes, you've had some failures. And when that lives in our own head, it's useful to us, but when we get that out into the open, into a shared space, we can really learn and grow. And what's incredible about communities is that it's not just about the education and the learning and the wisdom, it's about being with your peers. For example, I started a community leadership accelerator recently called the Community Leadership Core, and I brought in my first 10 companies. And one of the things that I didn't realize when they all came in was the feedback over and over as being, sure, this is great, I learned a lot about how to build communities, how to be efficient, but it's nice knowing that I'm not the only one facing these challenges. It's nice knowing that I'm not alone in this. And that's one of the huge values of communities. One of the reasons why we're gonna do breakout groups in a little bit is because you've all got way more expertise and insight than I do. We wanna get that out into the open. So the tricky thing is that building communities, especially developer communities, is risky. It's error-prone, frankly, most of them don't work. Most of them suck. How many times have you been to a forum, a Discord channel, a Slack channel, and it's dead? There's 1,000 people in there, no one's talking, no one's doing anything. And nine times out of 10, the reason for that is because it just doesn't offer enough value, right? Because most of these developer communities fail for one or more of the following four reasons. The first one is that they just don't have any value, right? They're not clear on who their audience is, they don't offer value to those audiences. How many times have you been into one of these communities and it's just a bunch of people asking questions and getting help? Why would you go back? The only time you ever need to go to someone like that is if you've got a question and you need help. The second reason is because some of them are mind-numbingly boring, thoroughly dull. Just lists of questions, people you don't know having conversations about things you don't care about. Why would you go back? The third reason is in many cases, especially with developer communities, is that they're a bit tone deaf. How many people here work in marketing? Put your hands up, thank God, okay. Got nothing against marketing people, most marketing people. But there's a certain marketing speak and when you talk to developers with that marketing speak, when you talk about leveraging and accessing the world through your single pane of glass and all this kind of stuff, people just switch off immediately. It's tone deaf. And one of the other reasons why communities often fail is because they don't ultimately deliver a return on the investment. So there's a lot of companies, for example, I work with a lot of early to mid-stage startup companies who hire someone who works in developer relations, something along those lines. They come in, they work for a year, they fly around the world, they do conference talks, they create social media posts, they create content, all kinds of different things. But at some point, if that doesn't get connected to the value for the business, the value for the organization, then it's gonna get shut down. So for us to succeed in communities, we need to invert all of these, we need to create value, we need to create exciting, engaging communities. We need to talk to our audiences like they would want to be talked to and we need to make sure that it's really impactful. So developer communities are risky, they're error prone. So to fix this, we need structure and focus and that's what I wanna talk about today. So what I wanna focus on is three main things. The first thing is the strategy. How do you go about building predictable growth in a community? One of the things that drives me bonkers is that I know so many people who work in the community space or so many companies who just throw online a forum or a chat channel and they say, go check out our community, it's over there. There's lots of nice people in there. And that's it, that isn't a strategy, that's winging it. Okay, it doesn't work. Nine times out of 10, that fails. The second thing I wanna talk about is planning. How do you focus on the right kind of priorities? This group is a good example. I haven't delved too deeply into the OSDU forum but I'm guessing that there's always a lot more things that you want to do than the time available, the resources available. How do we make sure we pick the right things? And then the third thing I wanna talk about is the value of iteration. There's two mantras I have in my world which relate to everything. One is progress over perfection. It's better just start doing something and start cranking on it than trying to be perfect. And the second one is iterate to awesome. The way in which we build amazing things is we start and we just keep just making lots of small minute changes and before you know it, you've got something that's absolutely incredible. Okay, so these are the three areas I wanna focus on. Let's start out with strategy. Now, does anyone know who this guy is? Anyone recognize him? Now, the fact that you aren't marketers means you probably don't know who he is because he's a marketing legend. So all the plastic-haired marketers, they love this guy. This is Seth Godin. He is a phenomenal author. He talks about marketing but he's not really talking about marketing. He's talking about how human beings interact and exchange value with each other. And one of the things that he said once completely underpins the philosophy that I think is a part of every single successful community that's out there. He says, if we're in service of other people's success, good things happen to us. So if you think about yourself, just your own personal experiences, the people that you have worked with, that you've mentored, it could be family members, it could be employees that have worked for you, it could be friends, where you've paid it forward when you've done something nice for other people. How many times does that then manifest somewhere down the line in something nice for you? It happens all the time. My whole career is banked on this. Like, one of the things I like to do, and I'm gonna make the same offer to everybody here, is I say to everybody, like, if there's anything I can do to help, just let me know, you know? For me, like, if you help people and you don't expect people to buy your stuff all the time, good things will come down the line. So if we can inject this into our communities, if we can say to our community members, I wanna make sure that when you come into this community, that you are gonna be really successful. I wanna help you to do amazing things, to build things you never thought you'd build, to learn new skills, to challenge yourself, right? If you do that, then all the goodness will come from that. So this is a philosophy that wraps around everything that I'm about to walk through. A good example of this is GitLab. Now, GitLab, when they started out life, we're seen as kind of a dodgy knockoff of GitHub, right? It largely looked like GitHub. It was set up by this guy at the bottom, Sid Sabrandi, who's a friend of mine, he's a wonderful human being who built a very unique company because GitLab are so unbelievably asynchronous. They operate like a community as a business, right? So for example, everything that they ever do at GitLab, they write down, they put it into their GitLab handbook. You can go and get it online, right? And in fact, if you go and look at it, it's over 2,000 pages long. So good luck reading that. I tried to read it, I didn't get through many pages. But whenever they learn anything, there's a culture inside of GitLab is write it down because other people might find it useful. They don't want all of that insight living in a single person's head. So they paid it forward. They invested in the success of their employees, they invested in the success of their community members of developers. This is where their chickens came home to roost, which Ian would like, because he had a farm with chickens and cows and all kinds of stuff. In 2017, some engineer, fat-fingered an update, the whole thing went down, right? Now they tweeted out about it and they did what every company does. They said we're experiencing some issues with our production database and we're working to recover it. Now, most companies at this point would call their PR team. The PR team would say, okay, don't talk to the press, don't talk to anybody, no tweeting, no communication, we'll fix it and then we'll have a grovelling apology. That's the playbook, right? GitLab didn't do that because they had this culture of engaging with their community. So the first thing that they did is they created a live Google doc and they invited their community members to come in and diagnose what the problem was. Like, whoever does that. And what this did is it generated unbelievable levels of goodwill on Twitter. Now Twitter, how many of you use Twitter, hands up? Would you say that there's a lot of goodwill on Twitter? My experience has been that there isn't always a lot of goodwill on Twitter. But this hug ops hashtag formed and people started wrapping their arms around GitLab. This production service went down. People couldn't build software anymore, right? This was impacting real companies. But they knew that GitLab was one of them, okay? What I found especially surprising was this one at the bottom where they spun up a live YouTube stream and diagnosed the recovery with community members feeding into it. It was remarkable. And this manifested, I mean, this happened what, five years ago? I'm still talking about it. I talk about this in almost every talk that I do because I think it's a wonderful example of paying it forward. And this is the result. Google Trends is not a great measure of success but in terms of just overall brand growth and recognition this is what's happened with GitLab. And what happened is that the IPO'd, SID's a brandy now, is a billionaire, life is good. So the first step in doing this is we've got to get really clear in our audiences. This is one of the mistakes so many companies make that I see over and over again is they want to build the community, they want to do the content and have the social media and they want to have the chat channels and all the rest of it. But often when I say to a company, like, who is your audience? Who do you want to bring to your community? There's a bit of fumbling. We want to be really clear on this. Now there's basically three priorities when it comes to developer audiences. And this is what I recommend for most companies. The first one is the people who are consuming your technology, the people who you want to use the software that you're building, the people you want to come to your events, this group of people, basically. So you've got to focus on adding value to those folks, first of all. The second priority then is the kind of people who build plugins and extensions. Because really to do this, what you've got to do is you've got to ship an SDK, you've got to ship an API, and you've got to basically enable an environment where people can build things and then ideally create an environment where people can then share those things. A great example of this is WordPress. WordPress have got a huge plugin store. There's about 50,000 plugins. Some of them are paid for, some of them are open source. Anybody can really go and make a WordPress plugin and then they highlight the really popular plugins inside of WordPress. The third priority then is open source developers. Now a lot of companies will go and start with the open source developers because the mentality is well we want people to come in and spread the load in terms of building our software, which makes sense. The tricky thing is that building an open source community, as I'm sure many of the people in this room are aware of, there's a lot of moving parts. You've got to create an environment where you have a level playing field for everybody. You've got to have great documentation. You've got to have community meetings. You've got to have governance. You've got to have codes of conduct. You've got to have all these different pieces. There's a lot of complexity and nuance in this. But fundamentally, everybody starts out as a technology consumer. To convert those people into a plugin or extension developer is not a big jump, right? If you're a developer, download an SDK and building something is relatively straightforward. And then if you've written some code, if you've written an extension or a plugin, now contributing to the open source project is a logical thing to do as well. So this is the reason why I recommend you go down these priorities. I always recommend pick one of these, start cranking, and then again, we iterate and iterate and iterate. Now, the other thing we need to deal with when we think about strategy is, I don't really have a word for this, but it's kind of like the community equivalent of sticker shock. You know, like when you wanna go and buy a VR headset or a car or whatever it might be and you look at the price and you're like, whoa. For many people, when they come into a community, they see this, this is a Discord channel. I'm not picking on DIYs, they're actually a client of mine. They're a wonderful company. But if you look at this for the first time, it's completely overwhelming. There's all of those channels on the left. There's all of this discussion in the middle. There's all of these people I don't know on the right. Most people look at that and think, no, I don't understand this, this is too much and they eject, right? So the vast majority of companies that are foundations or working groups, that's the first experience that people have a community. What we wanna do is we wanna lower people gently into the bathwater, okay? So don't start with platforms. Don't start with discourse, Discord, Slack, you know, Buddy Boss, whatever it might be. Start with the strategy, which I'm gonna walk through in just a moment. But fundamentally, what we wanna build is a journey. We wanna build an experience, okay? To give you an analogy, when you go to Disney, how many people here have been to a theme park like Disney World or Epcot or Lightwater Valley, if they're still around, I don't know, in the north? Center parks, wherever else. Disney's a good example. When you show up at Disney World, you go on this little journey. From the minute you drive in and the parking people navigate you to your parking space and then when you walk over and you buy your tickets and then when you get in there, they give you a map and then you kind of walk around the park and it's a very natural progression and they have parades at certain times the restaurants are very carefully placed, the toilets are very carefully placed. They've designed an experience. They started out very simply back in the 50s and they've iterated and iterated based upon feedback. And it's a fun, pleasurable experience that is predominantly pretty overpriced. Another example of this are great restaurants, right? I discovered this last night, went out for dinner with a client of mine. We went to an amazing Indian place called Jim Khanna, if anyone's been there. 9.30, sitting last night, which was great. I discovered that if you have a tasting menu of Indian food at 9.30 at night with a bunch of cocktails and then the AC in your room doesn't work and you have jet lag, you wake up at four o'clock in the morning wide awake. So, but when you go to a great restaurant, what happens is from how you, if you valet your car or you get sat down and they bring you water or they bring you menus, everything's very carefully curated. It's the same thing with video games. Like this is Luigi's Mansion 3, bought this for my son about three years ago. First level is helping you to pick up the controls, right? We need to do the same thing for our community. And one of the breakout sessions later on is onboarding. That's what this is all about, right? So if we look at these failure points that we talked about earlier on, what we wanna really fix is these two. We wanna fix the community being boring and not offering any value. Because if it's boring and it doesn't have any value, then why on earth would anybody come back? So this is where I'm gonna walk through a model of mine which is gonna fix this, okay? And what we do is we, this is what the model looks like. Now don't worry, I'm gonna walk through this step by step. So first of all, we're gonna start out with this little guy over here, okay? This is your audience member. So remember earlier on when we talked about the three different types of audiences, this is your audience member. And the first thing we wanna do is to figure out what is that person's pain points? What sucks about their life? So imagine you're a dentist, you've got two people stood in front of you, a woman who wants to get her teeth whitened and another woman who's got horrendous toothache. Which one of those two people is gonna demand you as a dentist more urgently? It's gonna be the person with the toothache, right? A lot of communities and companies and whatever else, they go out and they publicize, here's all the cool things you can do with our technology, here's all the cool things you can do in our community. But if you instead of focus on what sucks about someone's life and you help them to fix that, instantly you become more interesting to them. So for example, if you look at a front-end developer, somebody builds a website, any front-end developers in here? No? They're hanging out with the marketing people. So there's two types of pain points. There's the narrow pain points. These are the kind of things that front-end software engineers struggle with. It's dealing with cross-browser issues and debugging horrible conditions and performance issues and managing security fixes and things like that. These are the very specific technical things. So if you think about the audience for the OSDU and you think about what are the specific technology problems that suck for people, that's a great place to start with your pain points. But then we have the broader pain points. These are the things that impact the people more broadly, right? More generally. So if you take a typical developer, a typical developer will face all of these issues. There's been a lot of tech layouts recently. People are gonna be worried about that. They often deal with difficult bosses or stakeholders. A lot of engineers have to wrestle with product teams and security teams and design teams. There's blockers on getting designs through before they can write software. So if we look at every one of these, it's just an example, and by the way, I use chatGPT to come up with this list, which is very powerful. May we respect our robot overlords? If you turn each of these inside out, you find value. So for example, if we say managing blockers, so like an engineer is asked to build a piece of software and they're waiting on designs, right? Well, that's something a lot of engineers struggle with. If you create a piece of content or you run a workshop or you do a webinar or you put together an e-book, walking through how to resolve that blocker, instantly become more attractive and more interesting to those audience members. That's step number one. So figure out the pain points. Now what we wanna do is we wanna get up to that star, and that star is a piece of value that requires very, very low friction, okay? So remember the screenshot I showed you earlier on of the community. If you land in there and you see all of that noise, those channels and things going on and people you don't know, it's completely overwhelming. And the reason why it's overwhelming is because there's not enough value in your mind in that community to justify wading in there, right? If you knew that that community was gonna be really valuable to you, you'd put up with it and you get on with it. So what we need to do is we need to give somebody a really amazing first experience, and that's what that star is. And those numbers one to six are the steps to get there. Now there's lots of different things you can do to onboard people, you know? Here are a couple of examples. The first one I always like to recommend is to do an online workshop, a webinar, training session. Somebody signs up with their first name, their email address, you teach them how to resolve one of those pain points. You can do hackathons, get people together to hack on software around a specific focal point, provide some prizes, developers love them. You could do live streams. I wouldn't recommend these right out the gate because they take a while to get going, but what's nice about all of these is that you see people's faces, you see people engaging, you can interact, okay? You can do in-person meetups and events. You can do live coding sessions. You can put newsletters out there. You can have pre-built training. You can create research and publish that research. There's lots of different mechanisms in which somebody can just give you their first name and their email address and you can give them some real value. And now what they do is they now start associating, huh, that organization were useful to me. That's pretty cool. That's the first step of the process. Now what we do is we nurture them. We don't bring them into the community yet. It's too early. And what we do is we nurture them in a couple of different ways. The first one is with email. Now there is a perception out there that developers don't read marketing emails. That's true, but developers do read emails, but they read emails that have got actual functional content. If you send out an email that's just full of beautiful imagery and it's got a button that takes you to a website, nobody reads that. Not just developers don't read that. Nobody reads that. It's garbage, right? But if you send emails that have got technical content, tutorials, real material that's baked into that, you can get double the open and click rates in the emails. Like my own emails that I send out to people who sign up for the things that I do, my open rate is like 46%. Industry standard is 22 to 24%. It's nothing special to me, but my emails, plain text, but lots of content baked into it, okay? So imagine they come to your webinar, your event, your workshop, whatever it might be, and then you start sending emails. I send an email once a week, every four days on weekdays, and I have tons of them. Every time I create a blog post I repurpose it into an email. I've got over a year's worth of emails. So even if they never come into the community, if they never come to any one of the events, they're always getting that value sent to them focused on those pain points. Another thing you can do is more events. You can do meetups, you can do office hour sessions, Q&A sessions, you can augment this with social media, Twitter, LinkedIn, Facebook, things like that, okay? So what we do is we create this nurtured flow and then in those communications, what we do is we bring people into the community. So imagine this, you're a developer, you hear about this webinar workshop type thing, you sign up for it, you go to it, it's pretty cool, it's useful, it solves one of your pain points. Then you get an email once a week for the next six or seven weeks solving more of your pain points. Now you're thinking, wow, this is actually really useful. Now when someone says, hey, do you wanna come and join our community? We're doing some really cool things. You can be thinking, yeah, I'll check it out. And then you confront it with that image, all those channels, now it's a lot more palatable because you've had a lot of value. So when they come into your community, they join as casual members. This means that they're not fully bought in yet. They show up to your community and they're like, eh, this looks kind of interesting, but they may show up one day, they may not show up the next day, they may casually kind of show up here, they're in everywhere, okay? We cannot depend on them coming back every single week. We wanna convert them into regular members where they come back every single week, regularist clockwork. Now to do this, we need to focus on nurturing them again for two months. The reason why it's two months is that scientifically it takes 66 days to build a habit. So when I moved to America 15 years ago, I'd never exercised once, did not grow up around exercise. Parents, not exercises. My wife is an exercise lunatic, right? So she immediately started haranguing me to get on elliptical, I didn't know what an elliptical trainer was, go out running, whatever. At the beginning I hated it, but then gradually as it kind of got drilled into me, now I'm in a position where like, if I don't exercise, like I'm not exercising this week because I'm on the road and I don't like going to hotel gyms and stuff like that, I feel guilty. So what happens is if we week by week give people a reason to come back, it becomes habitual to them and then they're back every week and that's how we build scale and growth in the community. Now the way in which we do this is every week we've gotta have attractions, just like Disney World, right? People wouldn't go to Disney if they weren't Space Mountain and it's a small world and all those rides, right? In the same way that if you open up Netflix and it's the same five TV shows every time you open it, you'd never open it back up again. The only reason why you go back to Disney, it's because they keep adding new rides, the only reason why you go to Netflix is because there's always new TV shows and movies appearing. So every week we wanna be posting new things to keep people coming back and what we do is we post what I call the three C's, content, conversations and carrots. So content is where you create essentially tutorials, demos, things that teach people skills that resolve those pain points, right? Again, chatGBT is actually really helpful in constructing this kind of material, right? The key thing about chatGBT is you have to edit it. Like it's a bit robotic if you don't go and edit it but it can generate a lot of really insightful material if you teach it effectively. One piece of content a week is what I recommend. Conversation starters, two week, Tuesdays and Thursdays, put them out there, right? And this is just where you kick off a question. You just ask the group something, right? And then carrots, which I'll get to in a moment, are recognition and rewards, right? So content, for example, looks like this. This is from the LFX forum. LFX is a suite of open source tools that the Linux Foundation have created. And they're a big client of mine. And one of the things I said to Henry who started running the LFX community was every week put a piece of content out, step-by-step instructions. This is in their forum, okay? So every week people are coming back because there's something new to learn about how to use LFX. An example of a conversation starter is this. This is from my community leadership core accelerator and this is a member who said, I obviously blocked it out because I want to protect their privacy. Hey, everyone, question regarding how do you manage your community? Which tools do you use it? We're considering using HubSpot to manage the community members and I'm wondering if this is the right choice. 10 replies, okay? People started feeding into that. So put a couple of those out every week. And then when it comes to carrots, recognizing people, oh, I didn't add the carrots in there. Let me explain what carrots are. There's two types of carrots, right? You've got intrinsic rewards and extrinsic rewards. Extrinsic rewards are swag, books, caps, mugs, things like that. That's fine. What's more important is recognition. Is just say to someone, thank you for creating this piece of content. Thank you for contributing this code. People like you that make our community special. I don't care whether you are the CEO of Starbucks or whether you are a road sweeper. Every single one of us needs to be validated. We all need to know we're on the right path. And something as simple as an email, especially coming from your community leaders, means the world. It's way more important than some crappy hat or mug that you send out to somebody. That stuff is fine, but the intrinsic validation is more important. So if you put the piece of content out every week, a couple of conversations start us out every week, gradually, and you engage with them, you interact with them, they'll become regulars. And then a small number of people, well, sorry, the regulars, what they will do is they will mentor your, this is important, they will mentor your casual members. So this is again how we build scale. So then when somebody kind of goes through this journey, you run into the workshop, they come in, they enter in, instead of you and your team having to go and mentor them and guide them and all the rest of it, your regulars are gonna start doing that. And also your regulars, the folks, the way if you say to them, hey, would you be interested in creating a piece of content? They're probably gonna say yes. Would you be interested in creating a couple of conversation starts? They'll probably say yes. Would you be interested in speaking at one of our events? They'll probably say yes. If you ask the people in the casual phase, they'll say yes, they won't do it. If you ask people at the beginning, they'll say yes, they definitely won't do it. Okay? And then a small number of people, usually about one in every hundred, will become your core members. And these are the people who just become fanatically excited about the community. They just wanna make the community an amazing experience for everybody. And I'm sure you all know the names of those people in the OSDU Forum community. So in terms of sequencing, I would recommend when you build a community, start out figuring out those pain points. Then what you do is you identify that thing to bring people in. Marketing people call it a lead magnet that brings people in. Then you focus on nurturing them. And then you focus on just getting that regular cadence of content, conversations, and carrots out there. And this will significantly increase the likelihood of success in the community, significantly so. So now let's talk about planning. So we have a model for how to build out the community. Now how do we figure out what we're gonna do? Okay? Does anyone know who this is? Yes! I am Maiden. Would you agree that they are the world's greatest rock band? Your pause does not infuse me. He's like, no, nickel back. So I am Maiden are an amazing band in every conceivable manner. I've been a fan of them since I was eight years old. I went to see them when I was 11. My dad took me. And last year, I took my 10-year-old to see them as well. It's like part and parcel of who I am. I have a weird obsession with I am Maiden. It's funny because my kid said, when I took him home that night, he said, dad, when I'm a dad, I'm gonna take my son to see I am Maiden as well. I'm just thinking. I don't think so, son. Chat GPT can't do that quite yet. Now I am Maiden, they're a huge band. They fly all over the world and they bought a plane or they rent a plane and they put all this I am Maiden library on the side of it. And their manager is this guy called Rod Smallwood. And he puts together these huge tours where they're traveling to far-flung parts of the planet. They've got to figure out visas and they've got to get crew. There's crew in the front of the plane and then the back of the plane is all the gear. They have these massive stage sets. And he was asked, how do you pull this off? And he said, just make a plan and stick to it. It's pretty straightforward. And I agree with him, but it's not that straightforward. It's not that straightforward in just making a plan and sticking to it. Fundamentally, his point is, you've got to be organized and we want to do the same thing in our communities. The first step in terms of how we build great things is we gather requirements, right? And there's all kinds of ways in which we can do this. You can look at the available data that's out there. What kind of technologies are people using? What kind of usage rates have we got? What are the patterns that we're seeing? You can look at one-on-one stakeholder interviews. I love doing this, right? If you're going to build anything, just contact 20 people and just get on the phone with them and just talk through, what do they want? And I especially like to say, what sucks about your life right now? What could exist that will make your life suck less? You can look at formalized surveys where you can send out surveys to everybody. One of the things I do in my work is I survey at the end of almost everything that I do. So whenever I run one of my group huddles for my community leadership core members, there's a survey that goes out. When I run live events, there's a survey that goes out. When they complete a training that I've built, a survey goes out. And I want people to give me data every single step of the way, okay? Because then you're always fixing those little blind spots. Product-led growth. This is a huge thing that's stepped into action where we actually instrument mechanisms into software where we can figure out usage patterns and then we can design things around them. You can also look at things like industry trends. I looked at Slash Data earlier on. They're a great company that shares kind of industry trends. But the point is we take a multifaceted approach to figuring out what our audience wants. The problem I think with, you know, when you're building any kind of software, any kind of community, is we've got a kind of guess. And, you know, I've been doing this for 22 years now. So when I built my community leadership core, I was thinking, I think I know what people want. And then when I got the survey results back, I was like, I was pretty wrong on a lot of these different pieces because everybody's got different needs, everybody's got different requirements. So gathering requirements, I think, is one of the most critical things that we need to focus on, first of all. The key thing is that we gather these requirements on a regular cadence. And cadence is something I'm gonna talk about in a moment. One of the things I learned when I was at Canonical when we were building the Ubuntu community, and this pre-existed before I joined, because I joined Canonical about a year into Canonical forming. I was one of the first non-developers at Canonical. And they'd already built this concept of a six-month cycle. So at the beginning of the cycle, I'll get to this in a moment. They planned out a bunch of work and then at the end of the cycle, they shipped Ubuntu. And at the beginning of every cycle, we gathered requirements. We talked to companies, we talked to community members, and getting into that cadence was helpful because then every single time we did it, we figured out not only what the requirements are, but we went and optimized the process of gathering requirements in more efficient, more effective ways. So this is what a typical cycle looks like. This is something I write about in People Powered. Now it doesn't have to be six months. I would recommend six months when you're building software, but basically what you do is at the beginning of the six-month cycle, you say, what do we wanna do? And you get really concrete. You say, what are we gonna ship? You write down things that you can say, did we do this with a yes or no? The problem is that in these kinds of requirements gathering exercises, people usually say things like, I think we should make it faster. Okay. I think we should make it more blue. That doesn't help, okay? But if you say, I think we should optimize the page loads on the website by 20%. You concretely can track that as a target. So what you do is at the beginning of the cycle, you go through all of your requirements gathering, and this is something I would recommend your community does. Maybe you're doing it already in some form. The beginning of the cycle, you go through your requirements gathering. It's a formalized process that everybody gets to feed into, and what you say is, this is not a Christmas list, right? Just because you say you want something, there's no guarantee this is going to happen, right? Because we're a community, and if we want to build these things, we have to come together to build these things. But we want to make sure we understand what everybody wants, okay? So you go through that process, and then what you do is you stack rank it, you figure out, okay, who's going to do what, who's going to work on what, and I'll walk through how we did this in a bunto in a second. And then every week, you have like regular sync meetings, where you say, okay, how are we doing with this progress? And then midway through that, you have a quarterly review. You basically stop halfway through, and you say, are we still working on the right things? How are we working? Are we making progress? Are we on track to hit all of these different things? If this is, it's basically project management. And then at the end, what you do is you do a cycle review, and this was the most powerful element of this process, is at the end of an bunto cycle, we'd say, okay, did we achieve what we set out to achieve? And I'll give you an example. One guy who worked for me, this guy called David Planella, who's an amazing community leader. After Canonical, he went and led community at GitLab. And the very first cycle he worked on, he was running our app developer strategy, and he had like about 50 or 60 tasks to work on. He got through about 20 of them. And it wasn't laziness. What we identified was, one, he was vastly overestimating how much he could deliver in six months, and two, me as his manager, I was not providing him with the right kind of support and guidance that he needed. So we fixed that. The next cycle, he got through most of it, not all of it, and then the third cycle, he got through everything. So the benefit of this is that you're always then iterating on how you work together, and I think that's how we make communities better. And I'm gonna talk more about iteration in just a moment. So the way we did this in a bunto is that, and it doesn't have to be this way, but I think it was a really effective way, is that at the beginning of that six month cycle, people would say, okay, what do we wanna do? So this is an example we wanted to do automated server testing. And there's an owner in here, which is Robbie Williamson, not Robbie Williams, by the way, two very different people. And what would happen is, there'd be conversations at an event that we ran, the Bunto Developer Summit, and then all of these different work items would be tracked in this thing called specification. Based upon those specifications, all these things that people wanted to work on in the six month cycle, they would form the schedule of our developer summit. We'd get together every six months, and we'd alternate between Europe and the US. We'd put together a schedule, and this is what it looked like. You can see up here in the top left hand corner, that's the schedule. They're all essentially unconference sessions. They're all discussion sessions. They're all kind of like, when we do the breakouts later on, there were very few presentation sessions, and it was all talking about like, what are we gonna work on? And there was a culture inside of our Bunto Developer Summits where if somebody says, oh, we absolutely need this, where somebody else would say, great, you volunteering. And in many cases, people would say, well, it's not gonna happen. This is not a wish list. This is a place where we figure out what we're going to build together. So if you focus on that six month roadmap, if you wanna do that, this is how I'd recommend you approach it. First of all, you create something called a strawman. This is where you basically say, okay, what are a set of objectives that we think we should work on? Bring together a group, a smaller group of people inside of the community to build that out. Then what you do is you gather a whole bunch of feedback from your broader community members. It's better to start with something than start with nothing the first time you do this. Further down the line, you can have a big comprehensive process. The third thing is that you then refine some of the KPIs. You say, okay, well, what does it mean to actually ship this specific thing? We gotta get really specific. Anytime I ever see an objective or a work item that's things like make this better, make this faster, stop this sucking as much, it's too fluffy and you will never, ever get a good result out of that. But if you can say, can I answer whether that was done yes or no? If you can say that about an objective, then you know you're picking the right kind of detail. Then what you do is you gather additional rounds of feedback about the KPIs and we're tracking the right things. And then you lock it in, you start working. This is what we're gonna focus on in the next six months. And this big rocks approach is really powerful because the idea is it's big rocks, these big objectives, and then you break it down into small pebbles, which are the individual items within them. Now this is a fairly comprehensive process. Another option in terms of how you do this is that you manage it on a quarterly cycle. Now this is harder for bigger organizations, but if you've got like a small sub-community or if you wanna build a community around and you're just starting out, six months can be a long time for small teams. So what you can do is you can work on a quarterly cycle. So let's say we look at Q2. You do a shortened version of this. At the beginning, you plan it out, you evaluate your priorities, you review the data points, you gather requirements, you set your set of goals and owners. And then what happens is at the end of the cycle, you review it. What worked well? What didn't work well? And then you plan any changes that you want to make. You essentially do the same thing, you just shorten it down to a quarter, okay? One of the nice things about taking a cycle-based approach is if you can say like, when we would build these roadmaps for Ubuntu, this is what's called, does anyone here know what a burn chart, a burn down chart is? Hands up if you know what it is. Okay, so some people don't know. I wanna make sure I explain this. This is a really cool thing. I love burn down charts. So here on this axis up there, on the y-axis, is the total number of individual work items that my team and the community had set for this six month cycle, right? The x-axis is the six months. And the big thick black line there is what's called the trend line. Every day we had a piece of software that would go and look at all of those work items and plot the line. And if it's orange or red, it means that it's still to be done. And if it's green, it means that it's been completed. And you can see up there the legend, but that's the main thing you need to care about. I knew, looking at this instantly, and this is hundreds of people participating in these different work items, I knew that so long as I keep the orange and the red under the trend line, we're on track to hear everything. So when you know you've got a specific number of items to complete in a fixed timeline, this is really powerful. I actually use this to write people powered. I created a burn down chart to make sure I was writing the right number of pages every day, for example. Now another way in which you can do this is you can be a little bit more explicit in how you track the work. So for example, in the community leadership call, which is my accelerator, at the beginning of every quarter I generate essentially a roadmap for my members. So at the beginning of every quarter, they go on and they fill in this massive survey of about 80 questions. Takes about 10 minutes for them to go and fill it out. They're all yes, no questions. And it's things like, have you implemented gamification? Have you defined your audiences? Are you running online events? Are you running live events? Are you, do you have governance committees, right? And for most of these companies, even the fairly mature ones, they're answering no to most of these things that they haven't done it yet. So what I can then do is I can figure out, okay, what are the next steps for them in the journey for each individual company? And I send them this thing called an action cycle report. This is an actual company that I've anonymized. And at the top of this action cycle report, I say these are the things I think you should focus on. I call them recommended focal points. So this is a company that's quite new at building community. They're a little startup. So this is like create your audience personas, deploy your community platforms, deliver regular conversation starters. And for each one of these focal points, I've got pre-built training that they go and watch, okay? Then for each of these items, I've listed out individual work items that they need to focus on to complete that. And then they go and check these off as they go through. So you can see here, they're kind of almost done with this particular item. So it's very granular. So what I did is I basically have created a single place where they can go and track this. And you could obviously do this for yourself as well. I just automate a whole bunch of this. Here's another example, conversation starters. And then I also generate a couple of graphs. I show the four stages of maturity in a community. Activate is when you're just kind of getting going. Foundation is where you're really spending up repeatable progress. Expand is where you start bringing a lot of new people into your community. And then empower is where you convert your community members into leaders. And then I also generate something called a skills index. And this is something I'd recommend you build out for your companies. I've defined eight levels, sorry, eight different areas of community skills. So value, engagement, content, incentives, awareness, collaboration, events, and leadership. There's 10 levels for each of these different eight areas. And I plot how far they are in this. So you can see here with this company, they're pretty good. They're halfway there in terms of really defining a really concrete value proposition. They've done a little bit of leadership and they've run some initial events, but they've done nothing when it comes to content or engagement or awareness. So now I know the areas in which I need to focus. So having a central place like this where you track this work is super helpful. So if you have, let's say, with a community leadership call, we have quarterly cycles. Whether you have a quarterly cycle or a six-month cycle, having a central page where you track everything is really powerful. It means that your community are all together. So the final thing I want to talk about is iterating. So far we've identified, okay, what's the model? Identify pain points, give them something valuable to kind of attract them in, nurture them, bring them into the community. We can track this work and prioritize this work on these six-month or quarterly cycles. Now we're working, but how do we iterate? How do we make it better every single week? One of the biggest mistakes I think people make when they build communities or they do anything is they try to map out a perfect version of the future. Instead of just getting started and setting the expectations with everybody, we're just gonna iterate. We're gonna make it better and better and better. So for example, when I launched my community leadership call, I launched it at the beginning of March and I said to them, my first 10 companies, just so we know, this is gonna be imperfect, right? Because it's my estimation of what you all want. In that first month, I must have made hundreds of changes based upon the feedback and I made it a safe environment to say it's not gonna be perfect, right? If I projected perfection, it would be a very, very difficult environment to operate in. I think this is really important for every community, so you say to everybody, this is imperfect, but we'll make it better together, okay? This is where progress of a perfection comes in, it's much better to just get something out there, start iterating, it doesn't have to be bad, but I think it was the CEO of LinkedIn said, if you release something and you're not embarrassed by it, then you release too late, right? So progress over perfection is everything. And this is all about mindset. The mindset is what we put out there is a raw piece of clay and then bit by bit together, everybody's gonna have a little tool and we're all gonna hammer it into something that's really beautiful, okay? Now I'm gonna give you an example of this that the marketing world do really, really well and that's webinars, right? You don't have to pay attention to these numbers, this is just illustrative of the point. So when people run webinars, they create what's called a funnel and it's a set of steps that you go through to join a webinar and typically it starts out with you advertise the webinar on Facebook or LinkedIn or whatever it might be, you click on the ad, it takes you to a landing page, you talk to all the valuable stuff that the webinar's gonna teach you. Then you register for it, you receive a bunch of email reminders saying, remember, webinar's happening in two weeks, remember it's happening in a week, remember it's happening tomorrow, then there's the actual live event that hopefully you show up to and then there's some kind of call to action. It might be selling you a product, it might be having you download an ebook or registering for a conference. There's always something in the last five or 10 minutes of a webinar that they want you to do, okay? Now this is where the iteration comes in, is that for each of these different pieces, we set a target metric. So for clicking on an ad as a general rule, these are all industry standard numbers I'm gonna give you. Again, you don't really have to pay attention to the numbers, unless you wanna run a webinar. Industry standard, if you're getting about a 2% conversion rate on your ads, you're doing okay. At least one in three people who hit your landing page should convert into registered attendees of your webinar. Two to 4% of people who get your email reminders should click on the links in your email. 22 to 24% should open your emails. 40% of people who registered for your webinar should come to the webinar. And then around 10% of people who showed up to the webinar who stayed to the end should take advantage of the thing that you're offering at the end. Now, the reason why this is valuable is that when we track these numbers and one of these numbers doesn't perform, we find the leak inside of our funnel, okay? So for example, imagine you run, everything else is performing as it should. You get a 3% conversion rate in the ads. You get 40% of people converting your landing page. You get 3% people click on your emails. But 20% of people show up to your live event. Now, what that tells me is we didn't provide good enough content in our email reminders. We needed to make it more compelling. Maybe we need to send them a calendar invite. That's the reason why they didn't show up, right? We can diagnose that point without focusing on the whole thing. Imagine only 10% of people convert on your landing page, okay? Oh, well now we know we need to make the landing page better. We need to make it more compelling and more exciting headline. We need to explain the benefits that they're gonna get out of it. This is the point of iteration, is we measure these different pieces in our community and then we iterate over and over again. I know this one guy called John Asraf who built a funnel like this for a product that he sells. He built it 10 years ago. He's made $100 million from this one funnel. But he spent 10 years obsessively tweaking every tiny detail of it, okay? I don't know if his product's any good. I'm not encouraging you to go and buy it, okay? So one of the first things we can look at is the metrics, right? So these are the metrics I recommend you focus on in the community. Overall traffic, people showing up into your community. You wanna have a 10% month-to-month growth. So if you have 100 people show up to your community last month, this month, 110 people should show up, all right? So if you're getting fewer than that, show up to your community, great. Now we need to figure out how to get more people in. We need to bring them in with social media or emails or whatever else. Signups, 10% month-to-month growth. If you get 5% of people who are signing up for your community, then we know we need to increase the value proposition. Why should they sign up? What benefits can you offer them? What are all the things that are gonna make their lives better? What are all the pain points you're gonna solve? Active users, 20% daily active users divided by monthly active users. D-A-U-M-A-U or down hours, some people call it, is a standard metric in which people use to track web applications, okay? So one in five people who are actually showing up in your community, so who like to look at it, one in five are gonna post, reply, respond, okay? This is the most important metric. If you're below that, then that's the first and most important thing you should focus on. Growth is irrelevant if people aren't participating. And then likes, this is kind of a blunt way of evaluating sentiment. If you're getting a 10% month-to-month growth of people liking the material in your community, people are generally pretty happy, okay? So this is the place where I would start. And then what you can do is within this quarterly cycle, you can evaluate that at the beginning of each cycle. You go and take a look. Are we hitting these numbers? If we're not, let's think of some new things that we can do to kind of move through it, right? And this is where the review phase of the cycle is so important. And that, my friends, is it. Thank you.