Proof of Concept
Proof of Concept订阅

You're all Developer Relations now

As software is being rebuilt, people need to know how to use it and roll it out to customers. Developer relations, or DevRel, has historically done much of this work: connecting technology companies with the developers who use their APIs, SDKs, and cloud platforms. The work often extends into partnerships, evangelism, and community. I’ll use DevRel as the broader umbrella here.

The need for this work now extends well beyond software engineers. Code is a material that more teams need to make sense of. People need enough understanding of what’s happening under the hood to explain two areas of value in the AI era: the infrastructure layer and the experience layer. What makes the technology work, and what does it help someone do?

There is also a need for this kind of guidance in every field. What does an AI-native way of working look like for a legal team? What could it help a homeowner do? Each audience has different needs, tools, and ways of working. Explaining the model is different from helping someone understand where it fits into their day. A legal team needs to know what it can trust and what still needs review. A homeowner may just want help making sense of three competing repair estimates. The technology needs someone who can translate it into a problem that feels familiar.

Storytelling is changing

Traditional marketing tactics are shifting. Paid marketing and campaigns still have a role, but they aren’t the only way people learn about a product. Even amid major technological breakthroughs, people want to hear from the humans building and using the technology.

Use the evolving product

It’s increasingly hard to talk credibly about a product you don’t use. Dogfooding is essential across departments. As AI becomes part of their work, even teams outside R&D need to understand the cost and limitations of the tools they’re adopting. People are learning to use a rapidly changing product while also explaining its value to others.

You cannot market a product well if you don’t use it yourself. What you can do with it is the proof point. Using it on a real task gives you details that won’t show up in a positioning document: the setup that took longer than expected, the output you had to correct, or the small interaction that made everything click. Those details help someone decide whether the product will work for them. They also give you something useful to bring back to the people building it.

Go direct

Communications is expanding beyond working with PR firms to include hearing directly from the people who build the product.

At Atlassian, many of our product partners use X to share their day-to-day work. What interests me about this is the shorter distance between making something and explaining it. The person who made a decision can explain the tradeoff. Someone considering the product can ask a question while the context is still fresh.

Going direct doesn’t mean everyone needs to become an influencer. A small audience of people who actually use what you’re building can be more useful than a large audience watching a launch video. You can start with a walkthrough, a decision you changed your mind about, or a problem you haven’t solved yet. Give people something specific to respond to.

Build in public

Building in public matters inside a company as much as it does outside one. As teams consider how to approach AI enablement, one of the best ways to accelerate learning is to show exactly what you did.

A short recording can make an experiment available to the team that wasn’t in the room. Include enough context for someone to try it: what you were attempting, which tools you used, and where you had to intervene. If they need you standing next to them to reproduce it, there’s still some explaining to do.

In a recent workshop I attended in Joshua Tree hosted by Ben Uyeda, he gave advice that resonated with me. When building in public, people care about the story arc and struggle, not only the start-to-finish process. In tech, there’s no shortage of people who do this well. Sarah Li at Replit is a great example of someone who shares her personal work and passion projects. She’s building her own stuff, not shilling Replit all the time. A personal project gives the technology a reason to be there. You can follow someone’s curiosity, see the choices they make, and imagine trying something of your own. That’s a more interesting invitation than another list of features.

Show, don’t tell

Companies have to practice what they preach. When everyone is making science-fiction predictions, the proof point is showing what you can actually do. Your credibility as a storyteller and builder comes from explaining the details rather than relying on broad statements.

In The art of the demo, I wrote about bringing an Origami prototype to a client pitch at Black Pixel. We had a deck, but showing the interaction running on a phone was what got the ‘whoa.’ The prototype gave everyone something concrete to react to.

I also made a distinction in that piece that still matters: strive for show and tell. A running prototype doesn’t explain itself. Set up the problem, walk through one meaningful interaction, and explain why it matters. You don’t have to narrate every button on the screen. Leave people with enough understanding to try it themselves.

Though many demos happen on social channels, those aren’t the only places to share what you’ve learned. Find the medium that’s most comfortable for you. For me, there’s nothing better than a personal website. Chi Quách uses hers to create and explore what’s possible. There is no better starting point than the personal website; get yourself the classic dot com.

Start a DevRel loop

Credibility takes time and practice. People come to DevRel from many backgrounds, so there’s no single starting point. Some were software engineers who wanted more variety. Others were marketers who became technical, or teachers who brought their experience to a new field.

1. Tinker

Start by tinkering, a lot. Working on small projects helps you get comfortable with the tools and with demonstrating what you’ve made. Pick a question you can answer by building something: can this tool help with a repetitive task, or can you make an interaction feel the way you imagined? Keep the scope small enough to finish the experiment. As I wrote in The art of prototyping, a prototype is a tool to answer a question. It doesn’t need to become a product.

2. Demo

Share a small project beyond your own team. Start with the team next to you to build confidence in your story and help others understand what you’re working on. Give them a short setup, show the thing, and let them ask questions. If possible, hand over the prototype or share a link. Watching someone use it will teach you things that explaining it to them won’t.

Once you feel comfortable, take it outside the company. A small community can be a good place to start, even a meetup of five people. I’m grateful I had the Seattle Xcoder community early in my career. It gave me a safe space among supportive people to share ideas and get constructive feedback.

3. Learn and repeat

Ask what people understood, where they got stuck, and what they’d want to try themselves. Use that feedback to improve the work and how you explain it, then share it again. Pay attention to the question you keep getting. It might point to a missing explanation, or it might reveal something confusing in the product itself. Both are worth fixing.

Close the loop with the people who helped. Show them what changed because of their feedback. Over time, those conversations give you a better understanding of the audience and give them a reason to keep contributing. You don’t need to wait for the next launch to do that.

I believe that, in the near term, everyone needs to practice some DevRel for their products and teams. As marketing becomes more forward-deployed and communication channels shift, each of us has a part to play in explaining the value of what we’re making. Congrats, you’re now DevRel.

Hyperlinks + notes

参与讨论