Signals: The Skill of Elite Developer Advocates

The best developer experiences aren't designed in a vacuum. They're shaped by hundreds of conversations with real people hitting real walls. Every friction log I run starts the same way: shut up and watch.

If you want to be a Developer Advocate/DevEx who actually moves the needle—not just one who creates pretty content—you need to develop the skill of detecting signals and eliminating friction. This skill makes you invaluable to any company that wants to grow.

What Are Signals?

Signals are behavioral indicators that tell you what developers actually experience—not what they say they experience, not what you think they experience. Signals come in many forms:

Direct signals (explicit):

A developer tells you "this is confusing". A support ticket asking something that should be in the docs. A forum comment requesting clarification. Negative feedback in a survey.

Indirect signals (implicit):

• A developer opening Google or asking AI while following your tutorial.

• A long pause before clicking on something.

• Repeated scrolling between two documentation sections.

• Drop-off at a specific onboarding step.

• Unusually long time on a page that should be quick.

Indirect signals are more valuable because they're honest. People don't always tell you what they really think, but their behavior doesn't lie.

These ones are probably the hardest to measure and keep track off, but is not impossible. There are many ways and tools to make this happen and we'll cover them here.

What Is Friction?

Friction is anything that slows down, frustrates, or stops a developer on their path to success with your product. It can be obvious:

• Incomplete or outdated documentation.

• Confusing errors with no context

• Registration process asking for too much information

• SDK that requires 15 steps for a "Hello World"

Or it can be subtle:

• Inconsistent terminology between docs and product

• Code examples that work but don't explain the "why"

• Absence of information the developer assumes should be there

Subtle friction is more dangerous because it's invisible to those who built the product. They're too close. They've seen the code a thousand times. They can no longer see what a newcomer doesn't understand.

Why This Makes You Invaluable

Here's the business reality: every friction point is a point where you potentially lose users. If 1,000 developers visit your "Getting Started" page and only 300 complete the first tutorial, you have a friction problem.

Those 700 developers who dropped off could have been customers.

A Developer Advocate who knows how to identify where friction exists and how to eliminate it is directly impacting:

• Conversion: More developers who try → more who adopt → more who pay.

• Retention: Less frustration → less churn → higher lifetime value.

• Support: Less friction → fewer tickets → lower operational cost.

• Reputation: Better experience → better reviews → more organic referrals.

When you can connect your work to these business metrics, you stop being "the person who makes blogs" and become someone who directly contributes to revenue.

The Art of Friction Logging

Friction logging is the process of walking through the developer journey as if you were a new user, documenting every moment of confusion, doubt, or frustration.

It's not simply "testing the product." It's a deliberate practice of observation and documentation.

How to run an effective friction log:

1. Forget everything you know

This is the hardest step. You have to think like someone who's never seen your product. If you've been working with it for months, consider asking someone external to do it while you observe.

2. Define the scenario

What is this developer trying to accomplish? "I want to integrate the payments API into my e-commerce app." That's the context. Everything you do should be evaluated against that goal.

3. Start from zero

Not from your Developer Hub. From Google. What would someone who doesn't know your product search for? What do they find? Is the first impression clear?

4. Document EVERYTHING

Every click, every doubt, every moment where you think "hmm." Use categories:

• Blocker: I can't continue without solving this

• High friction: I can continue but I'm frustrated

• Minor friction: Small annoyance, doesn't stop progress

• Positive: Something that worked better than expected

5. Capture the emotional context

Not just "the documentation doesn't explain X." Instead: "At this point I felt lost—I expected to find Y but only saw Z, which made me wonder if I was even in the right place."

6. Include timestamps

How long did each step take? "Time to Hello World" is a critical metric. If your competitor gets a developer to something working in 5 minutes and you take 45, you have a problem.

Where to Look for Signals

Signals are everywhere if you know where to look:

Quantitative sources (data):

Developer Hub analytics:

• Where do users drop off?

• Which pages have high bounce rates?

• What's the actual flow vs. the expected flow?

• What are they searching for internally that they can't find?

Product metrics:

• Time to first API call

• Onboarding completion rate

• Drop-off by step in the integration flow

• Most common errors in the first 7 days

Support data:

• Most frequent tickets

• Repeated questions

• Resolution time by category

Qualitative sources (human):

Community:

• Questions in Discord/Slack

• Forum posts

• Stack Overflow mentions

• GitHub Issues discussions

Direct conversations:

• Office hours

• Calls with developers

• Feedback at events

• User interviews

Observation:

• User testing sessions

• Pair programming with new users

• Hackathons (observe, don't just judge)

My Process: From Signal to Solution

After years of doing this, I've developed a process that works:

Step 1: Collect signals systematically

I don't wait for signals to come to me. I have systems:

• I review our metrics platforms where we have defined systematic KPIs/SLOs

• I review support tickets weekly looking for patterns

• I monitor the #help channel in our community daily

• I run monthly friction logs of the onboarding flow

• I run social listening on platforms like Reddit or similar

• I have regular calls with the Customer Support team

Step 2: Categorize by impact

Not all friction is equal. I categorize by:

• Volume: How many developers does it affect?

• Severity: Is it a blocker or just an annoyance?

• Position in the journey: Is it at the beginning (high conversion impact) or the end (lower impact)?

Step 3: Identify the root cause

The signal is the symptom, not the disease. If many developers ask "how do I authenticate?", the problem could be:

• The auth documentation is poorly written

• The documentation is fine but hard to find

• The auth flow is inherently confusing

• The error message when it fails isn't useful

Each root cause requires a different solution.

Step 4: Propose prioritized solutions

I present options to the team (example):

• Quick win: Update messages for clear comms.

• Medium-term: Rewrite the auth section in docs, create a visual guide.

• Long-term: Redesign the auth flow in the product

Step 5: Measure the impact

After implementing, I measure again:

• Did tickets on this topic decrease?

• Did the completion rate for that step improve?

• Did qualitative feedback change?

Without measurement, you don't know if you actually solved anything.

The Connection to Sales and Conversion

This is where many DevRels fail to connect the dots:

Friction in the developer journey directly impacts revenue.

Think about the funnel:

1,000 developers visit your landing page ↓ (20% continue) 200 developers reach signup ↓ (50% complete registration) 100 developers create an account ↓ (30% complete onboarding) 30 developers reach "Hello World" ↓ (20% continue to real usage) 6 developers become active users ↓ (30% convert to paid) 2 developers become customers

From 1,000 to 2. Every friction point along that path is an improvement opportunity.

If you improve onboarding from 30% to 50% completion, you go from 30 to 50 developers at "Hello World," which potentially doubles your final customers.

A Developer Relations/Advocate/Ex who understands this and can identify where the most expensive friction lies is a DevRel who speaks the language of business.

How to Communicate This to Stakeholders

When I present friction findings, I don't say "the documentation is confusing." I say:

"We identified that 40% of developers drop off at step 3 of onboarding. Through friction logging and support ticket analysis, we found that the error message at that step doesn't provide enough context to resolve the problem. I'm proposing three solutions with different effort levels, and I estimate that fixing this could improve completion rate by 10-15%, which would represent approximately X new active users per month."

That's different. That's strategic. That positions you as someone who understands the business.

Useful Tools and Frameworks

For analytics:

• Google Analytics / Mixpanel / Amplitude (web behavior)

• PostHog / Heap (product analytics)

• FullStory / Hotjar (session recordings, heatmaps) or my favorite Built for Dev, a tool built by the amazing Tessa Kriesel.

For feedback:

• Typeform / SurveyMonkey (surveys)

• Intercom / Zendesk (support tickets)

• Discord / Slack (community)

For documentation:

• ReadMe (it has great friction and sentiment analytics)

• Loom (recording friction logging sessions)

• Miro / FigJam (visually mapping the journey)

Key metrics to track:

• Time to Hello World

• Completion rate by onboarding step

• Ticket volume by category

• Developer experience NPS

Final Reflection

Anyone can create content. Anyone can give a talk. Anyone can answer questions in a forum.

But few can systematically spot the invisible walls that frustrate developers, diagnose root causes, propose prioritized solutions, and measure impact on metrics that actually matter.

That skill—detecting signals, eliminating friction, connecting to business impact—is what separates good DevRels from exceptional ones.

The next time a developer sighs while using your product, pay attention. There's an opportunity to create real value.

Have you implemented friction logging in your work? What signals have you discovered? Connect with me on LinkedIn or visit kevinblanco.dev to share your experience.