This particular carousel took me a bit more time than I thought it would, considering there's not much content available around the DevRel involvement in Product. Most of the articles available were around the best practices on both sides to work better together. But as a role, not a lot of people have tried to define something like this one.
After going through various of those best practices, talking to my friends involved in this role, and even reading a few job descriptions , I formulated some content for what I think DevRel Product Engineers actually do and what enables them to think about both DevRel & Product simultaneously.
DevRels are considered to focus more on the customer or the developer end of the product. Their role is largely to involve developers, make and grow the community and see if the usability and the experience are up to the mark or not. They're not directly involved in product decisions. On the product side, their job is more of conveying the feedback and let the product teams make decisions for the most part.
This is where the company needs a person who gets the DevRel as well as the Product teams. As DevRels get experienced, their grasp on the product becomes much resonant with what the community wants. This makes them the perfect choice for a person who can understand the DevRel team's point and work with the Product team to strategize the roadmap.
There are a lot of points one can make on this. Specifically, product thinking is an aspect one learns over time with the experience of being involved in its development. Be it a developer, a designer, an architect, we see product managers from every field. But, the added advantage of being a DevRel transitioning into Product is much more than that for a person from any other field.
A DevRel's whole experience shapes them into a person who understands the product and also the market for it - the ideal PM role candidate! Not just that, most of the DevRel jobs are also PM jobs themselves. Be it a Program Manager or a Community Manager; they're managing a program or a community, which in many terms is extremely similar to how a Product Manager will handle their product.
The primary job of a product manager is to understand the needs of the market and accordingly decide the best roadmap of the product and the features one needs to focus/ build upon. This is greatly achieved by their interaction with consumers and the community, though the focus is on paying consumers generally.
DevRels, on the other hand, spend a ton of time just interacting with the community. Their job is to ensure every community member is good to go with the product and their issues are being addressed properly. Through their engagements in events, hackathons, and workshops, they get high amounts of raw and unfiltered opinions of developers in the real world. This helps them detect the beliefs and opinions of the community and uncover the ideas that might not emerge in formal product team-led interviews.
DevRels are generally the first people to know if a new release or a company decision has got the right response within the community or not. Oftentimes than not, you can see a DevRel predicting the reception correctly much before the actual release. This is because their thoughts become resonant with the community. This helps the DevRel Product Engineers a lot in the general planning of the product roadmap, knowing what feature needs to be focused on and in what direction.
It's obvious that DevRels are community-focused, and their thinking reflects the thoughts of the community. As the company grows, they become the only source of on-field developer insight, which is generally missed by the Product team. Hence their involvement encourages the product direction to be a lot community-focused than it would be otherwise. Also, having insights into the product team's thinking, DevRel Product Managers will be driving the developer discovery process, which makes the product team know comments about their current thinking and the way to move from there. They also empower the product teams to speak at company-hosted meetups. Having updates about the product direction is a huge topic of interest to a community.
Documentation, online forums, community platforms, tutorials, workshops, meetups, hackathons, etc. There are a lot of things a DevRel takes into account while building the experience for every developer, be it a learner or an experienced developer.
DevRels collect a lot of data to know which specific developer they need to target and in what way their involvement will benefit the community. Similarly, product teams collect data to analyze the SDK usage, adoption of APIs and features, etc. When shared between the two teams, these sets of data can help create projects that can showcase the power of the product and add product value in the direction of what the community expects it to.
Any team depends a lot on numbers. Be it the engagement rate, usage data, crash analytics, every team has its own metrics on judging what is going well and where there's a scope of improvement. Numbers are always the key success metric for any product, project, or decision to be rated successful or otherwise.
But, generally, the numbers can vary a lot, and the real narrative behind them actually stands out to be the defining aspect of it. Having 100k followers with a 1% engagement rate and having 1000 followers with a 100% engagement rate differs extremely, though the numbers on both sides are 1000.
A product team also needs to justify their time spent with engineers, designers, and all people who directly depend on them for the direction. DevRels, being in touch with the community, generally knows the narrative well and comes very handy in these situations. Understanding the market and domain is one of the key parts of any product decision. A lot of companies have dedicated Business Analyst roles for this as well.
As mentioned, both DevRel and product teams aim to understand the developer perspective at a deep level. While the Product's perspective is more structured in user research and the dedicated product interviews, DevRel's perspective is very personal to the community. It comes from the various conversations they have within events.
The insights of both of these teams are stronger than either team alone. DevRel Product Engineers are the key in connecting both of these teams, being the source of information on either side!
Top comments (0)