When customers use our API they’re 2-4 times more valuable to DocuSign from a revenue perspective.
For our latest “What I’ve Learned…” interview at OpenChannel, we spoke with Marie Huwe, VP of Developer Programs and Evangelism at DocuSign, where she leads developer programs for the number one provider of eSignature and Digital Transaction Management solutions. From simple electronic signatures to complex workflows, DocuSign is the fastest, most secure way to make every approval and agreement digital. Previously, Marie spent 18+ years at Microsoft, where she was most recently General Manager for Integrated Marketing for Microsoft Business Solutions. In her time at Microsoft, Marie also led worldwide partner marketing, was general manager for developer tools marketing, and was a product manager for SQL Server and Visual C++. Marie is leading a quickly growing developer platform, and she spent some time with us to share what she’s learned along the way…
OC: Transactions that use the Docusign API grew 477% and now account more than 50% of DocuSign’s total transactions. What were some of the most important things that you did to create that growth?
Marie Huwe: The growth actually caught the Board of Directors and leadership here a little bit by surprise. For context, we have a lot of customers, approximately 300,000 companies and 200 million end users. That number of people will certainly generate transactions but it’s got nothing on the API.
A couple years ago the company started to get serious and deliberately create a developer platform and API strategy. They needed to build the entire developer program function and that’s why I joined. I was basically person number one.
The first thing we did was stop restricting who can get access to the API. Then we built the developer center and invested in building tools for developers like SDKs, How To guides and sample applications. We use Swagger to generate our SDKs and our documentation.
Then we saw the growth take off. A few years ago the API was less than 35% of overall transactions and both our growth rate and number of transaction number were much smaller than they are now. Today close to 60% of transactions are via the API, but that’s not the only number we look at when measuring the success of our developers.
OC: What are the most important numbers or metrics you look at when tracking developer success?
Marie: We do measure successful transactions from apps built on our developer platform, that is important. We also look at where our monthly recurring revenue is coming from. It varies by vertical but when customers use our API they’re 2-4 times more valuable to DocuSign from a revenue perspective. Customers using the API also have a lower churn rate, they’re definitely sticker.
Then I look at the steps a developer can take. They can setup a sandbox account, generate an API key and kick the tires. One KPI (Key Performance Indicator) that’s important is how many sandbox accounts there are. That’s somewhat of a proxy for developers and today at Docusign it’s around 50,000.
The more important question is how successful are those developers in creating their first integration with our API? I would like to do a better job of measuring is active developers. The flow I’m always looking at is:
- Who is coming in and trying the API?
- Who is being successful deploying the API?
- What are the outcomes in terms of transactions and revenue?
OC: What is the most effective tactic or strategy to increase the number of developer sandboxes?
Marie: Content in all forms is key. Developers expect your API to be well documented. From there, sample code in the languages they care about and documenting common use cases or common industries is helpful. For us, our SDKs need better documentation and we’re investing in that.
We’re also investing in discoverability. It’s interesting how easy it can be to make things difficult for developers. We’re in the process of re-architecting our Developer Center. We want to increase their success rate and hopefully their delight (that word can get overused) in using our API. Most developers care about two things. They care about successfully launching something they can be proud of, and that the end users of what they’ve built also love it. They get frustrated when:
- Your documentation stops or is incomplete
- You don’t tell them what you’re going to build or what you’re going to ship.
- You don’t build what you told them you were going to build.
Our goal is to launch the new Developer Center this winter. When a developer is logged into their sandbox, they will have a completely contextual experience. When they search, it won’t matter where the content sits or what type of content it is. It will all be returned for them to explore without any weird content silos.
OC: How do you define an “active developer”?
Marie: We look at a few things. I look at API calls and then envelopes created (an “envelope” is a container used to send documents for signature in DocuSign), and if they have used the sandbox in the last 30 days.
The DocuSign API is very much an ingredient in different types of systems and different scenarios. Once they’ve deployed an app, we call it a Deployed App Integration. We track the number of Deployed App Integrations and also how many of those remain active. The way I see it is, the Sandbox is about the people and the integration is about the ongoing success of what they built.
OC: You were hired to build the developer relations team, how have you built that team so far?
Marie: The first thing I did was hire an evangelist to build our evangelism function. The second person I hired was someone to focus on developer marketing both for the right inbound channels and also developer outreach.
I also fought to get resources for developer support. There are now three people who are part of the larger support organization that are API experts and support our developer ecosystem. They are active on Stack Overflow and help people who are working to go live with their apps. We manage our support forms through Stack Overflow and make sure all of our SDKs and are available on GitHub. We’re connected through communities that developers already care about.
I also hired someone for our content strategy. We want to create a completely self-service model and content plays a huge role in that. We automated our “Go Live Process” which wasn’t automated when I started. It’s basically doubled our throughput of apps and the deployment rate is going up every month now.
That doesn’t mean I never want a developer to call us but I want them to be able to find the content they need, try and then buy if they want. We put specific API plans in place where a developer can buy and pay by transactions.
Live events are still really important. You would think everything is online so developers will just live online. That’s not true. Developers are looking for knowledge everywhere and meet ups, events and hackathons are important.
Our most recent hire (I’m still waiting for them to start) is a role I call “developer adoption”. I want deeper analytics and insights into the lifecycle developers go through with us when trying to use our developer platform. After that I want more evangelists and want to build up the evangelism team. That’s our next thing.
OC: What mistakes do you see other platforms making?
Marie: They need to stop thinking their roadmap is top secret. If you want developers building on your developer platform and with your APIs, you need to:
- Have a roadmap.
- Practice real transparency and share the roadmap
- Create a process for listening to your community
- Take their feedback and implement it.
- Understand it’s ok when your platform roadmap changes.
- When your roadmap changes, own it and communicate that clearly to developers.
Those are pretty straightforward but many platforms fall down on a lot of them.
OC: Then how can a developer platform instill trust in their developers?
Marie: I talked about transparency and taking feedback. It’s important to recognize that when it comes to developers, the product experience and the community are connected. If you let developers try things before they’re finished and really take their feedback, you’ll end up building a much better developer platform.
OC: What developer platforms do you admire?
Marie: Everybody likes to say Twilio. I do love them but find their site has become more complicated since they went public. Stripe is really interesting. Google has always done a great job with developers and I’ve always found a lot to admire about their developer platform.
OC: DocuSign is a developer platform but also a platform developer, for example you’ve built #1 app on the Salesforce AppExchange. What unique insights come from being in both positions?
Marie: You’re right, the DocuSign app for Salesforce app, whether measured by popularity or number of downloads, has emerged as the #1 app on the AppExchange.
It helps us understand and work better with the Salesforce developer community. That is important for expanding within the Salesforce ecosystem which is a big opportunity for DocuSign.
Second, our experience building on our own API has made our own engineers more empathetic to other developers when building on the Salesforce platform. Just because you build APIs doesn’t mean you know what it’s like to consume them. Engineers sometimes think they represent the end developer and they often don’t. The person building the platform often doesn’t represent or walk in the shoes of the person who’s trying to use it all day long.
OC: What’s something you’re really good at or love to do that most people don’t know?
Marie: I was thinking about this question and thought “how am I going to answer this?”. I do write a mean haiku. Most people wouldn’t know that.
I love haiku. When I was in college, poetry was my third major. I did spend a lot of time in poetry classes and love a good haiku.
OC: Well then…
Marie, we thank you
About APIs, we shall learn
And platforms for all
Build Your Developer Platform!
Want more from platform leaders at Shopify, Intuit and Box? Check out the “What I’ve Learned…” series.