Scaling Product Management at SendGrid: Building a Developer Experience TeamScott Williamson
Note: This post is the seventh in a series that covers how SendGrid has scaled product management over the years and addresses the topic of how to build out a developer experience team.
I joined SendGrid in July 2013 as the company’s first Product Management (PM) leader. At that point, the company was four years old, with 150 employees and an impressive revenue growth rate.
Installing and optimizing PM at a rapidly scaling company is hard, so I’d like to share some of our learnings and takeaways as we tackled various challenges, in hopes that it benefits the broader PM and technology community.
UX is a Thing. Why not DX?
Most everyone who works on or closely with product development knows that UX stands for user experience. Investment in UX teams and capabilities has exploded in the last handful of years–and for good reason.
And while User Experience doesn’t exclude developers, it often times is not squarely focused on improving the user experience for developers. It’s typically focused on the front end UI experience, look and feel, interaction design, etc. But if your developer customers would prefer to interact via APIs or Documentation, are you serving your developer audience as well as you could?
At SendGrid, our founders are software developers by training, so they had no issue connecting with and building a great experience for developers in the early days of the product. We also have a top notch Community Development team that flies around the world evangelizing SendGrid to the development community.
However, as we scaled up to hundreds of employees, many new PMs, designers, and engineers ended up working on the product who didn’t share that same explicit understanding of our developer customers. Slowly, but surely, the overall DX around SendGrid suffered.
Establishing a DX Team
We decided we needed a more explicit focus on the Developer Experience (DX) to make it world class. We wanted a team that would wake up every day thinking about how to improve the experience for developers that interact with SendGrid.
We formed a small team, led by a technical Product Manager, Matt Bernier, who has significant experience as a developer. We asked Matt and his team to take the lead in the three following areas that would help improve the developer experience:
• API specification and consistency – own the API specification across SendGrid and drive API experience consistency across engineering teams.
• API documentation – create simple, consistent, and beautiful API documentation that enables developers to solve problems on their own.
• Open source client libraries – create simple and robust client libraries to reduce the amount of custom code required to integrate SendGrid with the top 7 programming languages. Because the libraries are open sourced, the developer community can contribute directly.
When forming any new team, it’s important to get some early wins to build internal momentum. Here are some team wins we experienced in their first 18 months:
• Revamped our new user sign-up flow to enable developers to progress from signup to sending their first email in 3 minutes or less.
• New API documentation reduced the number of support tickets 315% in 2016–which saves tons of time for developers by enabling them to quickly answer their own questions.
• Increased the amount of email traffic flowing through our client libraries by 239% in 2016. By using our libraries as part of their integration project, developers can more quickly integrate with SendGrid.
Becoming a Top 5 API
The rallying cry for the DX team was to create an experience for developers that was so good that we would routinely be recognized as a Top 5 API. We have a ton of work left to do, but we seem to be on the right track, as evidenced by Stackshare rating SendGrid the #4 Top Utility Tool of 2016.
To all those developers who have used us over the years, thank you so much for your support. We love you!
Photo via Visual Hunt