A 30/60/90 Day DevRel Plan for AI and Devtool Startups

TL;DR

• Start with the day-90 outcome, then work backward.
• The first 30 days should be mostly listening, auditing, and mapping friction.
• By day 60, the team should have a clear audience, content backlog, activation path, and reporting model.
• By day 90, DevRel should ship a repeatable motion: useful content, developer feedback, and at least one measurable activation loop.

Abstract

The first quarter of DevRel should not be a scramble to look busy. It should be a deliberate ramp from understanding to useful public work.

For AI and devtool startups, the temptation is to start with events, social posts, launch content, or community channels. Those may matter later. But in the first 90 days, DevRel earns its place by clarifying the developer audience, finding friction in the journey, shipping content that helps developers act, and building a feedback loop product and engineering can use.

This post lays out a practical 30/60/90 day DevRel plan. It is written for founders, technical leaders, and first DevRel hires who need a focused operating path without turning the role into a vague mix of marketing, support, docs, community, and sales.

Table of Contents

• Problem
• Start With the Day-90 Outcome
• Days 1-30: Listen and Map
• Days 31-60: Choose the Motion
• Days 61-90: Ship the Loop
• What to Report
• Common Failure Modes
• Summary
• Next Steps

Problem

New DevRel programs often fail because the first quarter is measured by visible activity instead of useful learning.

The calendar fills quickly:

• write blog posts
• join podcasts
• attend conferences
• open a Discord
• post on social
• fix docs
• answer community questions
• build demos
• help sales
• gather product feedback

Some of that may be useful. But if the team does not know which developer audience matters, where the product journey breaks, or what success looks like, the work becomes scattered.

The first 90 days should answer four questions:

1. Who are the developers we need to serve first?
2. What are they trying to do?
3. Where does the current product or content path fail them?
4. What repeatable motion will help them succeed and help the business learn?

If the plan answers those questions, DevRel has a foundation. If it does not, the team may generate attention without building trust.

Start With the Day-90 Outcome

Work backward from a concrete day-90 outcome.

Bad day-90 goal:

Increase developer awareness.

Better day-90 goal:

Ship a repeatable activation loop for Python developers evaluating our SDK: one improved quickstart, three runnable examples, one technical explainer, weekly office hours, and reporting on docs clicks, repo clones, completed first API calls, and repeated product objections.

The better goal names:

• audience
• product surface
• content artifacts
• community or support rhythm
• behavior to measure
• feedback to collect

That is the level of clarity DevRel needs.

You can choose a different day-90 outcome:

• a developer journey audit converted into fixes
• a content system for launch and post-launch education
• a first community program with clear ownership
• a workshop or livestream series that drives activation
• a recruiting scorecard for the first DevRel hire

The key is that day 90 should not mean “we did a lot.” It should mean “we created a motion the company can keep running.”

Days 1-30: Listen and Map

The first month is for learning the shape of the work.

Listen to Internal Teams

Talk to:

• founders
• product
• engineering
• sales
• support
• solutions
• docs owners
• existing community or user-facing staff

Ask simple questions:

• Who is the product for right now?
• Which developers succeed fastest?
• Which developers churn, stall, or complain?
• What do prospects misunderstand?
• What does sales explain repeatedly?
• What does support answer repeatedly?
• What technical claims need proof?
• Which docs pages are most fragile?

Do not turn every answer into action yet. Look for repeated patterns.

Listen to Developers

Find real developer signal:

• customer calls
• support tickets
• GitHub issues
• docs feedback
• community questions
• conference notes
• sales-call objections
• onboarding recordings
• search queries

The goal is not to collect anecdotes. The goal is to see where developers lose momentum.

Look for:

• unclear positioning
• setup friction
• missing examples
• weak error messages
• pricing confusion
• security concerns
• migration risk
• model quality doubts
• integration questions

Audit the Developer Journey

Walk the path yourself:

1. Land on the homepage.
2. Find the docs.
3. Choose the right quickstart.
4. Install the package.
5. Run the first example.
6. Modify the example.
7. Hit an error.
8. Search for help.
9. Decide whether to keep going.

Write down each trust deposit and withdrawal. If you need a model for that, use the Developer Trust Ledger.

Day-30 Deliverables

By day 30, DevRel should produce:

• audience notes
• developer journey map
• top friction points
• content and docs gaps
• early metric baseline
• recommended day-90 objective

This is not a giant strategy deck. It should be short enough that product and engineering will read it.

Days 31-60: Choose the Motion

The second month is for narrowing.

DevRel cannot do everything at once. Pick the motion that best matches the business need and developer journey.

Option 1: Activation Motion

Use when developers are interested but not getting to first success.

Ship:

• improved quickstart
• runnable examples
• setup troubleshooting
• short tutorial
• office-hours path

Measure:

• docs clicks
• package installs
• repo clones
• completed first successful action
• repeated failure points

Option 2: Education Motion

Use when the category, product, or use case is not well understood.

Ship:

• technical explainer
• architecture guide
• comparison post
• demo walkthrough
• glossary or decision guide

Measure:

• qualified traffic
• docs movement
• sales-call reuse
• technical questions
• return visits

Option 3: Feedback Motion

Use when developers are using the product but product teams lack structured signal.

Ship:

• feedback taxonomy
• weekly signal report
• community triage process
• product-facing issue summaries
• developer interview rhythm

Measure:

• validated friction patterns
• product decisions influenced
• docs fixes shipped
• repeated blockers reduced

Option 4: Community Motion

Use when developers already have reason to gather.

Ship:

• clear community purpose
• moderation norms
• office-hours rhythm
• question routing
• contribution prompts

Measure:

• meaningful questions
• community-answered issues
• returning participants
• useful contributions
• qualified champions

If the audience is not clear yet, do not start with community. An empty room with a logo on it does not create a movement.

Day-60 Deliverables

By day 60, DevRel should have:

• one primary audience
• one primary motion
• content backlog
• first two shipped artifacts
• reporting plan
• product feedback path
• day-90 launch or activation target

At this point, the work should become visible.

Days 61-90: Ship the Loop

The third month is for proving the motion.

This does not mean proving full ROI. It means proving that the DevRel system can produce useful public work, attract relevant developer behavior, and return signal to the company.

Ship Public Artifacts

Depending on the motion, ship:

• tutorial
• demo app
• technical explainer
• migration guide
• comparison post
• workshop
• livestream
• office-hours recap
• community guide
• docs repair

Each artifact should have one job. Do not make every post serve awareness, education, activation, sales, and support at once.

If the artifact is content, use the standard from developer content that does not feel like marketing: show the mechanism, use specific nouns, admit constraints, and give the reader a useful next step.

Close the Feedback Loop

After shipping, capture:

• what developers did
• where they got stuck
• what they asked
• what surprised the team
• what product or docs should change

Turn that into an internal memo or issue list. DevRel should not only broadcast outward. It should improve the company’s understanding of developers.

Report the Right Signal

Use the measurement plan from How to Measure DevRel Without Vanity Metrics.

Report:

• objective
• audience
• shipped work
• developer behavior
• business or product signal
• next change

This keeps DevRel grounded in evidence instead of activity.

Day-90 Deliverables

By day 90, DevRel should deliver:

• shipped content or program artifacts
• measured developer response
• product feedback summary
• updated content backlog
• next-quarter recommendation
• clear decision on whether to scale, narrow, or change the motion

The best day-90 outcome is not a victory lap. It is a sharper operating system.

What to Report

A day-90 report can be simple:

Objective

Help target developers reach first successful use of the SDK.

Work Shipped

• quickstart rewrite
• two example apps
• troubleshooting page
• office-hours session

Developer Response

• docs traffic from target sources
• repo clones
• package installs
• completed first API calls
• office-hours questions

Product Signal

• setup failures concentrated around auth
• developers wanted a framework-specific example
• enterprise evaluators asked about data retention

Next Actions

• improve auth setup
• publish framework example
• add data-retention explainer
• test activation change next month

That is enough. The point is to make the company smarter and the next month better.

Common Failure Modes

Starting With Events

Events can work, but they are expensive ways to discover you do not know the audience.

Opening a Community Too Early

Community needs purpose, ownership, and participation. Do not start one because every devtool company seems to have one.

Publishing Content Without a Job

Every post should help the reader learn, decide, build, debug, or compare.

Reporting Only Activity

“We published four posts” is not enough. What changed?

Treating DevRel as Support Overflow

DevRel can learn from support, but it should not become an unstructured support queue.

Ignoring Engineering Trust

If engineering does not trust DevRel signal, the feedback loop breaks. Make feedback specific, reproducible, and prioritized.

Summary

A good 30/60/90 DevRel plan starts quiet and becomes useful.

The first 30 days map reality. The next 30 days choose the motion. The final 30 days ship a repeatable loop that helps developers and teaches the company.

That is the point of early DevRel: not noise, not vibes, not generic community-building. Technical momentum with evidence.

Next Steps

Write your day-90 outcome before hiring, launching a community, or committing to an event calendar.

If you want help shaping the first 90 days, talk to us. We can help audit the developer journey, define the DevRel motion, build the reporting model, or decide whether DevRel recruiting should come after the strategy is clearer.