Boosting developer platform adoption: 6 common mistakes to avoid

My journey to developer-focused product marketing

I’m Anil Kumar Krishnashetty, and I'm a Senior Product Marketing Manager for Developer Tools at Lokalise.

I have 13 years of experience as a developer. I started off my career as a Java developer and later transitioned into a front-end developer.

I worked for seven years on front-end development and different frameworks, and I was enjoying my work. However, I was missing the ‘why’ part of the work, and always felt that there could be a better priority from the customer's point of view.

I always felt that we could provide better value to customers, so five years ago, I transitioned into technical product management. I worked at Contentful and commercetools, where I mainly built technical products for community and developers.

The big picture was that I was really enjoying the community scene, getting feedback from developers, and collaborating with them. But again, I was missing the piece where I could influence the go-to-market decision and the business decision of a company.

Now I feel that I'm in a sweet spot in product marketing, which sits in the middle of product management, go-to-market, and sales enablement. Here, I can influence decisions and put across the marketing research point of view on the product roadmap.

At the same time, I strategize on go-to-market, what the right channel to use is, and how we can approach our go-to-market strategy for the launch. I also influence more on sales enablement, and how we can tell our story to potential prospects or customers. So, it involves storytelling and strategizing, which also relies on my experience with a developer audience.

In addition, I’ve worked on communities based in Berlin, Germany. There's a saying that if you're in Berlin, you don't go to a restaurant for dinner, you go to a meetup.

We have a meetup for literally everything; for any technology, product marketing, or product management, we’ve got a community scene for every kind of skill and knowledge you want to acquire.

That's also one thing that’s really helped me to talk to a lot of experts, network with a lot of people, and collaborate with different community leaders. And this has also helped me to combine my developer experience and community efforts in what I'm doing currently, as a developer-focused product marketer.

How Lokalise helps developers eliminate localization hassles

Lokalise is a go-to platform for software localization and end-to-end localization.

I’ll give you a simple example. Say you’ve launched a product in the US market and you’ve launched it in English. It's working well, and now you want to expand your business and enter into Europe. In Europe, you can’t just go with English because you have people who speak many different languages: German, French, Spanish, Italian, etc.

Some might say, “Okay, I’ll just use Google Translate and then launch it. What's the problem?” You need to understand that Google Translate is not accurate. You can find a lot of mistakes.

When you want to launch a product, you also want to provide a great experience for the end user and build trust. And this is where the Lokalise platform provides tools for developers, designers, and translators.

Lokalise provides a local translator, for example, from German to English. You can make corrections and changes so that you don't have typos, you’re grammatically correct, and you're using the right words for the local market.

If designers are designing with Figma, they can already design things in different languages and sync with Lokalise. And developers can take those keys as the translated content and put it into their code with GitHub. That way, they have the right languages in their software and they can release things smoothly.

Currently, people aren’t using any TMS. They’re using manual processes like Excel sheets and talking to the translators back and forth, so there are lots of errors and bugs they're going to see after the release.

By using Lokalise, they can minimize such errors.

Lokalise lets developers focus on what they're good at, not on copying and pasting from Excel to their code base. It makes their lives much easier.

So basically, it takes the hassle of translating content away from developers so that they can focus on their coding efforts and on the business logic, which are the high-priority tasks they want to work on.

Engaging developers through a value-first approach

Getting developers to adopt a platform and attract them to your developer portal can be a challenge if you don’t approach it in the right way.

Most developer companies apply traditional marketing techniques, which developers usually hate. So let’s talk about what approach works better.

As a developer, I go to Google and search for a problem I'm having first. I might go to Stack Overflow, or I might go to GitHub.

Say I get into some problem with my day-to-day tasks and I want to get things moving faster. That's where the problem statement or the struggle starts. If you can address that piece at the top of the funnel and not talk about your product first, that way, you're already providing value and building trust by not trying to sell people anything.

So, let's say I visit Lokalise as a platform. Instead of selling Lokalise as the first step, it's about solving the developer's problem.

Let's say I'm a front-end developer using React, and I face some internationalization challenge. So, I search on Google because I’d like to see a tutorial of a product in the first instance to help me understand how to internationalize my React application.

If you can build that trust, and if you can help them solve that problem, then you're going to build brand awareness. And that's one of the reasons why you see many open source tools, developed by developer-focused companies, that are helping developers solve challenges with day-to-day tasks.

And if it's really helping them, what else can we do in a better way? How can we do this for a bigger problem? So that already builds trust when you understand the problem.

Helping developers instead of selling first is the way to go, and making sure it doesn't sound like marketing. And that's why the community piece is very important.

As marketing professionals, if you don't have any experience with developer marketing, it's very important to get frequent feedback from developers. You can start by talking to your internal developers and internal engineers and building trust with them.

If you're sending an email or a blog post to a developer audience, just have a 10-minute coffee chat with your internal engineer and ask them, “What do you think about this? Do you see any red flags? Does it sound like we’re selling here?” That feedback gives you a starting point.

You can also reach out to your community or if you have dedicated customers. There are lots of ways you can get feedback. But it's important to get that feedback so that you know you're doing the right thing. And you learn a lot by talking to developers. By getting constant feedback, you’ll be able to improve and finetune your marketing approach toward your developer audience.

This is all part of the go-to-market strategy.

We also want time to value to be as short as possible. If someone is spending five seconds on your content, are they getting value out of it? This current marketing trend reflects the behavior of Gen Z; their attention span is very short.

Let's say we attracted a prospect or a visitor; how can we show them the value as quickly as possible? What does the journey look like? How is the developer journey different from the traditional journey? What’s the one place we can provide that ‘aha’ moment for them, and where we can show our value quickly?

If you're familiar with the jobs that need to be done, it's more about what problem the customer is in need of solving. And if you can show them as quickly as possible, that's where it starts in addressing the need. You also get a lot of feedback if you observe your customers and how they're using your product.

And not only that, you might think that they’re not competitors; for example, Stripe and Twilio might not be competitors of Lokalise, but they‘ve set industry standards really high on those customer experiences. Therefore, they expect your tool to be of the same standard.

For example, a customer might be thinking, I want to get the ready-made things and the SDKs, be quick to copy the code and see the changes, run it, and get the results quickly. Those are the expectations, but can we meet them?

That’s where it starts. The developer portal is one place where we can provide all of the necessary information, and where we can set ourselves apart from just trying to sell things. It's not a marketing place, it's a place to help developers.

6 mistakes to avoid when driving developer platform adoption

1. Pushing a sell before creating value

In developer marketing, it's very important that we strike a balance between creating value and capturing value.

When I say capturing value, I'm not selling immediately. But, if someone reads a technical blog post about a tutorial, I'm not trying to get them to purchase or try our tool. Instead, you can say, ‘If you liked our article, you can follow us on Twitter or LinkedIn.’ And if they subscribe, whenever you post or update an article or provide new information, they’ll get notified.

This is where capturing value is so important. They get to know you so that they don't just simply get their value. So, it's important that we balance what the right call to action is at that particular stage so that we don't immediately sell to them.

But, we also want to capture the value because, at the end of the day, you want to run the business. And I think it's very important to balance this and do it at the right time, at the right step, in the right space.

If you just look at it from a community angle, yes, you always want to help developers and provide value, but you might get questions from your stakeholders and your business like, “What’s the ROI? I'm spending money but I'm not getting any customers, so why are you spending so much time on this?”

That's why it's very important to think about it from a long-term perspective. Think about how you’re going to set this up for success, and how you're going to achieve this by providing the right value, capturing the audience, and convincing them to follow your journey so that you can provide and help those customers and developers.

2. Lack of feedback

The second mistake I've seen companies make is not getting enough feedback. They just launch a developer portal and let the customers try it out without getting enough feedback on their platform.

There are a lot of questions and issues you might get, like, “Hey, it's very hard to get developer beta testers to test our portal. We tried and nobody has time.” It's a common thing.

As I said before, you can start with your internal engineers, and this is how successful companies have done it. Take Stripe for example. For any major feature launch they do, they run an internal hackathon on that particular feature. And most of the other employees have their own private e-commerce or website where they can check the Stripe integration or a new feature and give a lot of feedback on the product.

So, before anything is released externally, Stripe already has a lot of feedback from their internal engineers.

And, of course, you can have a coffee chat and build a relationship with internal engineers. It costs nothing, Just talk to them, say hello, provide them the value, and see how they can influence the business. If you talk to them in the right way, developers will be happy to help you. That's where you can already do some user testing.

Another approach would be asking the community. You can reach out to loyal customers who always share feedback and want to talk to you. It’s definitely good to have that feedback from beta customers.

It's also about building relationships and providing them with incentives. Send them swag. You don't need to spend a lot of money; you can just send them stickers or a t-shirt as a token of appreciation, to show that you value them. And that way, you’ll have a pool of beta testers or customer advocates.

Another thing you can do is have a developer portal where people can give you feedback. For example, have a feedback bar on the menu of your website, where people can constantly send feedback in a message.

We did this at Lokalise. On the top of the menu of our website, we have a feedback form where customers can share details about what their problem is and what we can do better, and they also provide us with an email address so we can reach out to them and talk to them. And most of the time, they’re happy to collaborate with us.

You can’t build a great product in one day. It's a continuous process with the constant feedback you get and the constant improvements you do. And if you listen to the feedback and you’re able to solve the problems pointed out to you, your product always evolves.

You're not just helping them, you're helping all the new prospects and visitors who are coming to your developer portal, and they're going to get a great experience. So basically, it's about listening to them and opening up your channel to get feedback.

3. Talking without observing

Another common mistake that developer-focused product teams make is talking to developers. I say this is a bad thing because developers might not be expressing what their problems actually are.

Developers often work on tools day-to-day on IDs, their code editors. And they might use a terminal or a code editor because they want to get their jobs done quickly. So, they might be following lots of shortcuts, and they might be using some different techniques that they don’t tell you about while you’re doing user interviews.

Instead, observe them. A technique that worked really well for me was, first of all, building relationships with community members or customer advocates, and building a small application together with developers. This is the same technique used by Flutter developers at Google.

You can also ask your teammates to join as passive participants, and just observe them. Look at what they're doing and ask them to talk about what's going on in their minds.

When I was working at Contentful, we were building version four of our Forma 36 design system. Initially, we were spending a lot of time on improving the documentation. But as I started playing around and talking to developers in pair programming sessions, we started noticing that some of the developers didn't visit the documentation at all.

Instead, they were using TypeScript types, which already provided documentation on what this component was about. Because it was time-consuming for developers to switch between the documentation on the browser and ID, they wanted to move things along faster.

We hadn’t considered this at all until we did this observation, and it totally changed our perspective, because that's the developer experience we were missing, that developers hadn’t mentioned in our user interviews.

This is the advantage of pair programming. This is why I'm saying that you shouldn’t just talk to developers, you should listen and observe.

This really helped us to prioritize, and we delivered a great type system for the TypeScript of the component, and in turn, provided a great experience for those developers.

That way, you understand some of the parts you never would’ve thought about, and where developers are taking it. You also see the lifecycle, the wider code, the testing, and also see how it works in the browser.

There’s a feedback loop that goes around many times, and you get to see where the problem is and where you can optimize. And that way, you can definitely identify a lot of those mistakes.

4. Underestimating the importance of quick wins

If you have your own developer portal and you have a lot of resources like Stripe or Twilio, that's a different story. But, if you're a small company and you have limited resources, you might be using platforms like ReadMe, or other platforms to build your developer portal.

And they come with a lot of limitations in terms of having complete flexibility. Therefore, you might have to do a lot of compromising.

So, it's important to do some quick user testing and see what the quick wins are. In the case of Lokalise, we had some limitations with the ReadMe platform, where we had to provide a quick video tutorial explaining how to use it. That quickly sold us, instead of just waiting and investigating all of the different platforms.

It was about finding a quick win and validating our assumptions. Instead of blocking it and saying, “Hey, this won’t work and this won’t work,” let's uncover this with the developers and see if they're able to get their job done or not. That already gives us a lot more confidence and helps us move things along faster.

I highly encourage testing with potential customers and developers internally so that you can move faster and validate your assumptions. Just don't decide on the spot if it's going to work or not, because you have to make a lot of choices and it's a continuous process. It's not going to happen in one day. It takes time.

5. Assuming that only developers will use your portal

Another common mistake I see is that people think the portal is only for developers. It’s not, because you have tech partners, project managers, and non-technical people who also come and visit it.

So how do you make sure your platform is also welcoming and knowledgeable for a non-technical audience?

Let's say you have a developer product platform and you want to build an integration with a lot of CMS portals. How do you make sure that you're going to provide useful information for tech partners?

A tech partnership manager who’s neither technical nor a developer might not understand all the code examples. But, he has to understand on a bigger level what it’s about so that he can say to the partnership engineer, “Hey, this platform looks great. Please go and build it.”

And if you can't convince those tech partners, chances are low that there's going to be adoption from the other technical partners.

6. Not mapping developer journeys

Imagine you have developers that aren’t very experienced. They might be junior developers who also want to get started with your tool. How easy are you making it for those absolute beginners? They may not be comfortable with all the conventions you use, so how do you provide a separate journey for those beginners?

A lot of customers don't have the resource to buy developers. Developers are expensive. Instead, a project manager with limited technical knowledge might want to play around and copy and paste the code to move things forward because they don't have the resource to buy a developer. Or hiring a developer might take a couple of months and they can’t wait that long.

So, how can you make those project managers' lives easy?

That's why it's very important that when you're doing developer journey mapping, you’re identifying the experienced developers, beginner developers, non-technical, and low-code developers.

What’s the journey we can provide to them? Is that our use case for those audiences as well? Your use case might not be for low-code developers, and that's okay. But having that assessment can also give you ideas like, Hey, for these different user segments, let's also try to optimize them for these users.

That way, you can definitely provide a great experience for all the different segments and make a great developer portal.

Always prioritize developer needs

You can always look for jobs to be done from the perspective of the developer's needs. What is the need for the developer? How can we cut down all the unnecessary steps? Is there a way we can provide time to value quickly?

One example is if you're building an API, how can you make sure they can test their API as quickly as possible?

Let's say I'm a technical project manager. I'm not going to code, but I want to see what the response looks like. I don't need to take your API and test to see it. But I can already see what your 200 response looks like, and what your 404 response looks like. I can already sense that this is what it is.

Or, if I'm a developer, I want to really play around with my project. How quickly can I play? Do you have to set up everything to do it? Or do you have an SDK that I can take and get started with quickly? So looking into that, what is the need? And how quickly you can provide value to your developer?

As I said, before, continuously listen to feedback, and also build relationships with customers. Talk to customers and ask what their use cases are so you understand how to provide them the value.

Try to do a pair programming session or user testing session with the developers instead of just talking to them, and you’ll always discover new ways to improve your portal or your product.

You're going to get an enormous amount of new insights once you start observing developers during pair programming sessions.

Get our Developer Relations Playbook for expert tips and insights on developers, DevRel, developer experience, developer journey, and so much more.