When asked about why we do what we do, there’s always one response: we love solving problems for the industry and our clients.
Our mission is to help our clients understand what the market looks like, what developers need, what excites developers and what doesn’t and what they expect from our clients’ products and the developer programs that go along with them. So, when we are approached with a request for some custom work, we roll up our sleeves and dive deep into the data.
In this blog post, we’ll look together into such a request and:
What the client asked
How we approached it
What we offered
How the client solved the problem.
Let’s see how this client, a household name we’ll call “Client”, which is a company among the Top 5 in tech and one of the largest in the world, worked with us to improve their Developer Experience.
Knock knock – The Question
The client chose to work with us to address developer experience. They already had access to our research showing how their satisfaction level compares against their competitors, but what they wanted was to understand what drives developer satisfaction with their product and what they can do to improve it.
What was the goal/challenge you were looking to accomplish?
The product we wanted was a custom project. We’re always really interested in the health of the developer experience. And so we use the Developer Program Benchmarking report as one of the indicators of the health of the Client developer experience. Within that, we are also interested in the adoption and engagement [of our product]. But within my team, we mostly focus on satisfaction as a proxy metric for developer experience. When we decided to do this custom project last year, it really was to understand “what is moving our satisfaction up or down?” and “what are some of the levers that we can adjust in order to improve our developer experience?” Some of this data is confirming things that we already know. And some of it is providing new insights. Both of those are valuable use cases for us.
This report helped us not look at developer experience in a vacuum, but benchmark it against the industry. Client representative
Why did you choose SlashData?
Part of that is the sample size. And I think the trusted relationship we already have. Also, I think this ties back into why do we choose the Developer Programs Benchmarking report. The competitive analysis in that report is important to us. While we didn’t focus on that in the deep dive, I do think that is one of the reasons why this data is helpful so that we’re not always looking at Client experience in a vacuum, but we can actually as the report says “benchmark it against the industry experience” as well.
The answer
After we looked at what questions our client has, we took a step back and looked at the data points that could help us find the answers. There were several data points to choose from, as we survey 30,000+ developers annually on 11 areas of interest.
How did our data solve your problem/challenge overall?
The area where we found it most useful is getting that cross-section of region, experience level, and product area. So we looked at that data. The place where it becomes a little harder in our process is making those insights actionable within our company. Part of our job is to provide the data and then folks act on it themselves. I think that Client Developer Relations, as a whole, is still thinking about “how do we make this data digestible and more centralised?”. SlashData is a big data source for us. But there’s a lot of information always coming in at us, around developer experience. We’re still trying to navigate how we make that useful and easily actionable for our people. I don’t think we’re there yet. I think we’re at the point where we’re thinking “I want data to do my job better”. And then, we’re at “wow, okay, well, there’s a lot of data. What do we do now?”.
What decisions did you make using the data/research?
What we wanted to focus more on were the top three things that are important to developers this year. I don’t always have visibility into the TA level on what decisions might be made from this data. That’s also something that we want to do better. It’s also hard though because we don’t always expect that there will be a leader who’s going to take this and say “I now declare, we all must focus on this”. We are equally happy if a single engineer sees this data and then goes and makes a change in the parts that they affect. That alone makes the overall developer experience better. There’s this interesting intersection of leadership use and individual contributor use. We know that there’s value to both sides, but we don’t necessarily track what that value is.
Working together
Seamless cooperation is key to bringing in good results. That’s why we wanted to know how our client felt about working with us on this project.
What did you like about the process of working with SlashData?
I think that Slashdata is a good partner. Especially when we focus on discovery. We had a case last year when we didn’t necessarily know what we were looking for. Your response was to try out different things. Even when we asked for a random data table, you did not only deliver it, but you also provided a comprehensive analysis and different ways that we could look at the data. Last year we focused a lot on regional topics but we also broke it down by product area. And then at the end of that, we decided that we didn’t care so much about the region. What we needed to focus on more is the product area. We have that partnership where we can do some exploration, and then have things work out well. Even if they don’t work out well, we continue from there. That’s a really important part of this piece. The flexibility is really important to us, and just as much, your responsiveness.
How would you describe the service quality?
I think that’s excellent. We’re not always super buttoned up on what we want and that causes a lot more work on your end, but it’s handled well. I feel like you have helped us navigate that a lot.
What are the things you found challenging when working with SlashData?
We don’t always know what we’re looking for. We are relying on you, the data analysts’ expertise to help guide us. We need the expertise, but you don’t know the business goals. And it’s challenging to try to find that middle ground where I can articulate the business goals well enough for you to provide the expertise and help us decide on the right metrics or analysis that would prove to be useful information for those business goals.
This interview is part 2 of the “How we work with our clients” series. The product this client worked with was a custom project, along with Developer Program Benchmarking data. You can also see how Okta managed to broaden its developer network using our Developer Program Benchmarking.
Working on a new initiative or want to make sure your product will win developers’ hearts? Talk to us.