The Silver Bullet for 30-60-90 Day-Plans as a DevRel

One of the first tasks when starting in DevRel, if not the first, is to do a 30-60-90 day plan. During DevRel Uni, I was often asked about the silver bullet for making a 30-60-90 day plan. The truth is, there is no silver bullet. It all comes down to the organization you are joining, its specific needs, focus, and stage of development.

However, there are certain activities that you should be doing in the majority of cases. Let’s cover those here.

The First 30 Days

The first 30 days are about learning about and establishing connections with your stakeholders. Consider colleagues from different teams (e.g., product, marketing, engineering, sales), external teams integrating with your protocol, top builders within your community, etc.). The conversations you have with these groups will help you understand the product, how it sets itself apart from competitors, relevant user personas, monetization strategy, and the maturity of the community.

You can start identifying what parts need improvement as you find answers to these questions. For example, maybe you find outdated tutorials or missing information in the docs. Identify opportunities like these to add value and strengthen the community (case studies, developer guides, events, advocacy programs).

Understand the organization's strategy over the long and short term, and see how your DevRel strategy can complement and fuel larger organizational goals.

Last but not least, set up a meeting with marketing as soon as possible and learn about the tone and voice of the brand. If you work in DeFi, or another field that abides by additional regulations, ensure you know the different rules concerning communicating with the community. To your surprise, you might even discover certain limitations when using emojis on Twitter.

At this stage, you should also get your first win. You’ll find a blocker that can be solved or start a small project that you are confident with. Your first win will boost your confidence and communicate to your team that they can rely on you.

Tip: while you are performing this learning exercise, document your learning. It can be as simple as daily tweets from your personal account. This will allow you to build relationships, collect feedback, and signal your new position as an advocate for the protocol.

Days 30-60

By now, you should be familiar with the protocol you are advocating for and its stakeholders and understand how DevRel is perceived internally. Ensure everyone is aware of the value that DevRel is bringing to your organization. Educate stakeholders about the critical role that DevRel is playing in your organization.

Now is the time to perform a developer experience audit. Put yourself in the shoes of a developer looking to integrate with your product and follow their journey. Go through your documentation, guides, code samples, and case studies. Repeat the same exercise for your competitors' products and take note of anything you should replicate or are missing. Work closely with the product team and loop them in on your findings. Document your experience and share it internally and externally (on social media or by creating blog posts).

Days 60-90

It is time to ramp up communication with the community. You should know by now where your expertise and knowledge can support and complement the DevRel team best. If it’s just you, identify how you will prioritize your activities and which efforts will get you the best returns.

With this information in mind, you can start actively publishing content for your organization. Start with written content (e.g., blogs, case studies), podcasts, events (meetups, plan for any future hackathons and conferences), and your usual social media activities (technical Twitter threads, Twitter spaces with partners, etc.).

You should aim to fix the most urgent needs first. In many cases, the most critical issues are around documentation. No matter how good a product is, if it isn't supported by good documentation, it pushes away potential users. Make a plan with the engineering team to best approach documentation, and start working on it together early.

Closing Thoughts

That’s a wrap. I hope by now you have a better understanding of the 30-60-90 day plan and are in a good position to start architecting yours.

If you want to learn more about the 30-60-90 day plan and how to break into DevRel, check out DevRel University.