Couple of days ago, I discussed DevRel issues with a Web3 project leader who is trying to build a good developer relationship and create an excellent community culture for the product expansion, so I would like to summarize the problems and how to solve them with my previous experience in building technical communities.

This article contains 2 parts, the first is current issues which including starups team issues and developer pain points. the second is solution ideas which including the basic requirements for creating a developer community and how to actually do it in the daily work.

For the startup team in Crypto industry, how to build a strong developer community faces a lot of difficulties, especially for the crypto startups team who want to build a strong web3 application ecosystem based on their products,in this section I will present the problems faced in the process of building developer community from 2 perspectives, one is the problems faced by customers (developers), if the service we built is for developers to use, then we should know their requirements and pain poins , On the other hand, for the crypto project teams who also face some real difficulties when building the DevRel .

I have worked in a public chain development team for 2 years, and later observed many other public chain developer communities. one article is about How To Serve Web2 Developers To Join Public Chains, it show some problem about developers question .In the following list of 12 problems, the first 5 are basic problems and the last 7 are advanced problems, let me explain them one by one.

1. The development of scarce documentation, developers can not understand the specific use case of certain features

   This is the most common problem, the developer documentation is scarce, not enough detailed cases, there are errors in the manual, links can not be opened, confusing documentation logic are common problems, you often see developers compare the advantages and disadvantages of two crypto project documentation.

2. No timely response to problems found during toolkit integration

   This is also a common problem, because developers often find various adaptability and compatibility problems when using certain tool suites, so they often ask the product team through discord or forum or ticket support, but the problem they often encounter is that the response is very slow, or the problem goes unclaimed for a long time. For example, the person in charge of the development team in discord is often not online, and the reply is slow, and the support in different time zones is not friendly enough.

3. Issues in the debugging process can not be found in the developer community

   If the developer community is active and has many users, developers often encounter the same problem, at this time if someone has solved the problem, it does not need the development team to go back again,they often can not find the answer may be because of three reasons, one is a new problem, two is because other developers are not online, few developers in the community, so few people are active, three is because the problem has been a long time, but the product team or the community managers did not output the answer and the solution with some channels.

4. There is no forum for precipitating development content and product discussion

   Now, Crypto projects basically use discord to manage daily output and communication, and some links to SDK documentation in website, but the developers' questions are very diverse, and other developers will help answer them, sometimes because others have crossed to similar problems, sometimes they take the initiative to contribute their own wisdom, but discord and TG do not have content forum features, such as tips on how to use a product feature, and such issues can cause developers to discuss them over time. the forum is needed to host such valuable content. In a traditional web2 project, for example, if we have a problem with Ubuntu, you can easily find the answer in the relevant forum and see other developers discussing it.

5. Not finding other developers in the community to interact with and share certain ideas and problems

   When a developer is using a new tool or developing his own product, he will have a lot of interesting ideas, and his natural need is to find people in the community who can communicate and collide with him, e.g. everyone is using a certain wallet structure sdk, and there are a lot of interesting ideas around product design and interaction. There are many interesting ideas that can be generated around product design and interaction, so a precise and active communication community is a must.

6. No response from the development team for their improvement ideas

   Developers always expect to get a response to the problems they find in the process of using the product or the requirements they put forward and to be reflected in the next iteration, but the response from the product team may be slow for some reasons, or they may ignore it, or they cannot arrange it in time because of the roadmap.

7. Slow product updates, increasingly difficult in using features

   The speed of product updates can not keep up with the speed of demand generation, new features are not what developers need, or new features are increasingly difficult to use, but this problem is mostly found in large software tools, you can see many open source software users are becoming less and less, one reason is that the new features have lost their characteristics.

8. Developers want to submit PR to build this project with the product team, but they can not join

   For many open source projects, in the developers use the project's products, always generate some fun ideas, and want to integrate new features code into the project's github repository, but due to a variety of product policies and human reasons, resulting in these developers produce excellent code can not be integrated, This is a huge loss for the project and should be taken seriously and addressed, especially for the Crypto project.

9. Just a user, not a co-builder

   The role of user and co-builder is a differences that many product teams ignore, and when a developer uses a product, his inner expectation is to build the product together with the team, especially when the product resonates in the developer community. so when building the developer community, it can be targeted to respond to this problem, and this is a reflection of the community culture. This is the embodiment of a community culture, which can be reflected in many ways in the actual operation process.

10. Developed products are not supported and responded

    This requirement is particularly evident in the Crypto ecosystem.in the process of promoting crypto products, the current mainstream practice is to support developers to link each other and build DApp together, for example, many middleware projects and public chains are supporting developers to build their own products, and helping developers to promote, publicize, or create opportunities .

11. Unreasonable product pricing

    There are many middleware products, such as Nansen in the field of data analysis, Pocket in the field of public chains, and Web3auth in the field of Wallet, all of which are currently adopting a fee-based strategy to increase revenue.

12. Insufficient incentive for developers

    There are various incentives for developers in crypto ecology, from technical support to financial support, and a feasible incentive plan should be given according to the project's own positioning and the ability of resources that can be mobilized. For example, you can offer more discounts for good developers, or product promotion offers, etc.

1. The team lacks suitable developer support candidates

   This is a problem faced by all startup teams. Large companies can organize mature developer relationship teams to do this work, and building developer relationships is a very hard and time-consuming job, and requires the right team to support.

2. Team developers are no wareless to spend a lot of time to reach out to the community to solve the problems faced by developers

   This is a common problem, in the process of intense product development, developers have limited time, they prefer to spend their energy in product design, and can not spare time to deal with the problems raised by the community, and there is a product team will be too much trouble to deal with this matter.

3. Teams are inexperienced in building robust developer relationships

   Many teams do not know how to quantify this, building developer relationships is a very costly and time-consuming task, and it is difficult to see results in a short period of time. These metrics can be implemented on the ground. For example, how to communicate with developers in different parts of the world is a problem, because we speak different languages, for example, if you need to have a meeting with developers from different cultures, how do you prepare the event? If a developer finds a problem during integration, but the way the technical team handles it makes him unhappy, so he goes around advertising the weaknesses of the product and attacking the team's capabilities, and this person is very influential in the technical community, how fix this problem?

First of all, I would like to state that these solutions need to be designed according to the resources and product positioning of different teams. As the team expands, some specific tasks need more input and refinement, so the implementation plan should be adjusted accordingly, but the principles are universal. The following solutions are mainly designed for crypto industry startups, because of the decentralized and open nature of the crypto industry. So in building developer relationship to pay special attention to the sense of Service and Member attributes (note: not the customer who uses your product, not only a USER, more emphasis on the characteristics of the co-builder, is a Member. the Member and User is different, with the development of web3, Member culture will be increasingly stressed, so in building developer relationship, this is differ from web2's way .

1. Everyone Wants to Be Part of DAO Member

   Now the Crypto field of DAO is more and more, which also reflects the tendency of the participants, each one want to be seen as a member of the organization, not only to be Holder, User, the second is they want to be Member, and they can build this project together, contribute their ability, so if they succeed, then your success will also be closer and closer, in short, to help them, encourage them become Members within your ecology.

2. Build Content with community together

   The creation of Content consists of two parts, one is technical documentation, mostly written by the development team and active community developers, currently each project has a mature development documentation library, but this is not enough, the project need more Application story, which should find a suitable way to invite and motivate developers to write their own User stoty, to invite developers who have created extraordinary applications based on your SDK, to write their own stories and tell new developers how to use your SDK to build extraordinary Web3 products. Because for the developer needs to promote the product and attract users, if the crypto project team can make good method to levarage this appeal, it can be a win-win situation, which is the value of building an ecology, building together & winning together.

3. Build "always-on" approach - Developer communities never sleep

   For startup teams in the crypto industry, there are not enough resources to cover 7-24 needs, and it is very labor intensive to keep the team continuously responding to questions from developers all the time. However, we have ways to alleviate this problem. The first thing is to find active developers in the technical community who are distributed in different time zones, support them, train them to be the most familiar with your product, and then invite them to join your support team, which requires a lot of work before someone wants to join you in the process. Also I suggest you locate and trace developers according to time zones, for example in discord ,you can atmosphere European region, American region, Asian region, African region, etc. When you are short of staff, don't manage your developer organization according to language and culture, you should communicate in English uniformly, but you can divide the time zones. If there are active developers in each time zone asking and responding, it will reduce your workload a lot.

   Another way is build tools and platforms to support it, or you can do secondary development based on open source tools. For example, use Discord for instant question answering, and secondly, use the forum tool to sink technical Q&A content. If developers do not get a reply in Discord, they can be directed to leave a message in Forum to describe the problem, to sink technical content to facilitate developers, to discuss or find existing answers, reply question in the forum later.

4. Find The Active Member - Invite them Join you

   Find the most active people in the community, may be they like to speak, like to answer others' questions, like to suggest new products, like to talk about users' needs, like to share great code, etc. These people are gems, if you have a large number of them in your developer community, then congratulations, you will have a good link with them and many of them will become co-builders of your product. They are like gems and magic in the game, and it will be a question how to play the gems.

5. Be Where Your People Are

   If possible, try to create opportunities to communicate with developers together, Eg: Face-to-face with a lot of people or smaller, localized events party with a dozen developers or developer their The more familiar you are with them, the more you understand the Web3 APP they are creating, the more you will understand the future needs and will have an accurate judgment of the direction of the product, which is a great way to research things and try to understand and help them.

   If possible, try to create the opportunity to communicate with developers together, Eg: Face-to-face with a lot of people or smaller, localized events party with a dozen developers or developer their The more familiar you are with them, the more you understand the Web3 APP they are creating, the more you will understand the future needs and will have an accurate judgment of the direction of the product, which is a great way to research things and try to understand and help them.

6. Share the Swag - Leverage the Power of Cool Stuff

   A T-shirt with everyone's signature, a logo created by the community - a totem representing all developers' stories, a unique NFT - decided by the developer community who can have it, a special product gift pack, an opportunity to build with the team, etc. Swag is not about being valuable, but about whether the gift itself is created from everyone's wisdom and participation in the creation process. The process is important, and developers have their own unique ideas and expressions.

7. Understand and Analysis The Target Developer

   The easiest way to do this is to observe what they say in the community, their questions, answers, and use of their products, interview some developers for in-depth one-on-one sessions, or go a step further by co-developing products, such as opening up your codebase, asking them to submit PRs, or assisting them with product issues.

8. Gather Developers' Viewpoints

   Let's listen the poin from a Web2 product manager, Analyzing developers' viewpoints can reveal things you didn't know about your API. By listening and empathizing with them, you can better understand their needs and identify any missing details in your product. Conducting developer conversations can also help you create important documentation and case studies.

9. Build Loopback Structurally

   Build a bridge between developer and your team. summarise painpoint to your team member Eg:

   A: Synthesize and categorize the most important feedback

   B: Priority your list of issues

   C: Submit this list to the internal API team

10. Build a Multifaceted DevRel Team

    Building Developer Relations is not a one-man job. It's a lot of work, so if possible, build a DevRel team and divide up the work. If you don't have anyone, discuss with the developers on your team how they can contribute some of their energy and capabilities, for example, the DevRel team should select one person each day to respond to technical questions raised in the community, or invite dev partners to participate when you invite developers to online discussions.

11. Build The North-Star Target

    It is a difficult task to build and metric a good developer relationship , but it is not impossible. We can try to define a North-Star target when building DevRel and use it to guide our work. I list 5 points:

    A: How many active developers are there each month? Posting questions, answering questions, posting proposals, suggesting new ideas, etc.

    B: How many people try to help another developer each month, e.g. A answers B's question and helps B to solve a feature usage.

    C: How many developers are building Web3 products based on your project each month?

    D: How many developers are collaborating each month?

    E: How is the quality and efficiency of problem solving each month?

12. Design Your Developer relationship tool

    When building DevRel, there are always new requirements that need to be combined with the current reality to develop new tools and support the work, such as building efficient issue tracking and support tools.

13. Measure Success/Review

    As explained in point 11 above, metric and measure what success is, review the current data and find ways to improve it.

14. Tools: Medium/Discord/Discourse/Eventbrite /Jira/ meetup/ Google doc/zoom/Youtube and so on

    Developer relationships focus on services, not operations, so the tools used need to be simple and practical. For startup teams, these tools are sufficient, and as business increases, some tools need to be developed by teams, such as efficient work order support and analytics systems.