A cross-functional approach to successful developer marketing

Katie Miller, Director of Developer Marketing at Slack, discussed how cross-functional collaboration can lead to success in developer marketing, the mistakes to avoid, and top tips for career growth with three industry experts:

Elizabeth Kinsey, Director of Community at Slack
Katy Schmidt, Product Manager at Asana
Aja Hammerly, Developer Relations Manager at Google

Check out the highlights from the discussion.👇

Developer marketing is a cross-functional endeavor

Katie

I had the good fortune to do a test run of this with Aja when we were teammates at Google, and it felt like there were so many rich lessons within that. So, if there was an opportunity to expand it across more functions and share it out more broadly, that just felt like the dream.

I'm going to do a little framing first of how I thought about this. Today's framework is going to be all about acappella. It's actually going to be all about Pitch Perfect.

If you haven't seen these movies, we have protagonists who, despite a shared goal, run into various obstacles that prevent them from understanding their audience and delivering to expectations. So, essentially they know they want to win something but they can't quite come together to do it.

And then they go through a series of challenges that result in a crisis. They get to that ‘aha’ moment. There's that crisis that forces them to work together, to communicate, to break down barriers, to find their harmony (that's the part that comes back to the acapella), and come together to successfully deliver on a common objective.

In the case of the movie, it was very much about each of them finding their sound or pitch, and how they all made mouth music together.

In this case, it's about all of us across the developer marketing journey figuring out what our role is in this journey. I’m someone who strongly believes that developer marketing isn’t a title, a ladder, or an exclusive function that sits in one department, but a cross-functional endeavor. And that's what we're going to get into today.

Different frameworks you can apply to developer marketing

Katy

When we think about frameworks (this is something I've thought about a lot in my career, both as a product manager not working on developer products, and as a product manager now working on developer products), I think about this framework of building and what your customers are trying to build.

I think a lot about companies that people think about when they think about building. A Home Depot is very much a seller of tools. They sell you tools and you come up with possibilities of what can be achieved with those tools.

IKEA is much more packaged. IKEA sells you a product. IKEA sells you something that's easy and you can put together, and there's a lot of confidence that you have what it takes to put it together. You don't need to be an expert.

I think about these things a lot when I think about developers. I think developers can fit either of these categories. And, as I think about a tool like Asana and selling Asana, we have to think about selling for people that want to be builders and want to come up with whatever their heart desires; and whatever they think is going to be a successful business that we can help them market with our platform.

And I think a lot about people who are really just looking for a solution. They want something that they can easily put together and know it's going to be successful. So when I think about selling to developers or marketing to developers, I think about both of those frameworks.

Aja

I’m Aja Hammerly, and I manage a team of developer advocates at Google. My team specifically focuses on developers, which is in the name, but we also talk to a lot of other types of technical folks.

I worked with Katie at Google, and we worked on lots and lots of events together.

My framework is a little simpler, and I use it for a lot of things. It's about cooking. I think about the fact that, if you have reasonably good ingredients and you get most of them right, you come up with something that's good enough for a Wednesday night when you're tired.

But, if you put a lot of effort in and you get the balance of acid and salt and everything exactly right, you can make something truly fantastic.

Oftentimes, you don't know, from a tasting perspective, what the difference is, other than that you really like this one and you really don't like that one.

So, when I'm collaborating with our developer marketing team, our product marketing team, our product managers, and our software engineers, I’m trying to figure out which ingredients and techniques each of us is going to bring to the table so that we can make something that’s truly fantastic and not just adequate, unless it’s one of those situations where adequate is good enough.

Quite frankly, there are days when all I want is Kraft Mac and Cheese. So, if this is a Kraft Mac and Cheese situation, let's deliver on that and save all that extra effort for those situations where we need to knock it out of the park.

Elizabeth

I've spent a lot of my career working on community, specifically both with developers and non-developer audiences, and now a mix of the two at Slack. So, I really see our work as the pollinator and the pollinated.

You need to step up and be the person that’s floating from those stationary item flowers, let's say, that need to be pollinated, and bring those ingredients that you were talking about to each one of those flowers so that they can bloom and spring again the next year.

And, sometimes, you need to be that flower. You need to be the one that people are bringing things to so that you can grow. So that's really how I approach it, especially with developers.

I’m not necessarily in my element on the technical side, so I can really help with the relationship-building and making those connections with the people that they need to be around. Oftentimes, I'm that pollinator, but when I’m out of my depth, I really need them to come and pollinate me. So that's the framework that I look at.

How to market to developers in the right way

Katie

One of the classic tropes is that developers can't be marketed to. When you hear that, how do you respond and do you believe that there's any truth to it?

Aja

Developers are marketed to because they buy stuff, and everyone's marketed to. So developers can't be marketed to? Well, people try all the time.

Developers don't want to feel like they're being marketed to because they like to believe that every decision they make is rational. And I speak primarily as a developer. I like to believe that the decisions I'm making are rational, and so much of good marketing is based on emotions, feelings, and understanding human psychology.

A lot of times, developers want to believe that stuff doesn't work on them, and it totally does. You just have to be a little more subtle.

Elizabeth

Yeah, I would definitely echo that. The subtlety is important, but also not trying to sneak things in. Be really clear and intentional. Developers just want you to tell them the facts. They’re happy if you’re clever, but they don't want you to be cute. And they like a little bit of fun, but leave aside the whimsy.

It's really just about understanding how to deliver the message in a way that makes it feel like they’re discovering something new for the first time or making that rational decision.

Katy

Yeah, I think there’s a nugget of truth to it, but it's a really broad generalization and that's what I take issue with. And I think, to the points that you both made, it’s about value and making that value incredibly clear and easy to achieve. Don't hide your value.

Cross-functional collaboration successes

Katie

One of the things that I've taken away from many parent-teacher conferences is this new way of thinking about how to encourage and grow children, which is ‘grows and glows.’ So the next two questions are going to be about our ‘grows and glows.’

First, I’d love each of you to share an example of a successful cross-functional collaboration. And then on the flip side, what were some of those beautiful ‘oops’ moments? What were some of those grow moments that we all know we’ve had but we don't necessarily feel comfortable talking about?

And yet putting them out there actually helps people learn from them and avoid that particular thing the next time they do something.

Elizabeth

The first thing that came to mind for me was some of the first collaborations I worked on with the DevRel and product teams at Slack.

The Slack community was born in the developer space. We’ve since expanded to include our admins and end users, but that’s where the core of our users are and where the developers are actually using our APIs and building on Slack, and then there are folks that are just software engineers or developers as their profession.

So, those are the folks that we need to help educate that they could be building on Slack.

When I first started at Slack, we didn't have a community, and I had no idea how I was going to go out and meet all of these people that our team knew but maybe hadn't met in person or developed relationships with. I really needed to understand their motivations for why they wanted the community at all.

We had a new framework coming out called Block Kit, which was a new way to build apps that made it very easy for people to visualize what their app would look like in Slack as the end product. It was a UI design that would output JSON.

We talked a lot with product about how to get this out into the market, and we decided to go on a series of DevRel tours. I’d never done anything like that with Slack before. I’d done it with other companies, but it was very scrappy. And so walking into a room where everything was highly produced, I thought, Yeah, you’re not a seed-stage startup, are you? You all have money.

The most important thing was that we worked hard to get the right people in the room.

I worked with our developer marketing team and the product go-to-market team on what the messaging was going to be, how we were going to bring this to life in different spaces, choosing the cities for the tours, who we were going to send out to talk about the tools and things we were building, and how to get people motivated and energized to actually use them.

So, we spent a couple of months working on the plan. We then went on the first tour in Europe and hosted a couple of different events. We had two tag teams that went to different cities. I think there were 12 cities in total.

I was able to partner with folks on the ground and use those partnerships to seed the start of our meetup community.

Meeting all the folks, showing them the tools, and helping them to trust me as someone they could come and talk to in community that could connect them with the product and DevRel at Slack was really successful. And we measured the success through the adoption of the tools that we built.

Block Kit was brand new, which was really great because we could say, “Okay, what’s the net new in the cities we’re in doing these tours, compared to the cities where we’re just doing marketing pushes? Do we see a higher uptick in adoption with Block Kit?” And we did.

The other really successful outcome was that it helped me to establish relationships with my cross-functional partners at Slack, which was crucial since I was brand new and they didn't really know me from anything. So this was a way not only to establish trust with our core audience of developers but also across the team and say, “Look, these are the things that we can accomplish if we work together.”

Katy

I'm thinking about our Asana launch last year, which was a UI component of the platform. It made this set of components available that developers could use to build apps within the Asana product.

When I first joined the company, it started as an alpha and we’d launched it with one partner developer. And I think that we didn't really know where to go from there. We had a successful initial partnership and we’d launched the product, but it still wasn’t something that developers could use very easily. It wasn’t well documented, and we didn't really know what the future of this product looked like.

Joining the company at that time, I think the challenge for me was how to take the first tendrils of success and grow that into something useful for our business and our developers.

The glow of all of this was working with Katie and marketing to set a clear destination for what we wanted to ultimately say about this product, how we thought it was going to resonate with the market, and how we were going to be able to use Asana’s existing channels to market to developers because that’s a brand new motion for this company that's very end-user, consumer-focused.

We tagged along to this larger workflows launch moment and really thought about how this type of new app development opportunity was something that would help our end users with their own workflows, and talked about it to our developer partners that way.

We then pulled in BD and thought about this framework and this way to pitch what this capability would allow in this workflows lens, and then see if that resonated with our partners.

What we ultimately got was a destination set with this workflows launch moment.

We thought about how we were going to pitch it in that way to our BD partners and then started to understand from our developers, based on their feedback in the alpha, where we thought we wanted to go for this workflows launch moment. We then tried to set a roadmap for what was going to help us launch with this workflows moment.

I think that motivation, that goal, and that alignment of having this clear destination really helped us get to a successful launch moment.

Katie

I think from the marketing end, what I found was that through the entire product development and go-to-market lifecycle, every role had a seat at the table.

I recognize that depending on the size of a company or the relationship between product and marketing, some of those things are easier or harder. But it was in core meetings, it was marketing, BD, product, eng, design, and DevRel, and everyone knew their part.

And with the marketing campaign, it wasn't just me thinking about channels. It was about saying, “What are the communities folks a part of? What's the content we want to create? Who is the subject matter expert to drive that content?”

And that was really that ‘aha’ moment for me, that this developer marketing motion isn’t me. This motion is this entire team at the table that’s building the product, thinking through the naming, validating the naming and messaging, and building all of those partner relationships.

Aja

You just hit on something that I was going to talk about, which is making sure that everyone has a seat at the table.

Some of my most recent wins have been situations where I was so in lockstep with product marketing or dev marketing or both, and/or product management.

One was a recent keynote that we put together earlier this year, where I coordinated a team of 10 developer relations engineers in various roles, building out a demo that covered seven products that we wanted to highlight.

We came up with a scenario, we did the architecture diagram, and we started coding like maniacs. And simultaneously, I was sitting in meetings for hours a day back and forth with the product team, the product marketing team, and the dev team, working on making sure that we got those words right.

I said, “You guys know the words part. You make way prettier slides than me. You know how we have to position this in the market due to all the research that you've done. Let me do the part I'm good at, which is making stories that are great for developers and making interactive demos, and you guys do the part you're good at.”

It truly wasn’t a passing the buck around, but day-to-day, over and over until 9 PM or 10 PM at night sometimes, getting everything right. Everything had feedback from both parties, and I felt really good about what we’d done in the end. I felt like we had a good developer story.

There was pushback of, “We don't think this is compelling.”

But I said, “No, we validated it.” Not with scientific research, but with anecdotal research. We thought this was a good story and it was great to feel good about that.

I always like to say that we win together. There’s no, “I did this.” We win together. We all bring different skills to the table. We all bring different talents, different communities, and different backgrounds.

And we have to bring all of those skills together because we win together. We succeed as a group, not as a DevRel team and a marketing team, and a product team.

Biggest mistakes made in developer marketing

Katie

And now it's those beautiful ‘oops’ moments. I'll actually share a quick one because I feel like I'm going to make myself vulnerable and maybe it'll be easier for the rest of us.

It was my second Google I/O. For my first one, I was on one of those famous Google 10% projects. So it was super fun because I got to write blog posts and be there in person.

My first full one where I was leading the developer marketing was in 2013. I just assumed that marketing and DevRel at that point got along well, and I thought, I'm just going to be my nice cheery self and I'm going to come up with project plans.

We were building an event app and it needed to be tested, and I didn't take the time to sit down with the developer relations program managers to really understand their role and responsibility and what was needed.

And it ended up just adding additional cycles of testing and validating across devices to make sure that the app was going to work correctly.

It was a situation where inviting the program manager, who had many years of experience, to a 5-minute coffee, probably could have broken down those silos.

So, now I always think about the fact that yes, you’ve got to get in there and get the work done, but you need to take that beat to get to know someone and say, “Tell me what you do. Tell me who you are. Tell me how you communicate.”

Am I perfect at it? Absolutely not. But going in with that mindset that we're humans first and we all bring something unique to the table has really, really helped. So that’s my beautiful ‘oops.’

Aja

Mine's an I/O story too. When I started at Google, I was a developer relations engineer and developer advocate. I was brand new, and I’d never had a role like that before. I’d been a contract dev, just building what I’d been told to build day in and day out for the three years prior.

So I thought, Cool. My job is to sell this stuff now.

I was asked, “Do you want to speak at I/O?” I didn't even know what I/O was, but it sounded fun because I love speaking. It's one of the reasons I took the job.

I got assigned to talk about a product I was working on at the time, which was around operations. It was designed for sysadmins, DevOps engineers, operations engineers, and security engineers.

I built out some cool demos and got ready to give the talk, and thought, Okay, I’ve got to encourage everyone to use this thing. My job is to encourage people to adopt. I want to build consumption and drive revenue, all the things we're supposed to care about.

I was doing a dry run and getting some approval from one of my peers who was more experienced than I was. And he said, “So what's the release stage on this?”

I said, “Oh, it's beta.”

He pointed out that I was recommending that someone use an operations product, the thing that's supposed to tell them when the website goes down and the thing that they need to rely on to make sure that everything’s okay. It had no service level agreement. We’d made no promise that it actually worked or that we’d get you your alerts within a specific amount of time because the product was still beta.

So, it was about a week and a half before I/O at that point. So I thought, How am I going to spin this?

In the end, I took the feedback approach. I said, “Hey, this is beta. This is what we think it does. Try it. Try it for something that's out of critical path. Try it for your staging environment. Try it somewhere else and let us know how it is.”

I was able to save it, but it definitely made me think for a second about how my credibility is my value to Google. It's one of my primary values as a developer advocate and the fact that I'm not going to try and sell people something that won't actually help them.

So it was definitely that moment of, from now on when I agree to give a talk on something and when I'm working on advocacy plans for a new product, I need to sit there and think, OK, does it have all of the pieces, including an SLA, that developers actually need before I agree to put my name behind those?

So it was definitely a learning moment, and not a mistake that I’ve repeated since, thankfully.

Katie

Bringing it back to that cross-functional relationship, that’s the voice that you bring, and you use good words.

But even if marketing is the one who chooses those good words, to be that voice at the table, and to say, “These words might be nice, but it's not actually telling the right story in being that vetting to make sure that messaging and positioning that we're putting out there is very straightforward and very fact-based. This is the experience you’re going to have.”

Any other ‘oops’ moments you folks want to share?

Katy

Yeah. “This is the experience you're going to have,” and being able to tell people at the forefront reminds me of our same project. This one is recent, so that's why it's top of mind.

As we were launching app components, we had seven launch partners, and those launch partners were given a deadline for when we wanted their apps submitted so that we could review them and get them launched into our new app gallery.

Of course, they all came in two days before. We knew we needed to QA them and that security wanted to have some level of review, but we didn't have clear QA guidelines. We didn't know exactly what we were going to be QAing for, security had been a little hard to track down, and we needed security to be super clear on what they wanted to test for.

It really was the gambit of issues we came across and things that we saw in the way that they’d designed in our UI that was just a bit of a weird experience. You’d click something and you’d expect something to happen and it didn’t quite work that way. But nothing was broken per se. It wasn't a QA break.

We were giving developers all this feedback and they were looking to us and asking, “What's a must-fix versus what I can fix later? Why are you telling me about this security issue that I now have to go re-architect? This is kind of a lot.”

That really felt like a miss on my part and a miss of having the forethought to help give better guidance and instruction on what we were going to be checking for, and what would get them a miss versus a go and fix this later.

It was about being able to provide that kind of feedback upfront because that back-and-forth communication just proved to be timely and isn’t a good experience for anybody.

If I look back in time, I guess it's this classic platform problem of, how much are you the gatekeeper versus how much are you just making an app available? And it's not your app, it's someone else's app.

So, we thought about that a lot. And ultimately that was a big retro item of, what could we have done better? How can we improve this next time? How can we give a preflight checklist that’ll make this easier for developers? So that was a big learning for us.

Katie

What I will say, though, being on the other side of that, is that it could have been much worse.

Thinking about the alignment of all of those motions, because we were all in lockstep, we could think about how this may affect launch and marketing strategy. What’s the contingency plan if 99 things line up and one thing goes wrong?

On one hand, it’s an important learning in terms of thinking about the resources, positioning, and relationship building that happens when a new product is launching that really is cross-functional. And yet, thinking about the fact that we were all communicating so effectively.

I love bringing it back to the analogy of food, that nice to fix versus must-fix. Does this need a little bit more salt, versus if I eat this, will it kill me?”

Elizabeth

In my previous role at a company called Branch, we worked with a lot of mobile app developers and we had a very successful community called Mobile Growth. Product managers and app developers were the primary folks that were part of that community.

We also had a product that had an SDK. There was a lot of documentation around the product that was maybe not that great. And we’d decided that instead of focusing on the thing that developers wanted us to focus on, which was improving our docs, we'd have user groups because that was clearly what they wanted.

They love the Mobile Growth meetups, which don't specifically talk about Branch, the product. They don't get into a lot of the specifics about the technicalities of the product. It's more about thought leadership and the ideas around building an app and a business.

We didn't talk to as many people as we needed to, and the team that was then working on the user groups didn't really know what they were supposed to be doing. So we had both the problems of, “We don't know who's doing what, and maybe some people are doing the same things to different results. And we’re also not doing the research with the folks that we're doing this for.”

We had our first user group meetup and it wasn’t great. We had a decent enough turnout, but we didn’t match the content to the end user who was consuming the content. So, it was a very high-level overview of our APIs and SDK instead of being something that was deeply technical, which is what they wanted.

It was more of us talking at our developers instead of talking with our developers. When we got the feedback in, it said things like, ‘This was fine, but I could’ve had pizza and beer and read your awful docs.’

It was definitely a learning moment for us, and it was early on in the company.

We realized that we needed to focus on the things that we’re good at. But when we try something new, A) it's OK if it doesn't work out, and there was a lot of pressure to make it work, and B) we need to do our diligence and actually talk with the folks that we're doing things for instead of assuming we know what they want based on some type of previous success that’s maybe not even with that specific audience.

We killed the user groups and just stuck to the mobile growth meetups, and spent a lot of time improving our docs and the search in our docs, and they were much happier with us.

How community impacts the feedback cycle

Katie

Elizabeth, with developer programs being a virtuous cycle, it's not just about driving adoption but also ingesting feedback. So what role do you see community playing as part of this?

Elizabeth

I think there are a bunch of different roles that community can play as part of this. But I'll focus on one, which is the feedback of your peers.

When you’re in a community of developers and you’re building something new, the most valuable feedback, especially as you're experimenting, comes from people that know what they're doing. They can give you feedback like, “Hey, what are you selling this for if it's in beta?” Or, “Yeah, this was a bit of a weird thing to have happened and not what I expected.”

I think that building the environment of trust that community does, allows for that feedback to be offered a little bit more freely. You can create a space where people feel comfortable sharing what they've built, even if it's still not even to the MVP stage, and getting that feedback and improving their product. It makes everyone's work better.

So, I think that that's one way that community really can impact that feedback cycle.

Katie

Awesome thank you. And a similar question for Aja. What models in advocacy have you seen work well or not well for feedback? And what role do you see marketing playing in creating programs around feedback collection?

Aja

The hardest part of the pandemic for me and the biggest lesson I’ve learned is that every time you interact with your developer community or the developer community that you want to reach, that should be a chance for feedback.

Early on in the pandemic especially, we lost a lot of those two-way feedback channels. People found other ways to make them two-way, whether we wanted that or not, and we just weren't always listening because we didn't know where those conversations were happening.

Now, every time we go to an event, every time we do an event, a webinar, a blog post, and every time we publish a video, all of those are chances to gather feedback.

It may not be product-specific feedback like, “Hey, I really need this feature.” It may be, “You look stupid and I don't believe you.” But it's still feedback. It's feedback on how we're approaching our work and it's valuable feedback.

With that framing in mind, everything that developer marketing does is a chance to gather feedback.

As a developer advocate, one of my primary jobs is channeling feedback and providing feedback to the product team, so I absolutely need to make sure that for every program and campaign that developer marketing builds, we keep in mind that every time we interact with the developer community is a chance for a two-way conversation.

And we talk about how we’re going to take that feedback, validate it, figure out if it's actually actionable and useful, and then channel it to the appropriate people, whether that's our docs team, because developers are trying to build cool stuff so docs are important, the product team for missing features, or whether that's the sales team because we get some feedback that’s actually just a lead.

It’s really changed my perspective and it's actually one of the biggest lessons I've learned during the pandemic. All of those need to be two-way conversations. There are no one-way conversations.

How to deal with misaligned goals

Katie

So, Katy, a question for you. An area of friction that I've observed, and this actually breaks the acapella paradigm a little bit, where everybody wants to be singing the same song, it's just figuring out what sound they bring.

Sometimes people want to be singing different songs, so there can actually be a misalignment of goals or motivations, whether it's perceived or actual. Have you ever had any experience with this and how did you navigate through it?

Katy

The challenge that comes to mind for me is actually very internal, and there’s been a theme in the last two companies that I've worked for, Box and now Asana, where they haven’t necessarily sold to developers.

They're products that developers play an absolutely critical role in both product-led growth and sales-led growth. But other product teams aren't necessarily thinking about developers as a primary audience or someone that they need to consider in their own product development cycle.

Almost back to Aja’s point about feedback and what we hear in the community, we really are an ear to the ground of this community that maybe doesn't get a ton of attention from other teams, yet is so critical in the ways that the business can be successful and grow and how features can get adopted.

I've viewed my role as being this facilitator of trying to help teams understand that there’s this opportunity that they have, and not come in and say, “Why aren’t you helping me with my goals of helping grow our developer community?”

It’s about helping them to understand that, “You have this opportunity for adoption. You have this other modality by which your feature can be consumed. Have you considered that?”

My engineering manager and I have a really strong relationship. She's a great counterpart and we brainstorm a lot on how we can think about these problems holistically.

So, one of the things we did is just make the data lot more evident. For example, on Asana, one of the key things people are doing is creating projects. Look how many projects are being created via the API. Did you know this? It's this whole other avenue that maybe you aren't thinking about.

Just trying to bring that awareness and attention and really empower other people to make decisions that are aligned with their goals, like meeting them where they're at as much as possible. That's how I've tried to think about that internal alignment challenge.

Top tips for career growth in developer marketing

Katie

You all bring years of very varied and rich experience, and I think everyone here is at a very different stage in growing as a developer marketer, a developer program manager, and a developer advocate. I'd love for each of you to share your top tip or word of wisdom. Something that you've done that’s sent you in the right or wrong way of growing professionally in this space.

Elizabeth

Community. It's my answer to everything when anyone asks me for a professional or growth tip that I have.

Find the community. Find the folks that are doing what you're doing or what you want to be doing. Find what you have a connection with them about and be part of it. Show up. You're only going to get what you give.

It's not enough to just join a Slack workspace or join a forum. You have to contribute. The more that you put into that community of practice or community professionals that are in this space (and there are many of those communities), the more you're going to get back from it, and the more you're going to be able to grow.

I think the majority of my career growth has happened because I’m a participant in different professional communities.

Aja

I have two tips, but I'm going to make them short.

The first tip I have for folks new to developer marketing is that developers are humans. They're people, they're squishy, they do human things. A lot of times people seem to imagine engineers as some sort of robot and they're not.

And the second one is for folks who are working with DevRel for the first time. I made this point earlier, but credibility is the currency. We have the experience and we can talk nerd to nerd. So, keep that in mind when you're working with DevRel.

When your DevRel team is saying, “Nope, not going to do that,” ask them why. Figure out if this is a credibility issue. It's a mistake that I made early on, and it's a mistake that I've seen some of my folks make.

Credibility is important. Authenticity is important. Speaking nerd to nerd is important. Make sure that you keep that in mind that that's what they're bringing to the table, and that there's going to be tension and that's by design.

Katy

OK, I have three.

The first is a lesson that I’ve learned over and over again: the answers aren’t in the building. Your team has great intuition and great talent, but if you're looking for an answer on how your product's being received or if you're looking for feedback on where to take your product next. That’s not in the building.

Ship, prototype, and get it in front of people. I think that’s something that I keep coming back to as a product manager.

The other thing that I’ll say is progress over perfection or progress over process. Whatever I can do to keep things moving is usually what I’ll do. Momentum is so key, so get things in front of people and get your team brainstorming. Just keep moving as opposed to waiting for an answer or waiting for things to be perfect.

And the last thing I'll say is that people hate reading. Everyone does, even developers. It’s often the case where something's hard to design or hard to explain, and we just want to put it in writing. And I really have to fight this tendency even for myself all the time.

For developers, documentation is a product, they're going to use it. But that doesn't mean you shouldn't design good experiences for them. That means they don't have to read so much.

Katie

Great, thank you. And my parting words of wisdom are to look for knowledge everywhere and then find the themes in your own journey.

Even if your experiences seem disconnected on the surface, if you're able to open your mind and see connections and learning moments everywhere, you'll realize that there's probably a really, really powerful story arc there.

Join our Slack channel to network with other marketers and developers, learn more about all-things developer marketing, get answers to your questions, etc.

Katie Miller

Aja Hammerly

Katy Schmidt

Elizabeth Kinsey

Developer marketing is a cross-functional endeavor

Different frameworks you can apply to developer marketing

How to market to developers in the right way

Cross-functional collaboration successes

Biggest mistakes made in developer marketing

How community impacts the feedback cycle

How to deal with misaligned goals

Top tips for career growth in developer marketing

Katie Miller

Aja Hammerly

Katy Schmidt

Elizabeth Kinsey