{
  "path": "/post/ditching-one-community-idea-per-month/",
  "site": "at://did:plc:45uheisi25szrjvjurfpritx/site.standard.publication/3mgfeypogdk2r",
  "tags": [
    "Community",
    "DevRel",
    "Product Management"
  ],
  "$type": "site.standard.document",
  "title": "Ditching \"One community idea per month\": Our hackathon path to 80+ community projects",
  "description": "Learn how we transformed community engagement through hackathons instead of monthly idea quotas, creating 80+ community projects while building better understanding between community and product teams.",
  "publishedAt": "2025-10-16T00:00:00.000Z",
  "textContent": "A question popped up recently in a product community: \"Should we commit to implementing one community idea per month?\"\n\nThe underlying tension will be recognizable for many community managers:\n\n- Your community members share ideas and feel like they disappear into a void.\n- Product teams are drowning in suggestions and struggling to show they're listening.\n\nI've learned that promising to pick one idea per month (or whatever your number and frequency is) doesn't really solve either problem. Let me share what worked for us, even in our small-scale enterprise-community setting.\n\n(Note that while I've applied this to a developer-community, this can also work for a non-developer community, see further below)\n\nThe Problem with Fixed Quotas\n\nWhen you promise to implement one community idea per month, you're creating a system that sounds fair but can actually work against you.\n\n- Ideas are cheap. The product team is already drowning in them.\n- Ideas might not align with your product direction or desired impact.\n- Ideas vary in size. A lot.\n\nYou're also setting up a competitive dynamic where community members are essentially competing for limited slots and you also cap your potential upside. That's not the kind of culture and practice most of us want to build.\n\nWhat We Did Instead: The Hackathon Approach\n\nWe started running regular public hackathons in 2024 at our own offices and at partner or customer locations. Resulting in over 80 public projects now live on the Spryker Community GitHub, with typically 3-5 teams participating per hackathon.\n\nThe approach was surprisingly simple but had some specific elements that made it work:\n\nWe pushed every team to publish their results to GitHub under an MIT license as reusable modules. We provided boilerplates to make this easier. We also recorded team presentations at the end of each hackathon.\n\nThis meant what teams created was:\n\n1. Instantly reusable by the community the very next day, or ready to be developed further in a future hackathon;\n2. Documented, including the team's vision and ideas for future use;\n3. Ready to be picked up by the product team if they chose to do so.\n\nHackathon team presentations at the Berlin office, September 2025, with\nmultiple members from the Spryker Product and Tech teams on-site.\n\nThe Key: Making Success Independent of Product Team Pickup\n\nThe biggest challenge for any hackathon participant is making sure the \"what's in it for them\" is clear, immediate, and not dependent on whether the product team picks up their work.\n\nFor developers, this was somewhat easy: They could have a great hackathon simply by learning from building something with others, nerd out about the latest tech and have a pizza and beer together. Regardless of what happened afterward with their code. We stimulated participation with prizes, which helped with motivation, but the intrinsic value was already there.\n\nI've also done this format at other companies with product managers and designers. The output is less directly usable, but when it's something tangible like a wireframe, user research result, or video explaining the ideas, it still provides value and makes it much more interesting to a product team than \"an idea\".\n\nPotentially counterintuitive but important: We never force these teams to work on specific features. Instead, we discussed hackathon themes with the product team beforehand (and set technical winning criteria that were the same accross all hackathons), but we always left the exact features open.\n\nAs facilitators, my team makes sure that the community efforts both:\n\n- Stayed away from things already in active development (preventing duplicate work)\n- Focused on either things the product team wanted to build \"next\" (to get POCs/MVPs of different solution directions) OR work on things that the product team specifically would NOT build so it could live on as a community module and provide value that way.\n\nThis gave participants lots of freedom and resulted in a good mix of funny, innovative and also serious enough projects that contributed to our north star: getting more community-driven innovation into our core product.\n\nHackathon team presenting their Apple Vision Pro shopping project. Did it make\nit in to the project? No. Was it innovative, fun and a great learning\nexperience? Heck yeah!\n\nThe trade-off: You need some volume\n\nHere's the honest challenge with this approach: To get a meaningful amount of actual product innovations, you need volume.\n\nBy leaving topics open, you create space for creativity but you also accept that not every project will be product-ready or even product-relevant. Some will be experimental. Some will be quirky. Some will be brilliant but not aligned with your roadmap.\n\nThat's actually fine. It's a feature, not a bug. It's a great motivational and bonding event for the participants. Who doesn't want the freedom to solve that pesky problem or to work with that cutting edge tech that no scrum master every gave the green light?\n\nBut it does mean you can't run one small hackathon and expect five ready-to-implement features. You need enough hackathon participants over time to generate the right mix of projects.\n\nIncreasing the chances of product team pickup\n\nOf course, we still wanted good ideas to make it into the product, that's still the north start we are working towards. To improve those odds, we took several steps:\n\nWe aligned on themes and what NOT to work on. We discussed the ideal handover format for the product team, which is why we added team videos and required proper documentation. We always had someone from the product team attend hackathons on-site and ideally in preparation sessions where we set themes and topics. We presented results to the product team afterward and referred them to detailed documentation per team, topic, and idea.\n\nAnd sometimes we also had Spryker developers actually join the hackathon teams, which made this learning even more powerful (and again increase the chance of being picked up).\n\nTwo deeper benefits I didn't expect\n\nLooking back, the hackathon approach delivered two bonus benefits I hadn't fully appreciated before we started this program:\n\nFirst, it helped community members understand that ideas alone aren't enough. An in-depth request or prototype that's well thought out has a much higher chance of being seriously considered by the product team than a single-sentence suggestion. This realization changed how people approached feedback.\n\nSecond, and maybe more important, community members who actually worked on solving problems gained a much deeper understanding of why things are the way they are. Even when the hackathon didn't solve the issue, participants came away with higher appreciation for the product/tech team and how they make choices (hat tip here to Volodymyr Lunov, Denis Turkov, Helen Laktionova & Andriy Tkachenko often being the ones taking time to explain deeper product/architectural decisions and provide recommendations to the teams 🙏).\n\nNot a universal solution\n\nI want to be clear: This is specifically aimed at community managers and DevRel specialists who work with a developer community on one side and a product team on the other.\n\nIf your community isn't primarily developers, or if your product doesn't support extensibility, this exact approach won't translate. But I do think the underlying principles can:\n\n- Make community participation valuable on its own, not contingent on product team action\n- Help community members understand the complexity of implementation, creating goodwill\n- Create opportunities for community members to work alongside product team members\n- Provide clear pathways for mature ideas to reach the product team\n\nThe research backs this up\n\nRecent studies (see below for links) on open source contributions show that intrinsic motivation drives far more sustainable engagement than external rewards. When developers contribute because they're learning, building relationships, or solving problems that matter to them personally, they stick around longer and contribute more meaningfully.\n\nResearch on hackathons specifically shows they're effective at building community, generating innovation, and creating lasting value when structured properly. The key is making the event itself rewarding, not just positioning it as a gateway to getting features implemented.\n\nCommunity-driven innovation works best when it empowers local expertise and creates genuine ownership. This aligns perfectly with what we saw: when community members built something themselves, they were invested in it regardless of whether it made it into the core product.\n\nSo what's the alternative to monthly quotas?\n\nInstead of committing to \"one community idea per month,\" I'd suggest to:\n\n- Create opportunities for community members to develop their ideas into something more substantial. Whether that's through hackathons, community modules, detailed RFC processes, or something else entirely.\n- Make sure the product team is actively present in these processes. Not just observing, but participating and explaining their thinking.\n- Focus on bringing more mature ideas and proof-of-concepts to the product team rather than raw suggestions. This makes their job easier and increases the chance of implementation.\n- Work on increasing community understanding and appreciation for how product decisions get made. This might sound like lowering expectations, but I found it actually increased satisfaction because people understood the \"why\" behind decisions.\n\nOur two-part solution\n\nSo essentially, our approach worked on two fronts:\n\n1. Make it more appealing for the product team to implement things by bringing more mature ideas, POCs, and MVPs rather than raw feature requests.\n2. Increase community understanding and appreciation for unsolved or unaddressed ideas by having them work on the challenges themselves.\n\nBoth of these reduce friction and increase the actual value exchange between community and product team.\n\nWant to try this?\n\nIf you're a community manager or DevRel professional thinking about running hackathons, I've documented our entire process in a Hackathon Blueprint that covers everything from planning to execution to follow-up.\n\nIt's practical, detailed, and designed to help you avoid the mistakes we made along the way.\n\nAnd if something is missing, feel free to send in a PR 😉\n\nHow would you approach this?\n\nI'm genuinely curious how other community managers and DevRel folks handle this tension between community expectations and product roadmap reality.\n\nHave you tried fixed quotas? Do you have a different structure that works well? What challenges have you faced in making community members feel heard while also protecting your product team's ability to execute on their roadmap?\n\nFor those working with less technical communities, how do you create similar value exchanges without the ability to produce working code?\n\nWhat am I missing in this approach? I'd love to hear your experiences in the comments!\n\n---\n\nResearch links\n\n1. Motivations and Incentives of Participation in Open-Source Software (\"OSS\"): https://www.semanticscholar.org/paper/8bf33b688b2a42c28bf3c66c6e17563e6161cabb\n2. The Shifting Sands of Motivation: Revisiting What Drives Contributors in Open Source (2021): https://ieeexplore.ieee.org/document/9402044/\n3. Why We Engage in FLOSS: Answers from Core Developers (2018): https://arxiv.org/pdf/1803.05741.pdf\n4. Motivation, values, and work design as drivers of participation in the R open source project (2015): https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4672828/\n5. Motivation of Open Source Developers (2009): https://www.academia.edu/54446264/MotivationofOpenSourceDevelopers\n\nThese papers collectively highlight that intrinsic motivators (e.g. learning, altruism, fun, community sense) drive sustained and more meaningful engagement than purely extrinsic rewards."
}