# Ana Hevesi knows developers
Source: https://uploop.dev/about/uploop
My career is a fifteen year obsession with technical tools and the people who love them.
![Ana's portrait]()
## Testimonials
> Ana was the first person I decided to bring in to collaborate with our lab, and **it was beyond worth it**: her work created space for us to learn about new possibilities and helped us access key insights from our audience. Ana's keen strategic thinking and incisive, empathic understanding of developer communities made her the only partner for this unique challenge. We're now equipped to create richer opportunities for our open science community to thrive while increasing our reach. If you're creating something that matters to people, you want Ana on your side.
>
> \
> **- Dr. Cat Hicks**\
> Founder, Developer Success Lab
> Ana was my team’s secret weapon at Stack Overflow. She has a unique ability to decipher social patterns in technical contexts, and used that to help us serve developers of different generations and cultures just as we were reaching massive scale. You can count on her to synthesize user needs into actionable changes for a project of any size.
>
> \
> **- Abby T. Miller**, \
> Former Director of Technology Operations, Stack Overflow
> Ana Hevesi knows developer communities at scale with a breadth and depth of understanding that only comes with building them. If you've written software over the past 15 years, you've benefited from Ana's insight, consideration and execution at a level of excellence. Ana is the lodestone for every developer community she serves.
>
> \
> **- Rob Spectre**, \
> Former VP Developer Network, Twilio
I'm Ana Hevesi.
As a kid wandering around Queens, New York, I carried a strange, obsessive conviction:
**The internet was networked human brains and the results would be either extremely cool, or extremely weird.**
Armed with this knowledge, I fell into an equally strange career: acting as ambassador between technical companies and their most impassioned customers. I made my bones at places like:
* 3D printing pioneer **Shapeways**
* **Nodejitsu**, the first Node.js hosting platform
* **Stack Overflow**, the most consequential community in developer tools history
Through it all, the same lesson kept repeating: it's possible to make people really care about your tools—and it's just as possible to demolish their passion if you don't understand their goals.
Today I work with developer tools teams who want to make their products **trusted, vital and beloved**.
After a life in New York City, I now live in the woods with my partner, my cat and far more deer than I ever expected to see out the window.
No pressure. Let's talk about what's up in your business. If I can be helpful, I'll tell you how.
# It’s better to be honest than perfect
Source: https://uploop.dev/blog/honesty-over-perfection
The best way to get it right when the stakes are high is to keep it real.
Most people don’t mind putting up with something imperfect, they just don’t want to feel misled.
In fact, imperfection can be a path to loyalty if you invite your users to join the adventure.
The visceral experience of what’s great and what’s not drives users to improve your product with you. They may take pride in knowing workarounds for things you haven’t patched yet, and satisfaction in seeing you make the fixes they requested.
This creates a relationship. As more relationships form around your adventures, the shared destiny becomes the seed of community.
Remember: your users are highly technical, and may love software as much as you do. They understand limitations, roadmaps, constraints. They’ll appreciate a front-row seat to the creation of a tool they love, and cheer you in the arena if you champion their needs in the process.
Just don’t act like you’ve already arrived when it’s obvious there’s still plenty of road ahead. Your most engaged users will feel deceived, they’ll stop trusting you.
Directness, honesty, and collaboration are underutilized in our industry. We see so much bluster and false confidence everywhere we turn. But a little humility cuts through the noise: it’s human and it’s an invitation.
Imperfection can be opportunity if your die-hards get to be part of the adventure with you. Let them in.
# Peer Learning: Your developer adoption safety net
Source: https://uploop.dev/blog/peer-learning
Docs and onboarding can't cover every edge case. They don't need to.
*Below is a text-based version of the talk I gave at [DevXConf 2022](https://youtu.be/bmsZGT151ys).*
When we write docs for developer tools, we take a snapshot of our understanding of our software, put it into the world, and hope it matches enough of our users' understanding to make them productive.
The wrinkle is that docs are a form of automation. All automation needs exception handling because it can't handle every possible circumstance.
Fortunately, you can build a social system to provide this exception handling for your project. When people help each other get better at using your tools, you've got an unbeatable stickiness factor.
You want your users to get each other back on the path to success and accomplishment. Developers look for evidence that this is happening before diving into a project. You've probably seen this yourself in your own adventures: how much do you weigh the activity of the community of users and contributors when selecting a tool or framework?
No one wants to Google a problem and find they've become the world's foremost expert on solving it.
Meanwhile, many developers love teaching their peers. It demonstrates mastery and forces clarity in the mental model for how a tool interacts with larger systems.
When we run into a problem with our code, we often debug it by searching for error content in Google. If we're lucky, we'll find activity from other developers who have hit the same issue. Public debugging processes, with support from peers, creates a paper trail for the bug in places like Stack Overflow or project-specific support forums. A good ecosystem makes it possible to assemble the puzzle pieces to solve problems and get back into action.
Community contributors appreciate larger external rewards, like speaking gigs or landing pull requests in popular projects. But initially, they're helping because it makes them better at the work and it's satisfying to alleviate shared pain.
If you're stuck in a programming problem, it's usually because you haven't met the right people yet. Technical knowledge gaps are actually network gaps.
# Peer learning levels up your developers
Every new tool has a learning curve. The longer your users are stuck, the more frustrated and discouraged they become. Stay in the red too long, they may move on and try an alternative approach that doesn't include your project.
Conversely, getting unstuck quickly restores them to the satisfaction of flow state, where they feel great because the problems they face are tractable and satisfying.
Programming can be high friction. In particular, adopting new technologies presents meaningful barriers to entry, as developers learn new APIs, design patterns and constraints. When we don't know the solution, but everyone else seems confident, it can create unpleasant feelings of self-doubt.
Interrupt this loop—with helpful humans—and you've got the basis for loyalty and passion for what you're building. It's isolation on the one hand, and relief on the other.
These constructive interactions result in real relationships. These relationships result in positive associations with your tool. My friend Dave told me the story of how an early freelance job involving microcontrollers had him stuck in the mud. He found an IRC channel, asked questions, and found an expert who promised "we will figure this out."
They went back and forth for weeks. Dave was in Brazil, his new friend was in Austria, and by the end, Dave was being tempted to consider an AV job at an Austrian opera company.
His relationship to microcontrollers was changed forever.
Your team can create these positive associations. Early career developers who receive help from staff or project leads are especially impacted. These investments show folks that they are worthy and valued. As a young bootcamp grad once told me, receiving help from a project team member "was the first time \[he] felt like part of the developer community."
# When you level up your developers, your business wins
When people feel like your tool gives them superpowers, they're going to talk about that. The best marketing campaign in the world pales in comparison to the power of word of mouth and grass roots support.
Imagine what you could accomplish if your users did things like:
* Blog about how they use your product
* Publish tutorials
* Help others navigate known issues your team hasn’t patched yet
* Start consultancies selling their expertise in your product
* Lobby their managers to let them use your product on the job
What competitive advantages would be conferred? A healthy peer learning community de-risks the decision to adopt your technology on a scale that's difficult for you to replicate with your team alone.
# You can have this!
Let's talk about what it takes.
First, understand that a healthy peer learning community requires balancing opposing needs and scarce resources.
You need to serve both askers and helpers, who have different incentives. You need strangers to show up and be constructive, in consistent ways.
You're going to be managing an economy of social capital with volunteers who don't all want the same things. Every successful technical community has invested countless hours resolving these challenges. They're hard, but solvable.
## Define your parameters
Understand the purpose of this space.
This is not a social watering hole. I know, I just mentioned the international friendship opportunities of a successful microcontroller community. I'm sure you want that too!
But there's a catch. It's too common for developer engagement teams to reach directly for friendships and good vibes without first building the foundations that make those things possible over distance: **shared accomplishment**.
Going through something hard lets you really know and trust someone. If you want meaningful relationships, set people up to win real triumphs together.
What you want to build is a place for your users to become more sophisticated technologists. You want a place where people can get answers to "how do I...?" questions.
Finally, you want a place for maintainers and your formal team to jump in when there are high leverage opportunities to create impact. You can learn a lot about how people are using your tools just by maintaining conversation with them, and these inputs can feed into more formal processes, like pitching a project evolution in your GitHub repo. This is also a venue for your team to create super-supporters. Remember: a little attention from your experts can go a long way.
## Choose your software
While it can be tempting to spin up a number of peer support channels to stir up as much engagement as possible, I recommend against that. **Don't spread your team and community too thin**, especially in your project's early days.
Think about the consequences of how your community software is designed. There's a tradeoff between the fluidity of chat, and the stability and discoverability of forums. They often work well in concert, but decide what to invest in first.
## What do people want?
Think about the broad personas your peer support community needs to serve.
**New users** will need reliable debugging help, progress toward mastery, and support in their quest to be worthy technical contributors.
**Power users** need access to maintainers, public recognition, and paths to career advancement.
**Maintainers and team members** need a successful project and sustainable use of their time. You don't want to overwhelm your crew.
## House rules and social norms
Here are some questions to help you establish guidelines for your community.
* What level of question is welcome?
* What are the responsibilities of those giving and receiving help?
* How can you turn your newbs into helpers?
* What do you consider off-topic?
* How do you reward your loyalists and create a sense of progression?
It's essential to set expectations and maintain norms, or your community may grow into something you won't want to participate in.
## Get your team in there
There's nothing like getting time with people who make your favorite tool. That's why your team is a seed crystal for values and culture, and the pilot light that ignites sustainable feedback loops. Remember: interaction with you is one of the central rewards for participation.
At the same time, your team's attention is a scarce resource. They have other responsibilities. That's why it's going to be essential to keep an eye out for interactions where your team can have the most impact as the community grows. Occasional mentorship of promising contributors, along with discussions that feed into the next iteration of your product, can be valuable investments of scarce attention.
Practically speaking, you'll need to allocate actual time in your team's schedule to make this possible.
# This is how you harness your community's network effects
Your docs and onboarding can't cover every edge case. They don't need to.
A successful peer support community starts as exception handling, and properly nurtured, grows into a powerful accelerator for everything from user research to marketing.
Be thoughtful, put in the time, and take care of your people. The rewards can define your project.
# Stop wasting time on ‘community’
Source: https://uploop.dev/blog/stop-wasting-time-on-community
It’s time we as leaders move on from 'community' and get clear about how we harness the passion and energy that exists outside our org charts.
**Mar 19, 2024**
I’ve spent more than a decade at the intersection of technologists and the companies who serve them. While technology has evolved dramatically, what we mean when we talk about “community” is no clearer today.
This is a problem.
It wastes time and resources, it depresses companies’ perceived value, and worst of all, drives up the cost of customer acquisition and retention. The dark matter that animates a product’s adoption curve remains mostly invisible.
We are leaving the best stuff on the table.
It’s time we as leaders move on from “community," getting clear about how we harness the passion and energy that exists outside our org charts, so we can drive business outcomes.
Here’s how we do it.
# The new economics of mattering to people
19 years after its founding, Reddit will IPO with 850 million monthly active users.
This is three times as many Catholic worshippers as existed in 1900, and remains competitive with modern Catholicism. Reddit’s population is 11 times the US population in 1900, and 2.5 times the American population of today.
These figures are dwarfed by Candy Crush, which boasts downloads in the billions.
In other words, today’s leaders can build followings at scales that were once the exclusive domain of religions and nations.
This is the lasting consequence of the internet, which permanently changes how we approach any business, from a local plumber to the cutting edge developer SaaS platform. The internet connects us all, allowing us to coordinate our actions based on aligned values and self-interest.
It makes unicorns *possible*.
## How to matter
The simplest way to matter to people is to *make them more successful*. Relieve their burdens, improve their skills, enhance their standing, make them less lonely. Our connected world allows us to provide all of these opportunities at scale. In success, the consequence is allegiance to our cause.
Making winners builds your community.
But this can only happen if we are deliberate and consistent in stewarding these outcomes. This requires ongoing negotiation: individuals and organizations are constantly evolving. Curiosity and humility must be operationalized to maintain a consistent view of how our work creates impact.
## Mattering is scary
The challenge of mattering to people is that our decisions have consequences. Disappointment—when needs go unmet, or expectations are betrayed—produces uncomfortable, sometimes volatile outcomes. This volatility becomes more complex with scale. Even now, after a rocky 2023, some of Reddit’s most engaged users turn away its olive branches.
I want to be honest with you about tradeoffs. We can’t make everyone happy all the time. Every leader knows this. But we can give the people to whom we matter enough of what they want enough of the time that it’s worth it to them to sustain ongoing investment.
*If we model their needs.*
# Constituencies
A constituent is someone who has expectations of you. They will make choices according to how well their needs are met. Constituents are *everywhere* in your process of creating value.
The modern business has two degrees of constituencies, but one of them is consistently left in the cold. The **conspicuous constituency** is familiar, composed of all the business stakeholders you’d expect. But we have to examine *all* the people who, in an internet age, your business can matter to: the **extended constituency**.
![A diagram of constituencies, represented as an iceberg. Visible above the waterline is the conspicuous constituency. Below and less defined is the extended constituency. Together these represent the total value and impact of a company.]()
## Conspicuous constituency
Every company has an obvious, conspicuous constituency:
People who can call executive leadership on the phone, people who are included in meetings, people everyone knows by name. These are everyone from board members, investors, tenured managers, to frontline workers. Others in this group are external to the org chart but still familiar and in-reach: parties like huge, consequential customers and partner companies.
Your conspicuous constituency has channels to lobby you about decisions in flight, visibility into your planning and assumptions, and context about the pressures that shape your business. It's easy to take their temperature, and they can provide feedback when necessary.
In today's business, it's too common that strategy and planning exclusively centers these parties. But when it comes to the total power and influence that's possible for your business and product, they are just the tip of the iceberg.
Remember: you can matter to a *lot* of people.
## Extended constituency
Here is a non-exhaustive list of those who may form your extended constituency. It’s important to understand that a single individual may be present in multiple categories, and so the results of supporting or alienating the needs of one category may leak into others.
### Frontline users
If you sell a boot that has a pebble in it, your frontline users will feel it with every step of the path. If you change the direction of their careers, they’ll never shut up about it.
They have come to rely on you for meeting their goals, and they have familiarity that only comes from ongoing, repeated exposure.
They have opinions. A common refrain from leadership: “Why are they always complaining?”
Because they *depend* on you. Because the thing they do all the time seems more tedious than it needs to be. Because there’s a particular feature or workflow that they’d use all the time, and they have no idea how to describe it in a way that will be legible to your product leadership.
Your users may buy your product directly, or they may have it bought *for them,* the decision made by someone else. Either way, these individuals will sing your praises or seethe every time you come up in conversation. In a connected world, these sentiments can replicate dramatically, especially in the case of marketplaces that include user reviews, along with industry memes that shape long-term perception.
### Forum posters
If you sell a technology product at scale, somewhere on the internet is a support community. Users show up looking for help, and with any luck they may even provide some. Represented here are power users providing help, newbies being persuaded to keep trying, and power users in waiting, learning the ropes. Posters' verdicts are durable, showing up in search engines for years.
### Community organizers
Communities around your product can gather with or without you. Message boards, Discord servers, subreddits, and other spaces will organize spontaneously through your most engaged constituents. They just really want to talk about your stuff.
In this role, they’ll set the terms of the community, the tone of conversation, and enforce limits on behavior. They will recruit themselves as your ambassadors, and their success will be a combination of your relevance and their wise stewardship.
You can’t control this energy, but you can harness it.
### Open source contributors
While all modern tech companies have some open source DNA, there are plenty out there stewarding actual open source projects. The people who file bugs, update docs, and build new features are so invested they’re using their own time and ability to contribute to your success. In exchange, they get proficiency and recognition in an ecosystem they hope will support their careers.
### Industry commentators
Experts with large followings will shape conversations in your field. They’ve built audiences through hard, consistent work, so their opinions will reverberate. Not everyone with an audience is a good-faith actor, and you can’t build your business with accolades as a goal.
Still, your standing with these individuals can influence the customers you haven’t met yet. Making your priorities and constraints visible to them can give you a fairer shake in public discussions of your work.
### Creators and influencers
If you’re lucky, some of the people your product touches will be so inspired, they’ll spend their free time trying to convince others to give you a shot. They’ll write tutorials, record videos, build example projects, and release libraries. They will identify the conceptual gaps in your onboarding, documentation and other artifacts and provide their labor free of charge to bridge those gaps.
In exchange for these investments, they hope to attract co-founders, collaborators, hiring managers, partnerships, or traffic.
### Solopreneurs
Sometimes tools or platforms enable people to become business owners in their own right. They might be a one-person consulting shop, or even an influencer experiencing outsized success. These are smaller players who have become so invested that their economic interests are bound up with yours. It’s no small thing helping feed someone’s kids.
And you never know which side project will turn into the next startup.
# Antipatterns
There are ways to squander the energy of your extended constituency.
## Coupons and t-shirt cannons
"All they gave me was socks."
I was talking to an ardent, external champion of a developer platform. He ran a consultancy in their ecosystem and touted their products constantly. So dedicated was his loyalty that his peers were starting to mock him for it, and with the episode of the socks, he was starting to wonder if they were right. He didn’t need socks. He needed the attention of an internal team, but no one asked.
It's common to jump to swag and coupons as a way of rewarding people for contributions and participation in your extended constituency. But these tokens only matter when your constituents already feel intrinsically rewarded for their work.
When that underlying allegiance isn't present, when needs are unmet, coupons and swag curdle, even becoming an insult.
## One-sided events
If you're going to spend the day talking at people, your words better be redeemable in gold. Too common is the event that centers the needs and priorities of the company hosting it, at the expense of attendee needs. Attention is precious. Earn trust and keep it by having clarity on your extended constituency's goals, priorities and challenges. Earn loyalty by learning from them directly, and presenting information you know they need.
Erode both by talking past these needs, or worse, failing to acknowledge they exist.
## Misusing attention
Relatedly, command of attention in the extended constituency is a currency. Spend it wisely, leaving people better than you found them, and you can be certain that your next call to action will produce results. Spend frivolously, demand superficial engagement—"what’s your favorite pizza topping?"—and you will quickly find your constituents have tuned you out.
## Winging it
It’s too common to treat engagement with the extended constituency as a shoot-from-the-hip afterthought. Endless time and rigor goes into roadmaps, strategy documents, fundraising decks and other planning, but little effort is made to map the extended constituency or understand its needs. This results in sloppy overtures, or worse, simply overlooking these parties altogether.
And they always, always notice.
## Isolation
Extended constituencies can provide you with market research you didn’t know you needed. Some ideas will be impractical, and need to be met with a kind but definitive “thank you for your feedback.” Sometimes, though, you’ll be handed pure gold: market segments that weren’t on your radar, or insights about customer-facing artifacts that need re-tuning. Sometimes, your team stands to gain the simple joy of seeing how much people love something they made, deepening their commitment and boosting morale.
It’s essential your conspicuous and extended constituencies actually interact from time to time.
# Leverage
## Define your extended constituency
Understand who outside your direct sphere of influence you want to serve with an external strategy. Rather than winging it, dig deep on what you hope to accomplish by developing what has been called “community.” Who are they? How will you make them more powerful and effective? What are they already accomplishing with your product, or a competitor’s?
What do you hope your outreach will accomplish *for them*? Have clear answers here and you’re already ahead of the game.
## Tell stories
Members of your extended constituency will enter rooms and conversations you’ll never know about. They’ll represent your position, your value and why people should give you a fair shake. Set them up to win.
Share stories about the work you’re doing with their benefit in mind. Explain your constraints. Be transparent about your goals, and the tradeoffs you’re managing to reach them. Not everyone will be invested in your storytelling, but those who are will carry it forward into their own communities.
## Highlight constituent success
You have to show people winning. Make it clear that what you offer makes people a more successful version of themselves. This provides concrete benefit to your specific successful constituents, who will have greater access to opportunity thanks to your attention.
It also provides social proof, encouraging more people to join the ranks of your extended constituency, in whatever roles are most compelling to them. Grow your constituency by making it a good idea to join it.
## Accomplish shared goals
Success builds social ties. People come to truly know each other, developing meaningful trust and even friendship, when they overcome challenges in pursuit of their goals. The quest is to fully engage people’s talents—whether or not they’re on your payroll—ensuring their combination of abilities produces output the world can see and which they can be proud of.
These relationships build the value of your extended constituency as a whole—it is more successful, and more likely to be successful for future challenges—which accrues to the value of your product and company.
## Let people construct their own meaning
*Elite: Dangerous* is a multiplayer interstellar dogfighting simulation. Developers provide a breadth of roles for pilots to take on: exploration, piracy, bounty hunting, trading, and more. But a group of players calling themselves the Fuel Rats created their own role: rescuing pilots whose fuel ran dry. This creates a new social scene for players who enjoy public service, while increasing the value of the game as a whole.
Constituents have their own reasons for engaging with what you’ve built. Those reasons may surprise you. Leave room for that surprise.
# What’s next
The frothy era of zero-percent interest rates is, at least for now, behind us. Across industries, this requires greater discipline and a clear thesis for ROI in all functions. The ambiguous, mushy approach to ‘community’ we’ve seen for over a decade won’t cut it. That’s okay: a better world is possible.
Without money flowing so freely, we inevitably confront the need to do more with less. The way we get more out of existing headcount and other resources is by *fruitfully, consistently* engaging our extended constituencies. They help us make better bets. They sing our praises and open more doors than we could ever manage directly.
Your extended constituency is a formidable power, but you can only harness it by being deliberate in identifying its membership, operating with clarity about how you will support their goals.
This unlocks **reciprocity** that accelerates your progress. Done right, at scale, consistently, your efforts will convert some portion of your extended constituency into zealous advocates. They'll be willing to go to the mat for your cause in their communities and discussion. This social proof changes the dynamics of selling and adoption, whether your funnel is self-serve or high-touch.
I hope this helps you add greater definition to this process.
# Career leverage in-depth
Source: https://uploop.dev/guide/career-in-depth
Here's what you get from asking about developers' career ambitions.
Go beyond the typical user interview by understanding what developers want from their careers, where they started from, and how your product maps to their ambition.
This is the first stop in your Dev Superpower Interview. Never, ever skip this.
Being a developer doesn’t just mean one thing.
Some people wrote their first shell script in their single digit years under a parent’s guidance, falling inevitably into a CS program. Others graduated from bootcamps and become full-stack devs after careers as artists. They might have “Sales” or “Product” in their title, but used your tool to hack together some little improvement to their workflow, and you can pry it from their cold, dead hands.
Or maybe you’re speaking to a current student, hoping there will be a job out there when they graduate.
Even if you think you know who you serve with your product, it pays to be curious.
The answer to this question will tell you how long they’ve been in the game, what work it took to get there, and what their current situation looks like. This is essential intelligence about how to enhance your tools and tell their story.
You’re the expert on how your product gets built and what you can do next. They’re the experts on how your product is used.
Don’t throw away leverage by assuming every user is like you.
In your Dev Superpower Interviews, this question helps you understand how the person you’re talking to thinks about software as a practice.
Our tools shape us, we shape our tools. And what’s familiar becomes intuitive.
Every developer will be looking for familiar patterns in your product, so it helps to understand those expectations more concretely.
If someone had an early mentor who helped them become proficient with Terraform, other IaC tools may be more intuitive to work with. If someone was hell-bent on making iPhone apps and cut their teeth writing Swift, your Rust library might be more accessible because type systems aren’t a new thing.
So do a bit of reverse engineering of the career path, to see if you can find out why your tool clicks. These origin stories help you understand the onramps you’ve already built, while providing inspiration for how to expand and enhance them.
In dev tools, bridging the gap between your mental model and your user’s mental model is the name of the game.
Devtools win by paying rent. So in your Dev Superpower Interviews, find out what they want from their work.
People love acquiring mastery. We crave the respect of our colleagues. We all want more say over how we spend our time.
It might seem grandiose to consider all this in light of a technical tool, but don’t sell yourself short. Advantages compound in unlikely ways.
A tool that gives devs good fake data to code against may allow a junior to maintain velocity without waiting for seniors to provide database access. An IaC framework that enforces best practices can be a teaching tool, giving a recently promoted build engineer the chance to take part in architecture discussions.
This is the first step to improved job security. Better advancement in their orgs. More influence among peers.
People might want promotions within their orgs, or they might have broader goals like becoming a keynote speaker, or even starting their own company.
If you find out what they want, you can track signs of their success, design better learning materials, and make your product a hub for helping them get there faster.
Technologies don’t exist in vacuums, they’re used in concert with other tools. So in Dev Superpower Interviews, this question is the first step to turning ecosystems into advantages.
Remember: your job is to use your product to save someone’s day when they’re against the ropes trying to ship.
It’s a lot easier to do that when you understand the tangle of adjacent vendors, projects and frameworks in their toolchain.
Understanding their stack lets you hone in on specific use cases and make informed decisions about which integrations you prioritize. It lets you invest in recipes and onboarding paths for tools that work well with yours.
You have a chance to craft developer experiences that take advantage of existing communities. You can supercharge each other’s adoption by working in a complementary fashion.
These network effects play a huge role in your adoption.
Here we are at the very end of your Dev Superpower Interview, finally asking the question you probably wanted to start with. Why?
You care about your product, but developers care about how your product makes them the hero of their story.
Your results come from their results. So we’ve reversed the focus. Start with them, then get to you.
Let’s review what you know:
* The kind of technologist you’re speaking to
* Tools and communities that shaped them
* How long they’ve been in the game
* How they want to grow.
You can’t serve everyone. You have finite time and resources.
Understanding the developer you’re talking to helps you categorize the product feedback you’re now receiving. Are they going in a direction your product can support? If you built your tool with this customer in mind and they're not into it, you need to know.
Not all user demands will take you in the right direction. But when the exact developer you’ve built your tool for loves it and wants you to build more, you know you're onto something.
# Step 3: Build developer mastery
Source: https://uploop.dev/guide/context
It's not enough to learn your product: developers must learn to succeed in the larger space your product serves.
Your product serves a larger ecosystem of people, tools and businesses.
This is why developer tools startups invest in **content marketing**: it's a way to build developer knowledge so that they can be more effective at applying what you've built.
Kathy Sierra [calls this](https://www.oreilly.com/library/view/badass-making-users/9781491919057/) "the larger context" of your product, and offers the example of cameras and photography. Mastering the menus of a digital camera doesn't create photographers. So the savvy, upstart camera vendor wants to improve how customers understand concepts like lighting and composition.
Content marketing in the abstract can be a challenge, but remember: you're also going to talk to your users and measure what they're doing in your product.
Armed with [interviews](journey) and [measurement](measurement), you'll have a much clearer picture on what kinds of learning will both support developer career journeys and help move the needle for your product.
## Planning your content
You made the startup that sells your product. You are in the 99th percentile of expertise on this stuff.
What you think is obvious, boring or basic might be transformative to the developers you're serving. Get comfortable starting from zero, get comfortable repeating yourself.
Think about what knowledge got *your* career path to the point where you could help deliver developer tools.
Next, think about the [numbers](measurement) you're trying to move in your product. Are people getting started? Are they sticking around? What could you teach to affect these numbers?
Most of all, tie this stuff back to what people want from their careers. It's not enough to document *how*, you're also going to have to document *why*: what kinds of leverage does expert use of your tools create? How will growing in this context serve their own journey?
Make more expert users. You will increase the size of your market, and thus the ranks of people who will pound the table demanding your tool.
## Learn from examples
There are loads of ways to do this, but here are a few examples to inspire you.
* Convoy gets [back to basics](https://www.getconvoy.io/what-are-webhooks) on webhooks. Anyone who reads this has a clearer picture on why they should use the product.
* Depot does [a deep dive on the history of tar files](https://depot.dev/blog/what-is-a-tar-file). Knowing the past gives readers insight on the future, plus context about the present.
* Oso provides a deep [crash course](https://www.osohq.com/academy) on authentication. Auth is a critical part of every application, and the more sophisticated you are about its larger context, the easier it is to appreciate Oso's offering.
* Mintlify offers an entire [guide to technical writing](https://mintlify.com/guides/introduction). A team will surely use their documentation product more if they're confident about technical writing overall.
**A note on hiring to solve this problem**
Learning content is a *lot* of work and if you are very early, you might want to put it off or immediately outsource it. **Don't**. It's critical for founding teams to find their voice on this stuff. A clear point of view will help you stand out in the crowd, and the more practiced you are at representing both your tools and their context, the better you'll be at hiring help to carry that burden.
***
One of the hardest things about being an expert is all the context you take for granted. We can plan a one-day intensive that includes unpacking your knowledge, creating the bones of a content strategy that moves the needle.
***
# Your reward is fandom
Source: https://uploop.dev/guide/fandom
This is a lot of work. But done right, people will fight for your product when you aren't there.
Since the dawn of the web, it has done one thing better than any medium that came before it:
**Fandom**.
The internet is for fans. People will write hundreds of thousands of words about the stuff they love. These are comments, blogs, discussion forum posts, chats.
They'll enact flamewars, they'll start beef, they'll write impassioned defenses.
This is true for books and television shows, and it's also true for developer tools.
## Users identify with their tools
When a tool changes the course of your career, you have feelings about it. You want others to know about how cool it is. You want to defend it from challengers.
When you're in love, you want the world to know.
**And tools can earn love.**
I've spent my career dealing with the consequences of this fact. I've been paid to don flamesuits, wading into nuclear conflicts whose roots were simple: someone badly depended upon a tool, and felt it was under threat.
As a field, developer tools has a terrible relationship to this fact. Tools often earn their fandoms by accident, and lose those fandoms just as accidentally.
But armed with a clear picture of the territory where developer love is earned, **you can do better**. You can actively, deliberately steward your fandom:
* Understanding how what you build creates career impact for developers
* Measuring where your product is falling short of your goals
* Teaching developers to be more formidable versions of themselves
* Facilitating peer learning, multiplying the reach of your product beyond what your team could do alone
## None of this work really ends
Like any relationship, your commitment to this work is open-ended. The road is long, and you'll have to evolve your stewardship as you grow, as your product changes, as new entrants join the market.
It can feel a little daunting.
On the other hand: isn't knowing the territory so much better than renting a T-Shirt cannon and hoping for the best?
There's no single right way to do this. What matters is being deliberate about the success you share with the developers who rely on you. Stay curious, stay engaged, and keep trying to change your space for the better.
Developers don't need perfection. They just want backup they can trust in a complex, ever-changing field.
***
I know: it's a lot to think about. If you want backup figuring out how to start or regroup, I'm here to talk about it.
***
# Introduction to the Devtools Success Guide
Source: https://uploop.dev/guide/introduction
Success in developer tools doesn't have to be mysterious.
**You deserve better** than the spaghetti-against-the-wall, stickers-and-socks, hand-waving approach to making developers engage with your product.
You deserve a clear and rigorous mission:
**Encouraging developers to learn, love and spread your tool**.
Fifteen years into my career working with makers, builders and developers of all stripes, I know what it takes to actually earn and sustain that love.
As a true believer in open source, **I'd hate the idea that you have to hire me to learn this**. The more we *all* understand these concepts, the more profitable developer tools gets to be.
So presented here is how I slice apart the work of getting people to use developer tools.
It's free.
Pay me if you want to go deeper, but if you learn *just* what's written here, you're going to spend much less time spinning your wheels.
## A candle in the dark
A consistent theme repeats itself as I work with developer tools founders: it's just hard to see the non-code problem space.
**That's how we all got lost in the glue trap of "developer relations."** Don't get me wrong: I really love a lot of folks in that role. I've been them.
But lack of definition wastes time and energy, and your team can't afford it.
So let's light up the territory. This guide can't tell you everything, but it can describe four major domains where having a clear plan and opinion will transform your future.
Developer tools have to help pay the bills. Learn what people want from their careers to increase the impact of your product.
Good vibes are not enough. You need objective measurement of your impact.
A system for answering usage questions will help you sleep better.
It's not enough to know how to use your tools. Developers need to understand the larger context of where your tools create impact.
When we say 'community' what we really want is people who will teach each other the best use of a tool. You can build that on purpose.
# Planning interviews that deliver
Source: https://uploop.dev/guide/journey
Learn about developer career journeys to ensure your product gives them the power they crave.
A successful developer tool is built on the career success of the developers who use it.
To win, you have to earn a place not just in the hearts of developers, but in their ambitions.
It sounds daunting, but remember this: most tools are awful. Yours is better. The trick is making sure that actually creates impacts for people, like job security, promotions and other career growth.
Think about it: *how many people learned React because they wanted to get a job?*
## You don't have to wing it
You can just *ask* what people want from their careers. You can ask what's getting in their way. You can ask what your tool needs to do to become part of their daily routine.
I call this the Dev Superpower Interview, and it's a way to reliably learn about career journeys. The results will inform everything from product marketing to your roadmap.
It's the best way to clear the mud off your windshield.
**A note on research**
You've been told before to talk to your users and do interviews. Too often, these interviews focus on your product first, not what your users want for themselves. Whether or not you already talk to your users, a focus on career trajectory will help you get more from your conversations.
## Preparing to interview
If possible, start with people who are either already really interested in your product, or already succeeding with it.
If you've gotten any testy emails from frustrated users, you might want to talk to them also.
Get commitments from at least six people for a 30 minute conversation. Make clear you want to understand them better, so you can make your product more likely to serve their needs.
### Asking questions
Your job is to learn from your users, but not to take marching orders. It's up to you to decide whether to double down based on what you learn, or to course-correct.
Sometimes you might do both.
1. **Tell me about your path into software**: use this to learn how this developer got where they are. You might find that your tools are particularly helpful for some origins, and less for others.
2. **Tell me about a tool that shaped you as a developer**: use this to learn about the expectations developers are bringing to your product. Developer experience is cultural, and some tools have very different cultures from others.
3. **Tell me what you want next in your career**: this can be a pivotal question, especially if you're seeking bottom-up, developer-led growth. Understanding what developers are trying to achieve, and how you can grease the skids with your product, can help you make better decisions.
4. **Tell me what tools you use alongside mine**: this knowledge is an essential detail for your roadmap, product marketing and documentation. All developer tools exist within larger ecosystems. The right integrations make you more likely to win new developers.
5. **Tell me what works great about our product, and what kind of sucks**: *now* it's time to ask about your own product. But with all the personal context filled in, any feedback you're getting here will be easier to calibrate.
By combining your insight and expertise on your problem space with a better picture of how your die-hard users are trying to grow as professionals, you can make better bets.
If you did this and only this, you're going to be in a stronger position than most.
***
You don't have to figure this out alone. Reach out for a one day, custom-tailored intensive to get clear how your users' needs turn into career outcomes.
***
# Step 2: Measure the journey
Source: https://uploop.dev/guide/measurement
You deserve a rigorous approach to success.
Vibes are not enough. Your business wins or loses on numerical facts: **are people doing the things you hope with your product**?
The sooner you and your team build a rigorous foundation for answering this question, the better you get to sleep at night.
You'd be shocked how many enormous companies substitute socks, stickers and random "community" events for actual analysis.
Defeating the dinosaurs is so straightforward, it's almost unfair.
## Analytics: just do it
Integrate a tool that provides you product analytics. I have a soft spot for [PostHog](https://posthog.com): the hedgehog is cute and the product is extremely well documented.
But gathering a pile of events and numbers is not enough.
You need to decide what numbers correspond to success. So read up on, at minimum, creating [North Star](https://posthog.com/docs/new-to-posthog/getting-hogpilled) and [Activation](https://posthog.com/docs/new-to-posthog/activation) metrics. These will let you know if you're moving in the direction you want, and if your product is becoming essential to developers.
When building a new product, you will *always* have questions about what people are doing and how much impact you are creating. Do not accept mystery. You deserve clarity, and you can get it through a rigorous approach to analytics.
## What you get for measurement
With a clear approach to measuring behavior, you can form hypotheses and test them with experiments. You can roll out new features and judge whether they're worth the trouble.
If you can't measure, you've got no choice but to throw random stuff at the wall and see what sticks. This gets costly, and runway is finite.
**A note about introducing analytics**
Analytics can feel gross if your community doesn't know they're being measured. Instead, communicate your goals clearly and proactively. You'll find most developers will understand, and perhaps not even care.
***
We can talk through what your developers are actually up to, then figure out the metrics you need to track their progress. Reach out to learn more about a one-day intensive that leaves you with a clear approach to measurement.
***
# Step 4: Peer learning
Source: https://uploop.dev/guide/peer-learning
'Community' is for teaching, learning and growth.
No matter how good your docs, content, or best-laid plans, successful tools will have both newbies and edge cases.
Docs and content are a form of automation, and all automation needs exception handling.
Two common exception cases:
* Newbies don't have enough context to use documentation confidently
* Power users have backed into an edge case you haven't yet documented
You can build ways for developers to help each other get unstuck when your docs aren't enough, and when Cursor isn't cutting it. This feeds energy back into your product's traction, instead of frittering it away when developers give up.
We also live in a reality where Stack Overflow is [in decline](https://blog.pragmaticengineer.com/are-llms-making-stackoverflow-irrelevant/). This means developer tools companies which host their own learning spaces have an edge.
## A self-organizing, distributed hive for problem solving
Positive community learning experiences become positive associations with your tool.
When it works, you'll see things like:
* First-hand accounts of how developers have implemented your product on their blog
* Tutorials made by your users
* Publicly-documented workarounds to known issues you haven't managed to patch yet
* Developers starting consultancies selling their expertise in your product
* Conspiracies to help people get jobs where using your tool is encouraged
Healthy, active community creates a flywheel, and de-risks the decision to adopt your product.
Your job, as a devtools company, is to use your product to make developers more successful in their careers. If you build a way for your users to scaffold each other's efforts, you and your users get to be part of the same upward trajectory.
## Decide what creates status in the spaces you control
The internet is vast and at the extremes of success, your community will be an archipelago of chats, forums and comment sections.
But there are places you can control, like the official Discord, Discourse or repos for your project.
Make clear, for yourself and for newcomers, what behavior creates status in these spaces. Without explicit definition and planning, status becomes an accident. High status people might become experts in your code who are also unfriendly, and this would put a ceiling on your growth.
Instead, you want status to accrue to those who are *helpful*, welcoming and generous.
You can do this through simple, low-cost rewards. Things like public recognition, more direct access to your team, and elevating the work of your most helpful contributors. You can and should give the cold shoulder to people who are capable of building cool stuff, but prevent other people from learning.
The network effects of a helpful peer learning community can change the trajectory of your business altogether. But this requires deliberate, transparent stewardship of norms and values.
Discourage the assholes, embrace the helpers. Five intermediate users who are eager to help are far more valuable than a single expert who makes people avoid your space.
**Directness works better than you think**
15 years into my internet career, one of my strongest convictions is that *people want to meet your high expectations*. If someone is behaving in ways that run counter to the healthy community you want to build, it's probably because a previous community gave them status for behaving that way. You can just tell them their behavior sucks and you want them to do better. This usually works best in private. You'd be amazed how today's troublemaker can become tomorrow's mayor.
***
A community that does what you want can be a thorny proposition. Get a one-day intensive to help you design fresh, reboot, or even remediate a peer learning strategy that's gone sideways.
***