Dave De La Pena Attributes Signable’s API Success to its White Glove Approach to Developers

Dave De La Pena, Tom Dickinson, SignableDave De La Pena, Tom Dickinson, Signable

In today’s business climate, where everything from pandemics to competitors can influence shifting market conditions, companies across all industries are facing an increasing demand for better connected experiences.  Connected experiences are seamless experiences (eg: mobile or web apps for customers or employees) that are composed from the Integration of two or more systems, but that ultimately hide that underlying complexity (appearing as though the entire experience is delivered from a single back end). As the demand for these types of experiences steadily increases, so too does the intolerance for extended project delivery times. The competition doesn’t wait for slow-pokes to catch-up. It is imperative for organizations to execute with greater agility and innovation and to be able to do so at scale. APIs are key enablers for companies looking to meet these challenges. But before an organization can reap the benefits of APIs, it must set up an API strategy.

Developing an API strategy can be broken down into four stages: establishing your business strategy, aligning your organization and culture to the idea of a composable enterprise (where experiences are derived from a combination of digital business competencies), installing the technology needed to support the strategy and engaging with your ecosystem of developers, business partners, and other constituencies. This series of articles examines the fourth stage.

All successful API providers make it a priority to actively engage with their developer communities. Doing so helps build vibrant ecosystems of developers and partners who, in turn, can extend the reach and success of those API strategies. ProgrammableWeb has spoken to a number of providers about their best practices for engaging with developers. This article will focus on Signable, an electronic signature provider. We spoke with Signable’s content executive Sophie Torry-Cook, lead developer Tom Dickinson, and head of product Dave De La Pena.

At Signable’s scale, the company has the ability to engage with developers and potential customers on a personal level. According to Torry-Cook, “people really respect that and I think they like our more friendly and human approach. I think that's why people choose us over some of the big dogs out there.” As the Customer Success (CS) team sources potential clients, it promotes the API to those who are in a situation where it makes sense. Dickinson explained how the CS team works closely with customers and that allows for a feedback loop where many feature requests for both the product and the API can be passed along to the product team. 

In addition to promoting the API, the CS team also helps developers initially engage with it. The team, backed by strong technical people, walks customers through the onboarding process and addresses any support issues that arise.

The Signable team feels strongly about this approach and believes that much of their success and engagement starts with their customer success team. They are aware of the need to scale beyond the CS team though and Torry-Cook explained that 2021 will be spent “putting a lot more effort into promoting our API to people that may not have heard about it yet.” She also pointed to the developer site that contains “all of the Documentation, all of the help articles, everything that developers would need to implement the API.” 

To find out more about how Signable approaches developer engagement, read the transcript of the interview below.This interview has been edited for clarity and length.

ProgrammableWeb: Hi this is Wendell Santos, editor of ProgrammableWeb and today I’m joined by Sophie Torry-Cook, Tom Dickinson, and Dave De La Pena of Signable which is an e-signature company. First of all, I really appreciate the three of you taking a few minutes to chat. When I was chatting with Sophie by email one of the things I found interesting was that you do a lot of work with partners more so than running a public API program. I’ll be interested to hear how your strategy accounts for that. But first could you each give a brief background of yourselves for our readers?

Sophie Torry-Cook: I'm Sophie and I'm in the marketing team. I handle our content and our PR. I also do a lot of the marketing around the API and am happy to tell you about how we do that. I think when you mention the thing about partners, it’s important to note that we do have two sides of it. So obviously we have a lot of partners using the API, but we also have customers themselves using it as well. So they don't have to be partners. It's not an exclusive thing, but I'll let the guys explain that a bit more because they know more about it. 

Tom Dickinson: I'll go next. I'm Tom, I'm the lead developer at Signable. I've been the lead now for a year, but I've been at the company for two years. That means I am involved in a lot of the decisions around the technical direction of the product and generally managing the team of developers that we've got there. 

Dave De La Pena: Hi, I'm Dave, I'm head of product so heading up the operations and team so there's UX, the QA, and data and I've been around for a year and a half now, I think. 

PW: Great and can one of you give our readers a little bit of background on Signable and what the company does?

Dickinson: So in short, we're an e-signature company, but we have a focus on humanity, on really connecting with our customers and hopefully providing a superior product. It was started many years ago now by our CEO, Olly Culverhouse. He started off with a web design agency. It was running out of the university, I believe. And he had frustrations when he was sending out his contracts and the product actually started as a side project to help him streamline his process.

I think a number of his clients showed interest in this thing he was using to send out his contracts and he realized that maybe there's some legs to this. So he built up a customer-friendly version of it with a billing model, and fast forward to today, yeah, that's how it all started.

I guess our main focus now though is building on those original services, and our focus in the product team over the next year or so is going to be pushing forward with a new infrastructure that's going to be more scalable, more modern, and more UX-focused. And also provide the API, the Webhooks, and the other services that the developers on our Platform make use of. 

Torry-Cook: I think you pretty much nailed it there, Tom. I think customers do opt for us because we put a lot of effort into our customer service and support. So I think people really respect that and I think they like our more friendly and human approach. I think that's why people choose us over some of the big dogs out there.

PW: You mentioned a couple of things that I would like to touch on. First of all, one of your goals is to focus on the product, really give developers the things that they've been asking for. So I want to know A) your strategy for engaging with those developers and B) finding out what it is that they really want in your product and setting up that feedback loop.

De La Pena: Sure. I was chatting to Tom earlier about this actually, and I think what's interesting is the history of the product and how Olly is a developer. So he has a lot of understanding of the wants and needs of other developers, and the API grew organically out of the product he first created.

Actually him chatting and having that domain knowledge and empathy with other developers, that really helped him understand and communicate with the developers that are consuming the API. He would really listen to their requests and respond to that, and the company grew organically in that way. We want to continue that empathetic communication with the developers. It's really important that we understand the users.

Dickinson: Just to build on what Dave is saying, I think one of the things that our customers are really positive about is the connection they get with the company. Our customer success team is very happy to field calls from customers to help them out with their API needs and development needs.

Through that communication we get a lot of feature requests as well and that close feedback loop that we get with our customers has driven a lot of the features that we have, and has made the product what it is now. We recognize we have developers who operate on all different kinds of scales so we have a billing model that reflects that.

You can start up on a pay as you go plan where you just pay individually for each envelope you send out, or you can sign up on a corporate plan and you pay wholesale for the amount of envelopes used. We also have the partners program, which I think is a really interesting part of our strategy. So if you are a company that rather than using the Signable app directly, prefers to integrate with it and use our API to write your own app, that your customers will then go on and use, we provide a completely different plan for these users with reduced rates and such.

One of the big things also that we're looking at in the coming year is a dashboard for those kinds of users. So they'll be able to break down their API usage based on their users. But I think the key thing here is that, depending on your need, you get a different flow through the product. So if you just want to write a script, you can sign up and use an API Key. Whereas if you want to build a whole app, then you can sign up as a partner and make use of reduced rates and things like that as a result. 

PW: It sounds like you have different buckets of developers within your ecosystem. What are some of the best ways that you have found for actually connecting with them? Because one thing I'm hearing a lot from you guys are words like humanity, empathy for the customer, that there's a real connection between the company and your ecosystem.

How do you guys foster that connection? How is it that either you're reaching out to developers or you're giving them road signs, be it through the product or through the website, however it is, to have them come to you? How are you setting up that engagement so that you guys can Feed that connection?

Torry-Cook: I can say something because we have a little bit of marketing that we do around it. I will be honest, we don't do a huge amount around it because I think, like Tom and Dave have said, the API lends itself to the people that need it so it speaks for itself in some ways.

So I think most of the time when we're onboarding new developers, it's often through new companies that join us and that's done through the customer team. The customer team will often prospect customers that they think would need something like the API and suggest it to those customers. The team will then ask those customers what they need from the API and then addresses the different routes that Tom just explained.

I think we are looking into doing more with our community so we would love to do more live stream stuff. We'd love to do more webinars. We run a monthly webinar at the moment that's around the product updates and the different features of the product itself, but we haven't yet done one around the API so that’s an area that we can expand into. That's what we're going to be doing in 2021; putting a lot more effort into promoting our API to people that may not have heard about it yet. But right now we mostly do it through our customer team or our sales team.

PW: So when your customer team talks to a customer, sometimes the API gets brought up and they can see that there is a natural fit. One thing you mentioned is that the API speaks for itself. Do you find then that the take-up of the API from those customers is pretty quick? Do they need to be guided through the journey from first being interested in the API to actually using it? How does that process tend to work?

Torry-Cook: I think one of the other guys will be able to speak more to this, but I think it probably varies quite a lot. We have our whole developer site that has all of the documentation, all of the help articles, everything that developers would need to implement the API. So there is a lot of help there. As far as I'm aware, the customer team would then lead them through those articles and then would be available to chat with them, go on a call, whatever they need to get them through it.

So I don't think that there's any trends. I think it's obviously different for every customer, but the customer team is hugely involved with every decision around the API because obviously they want to help customers understand how it works, and they're always available for anyone to ask them anything about the API. But yeah, we've got a really nice, extensive developer site ready with all the information.

De La Pena: Yeah. And the product team gets very few requests about onboarding people into the API, which is a good sign. I think that the customer team, credit to them, there's some really good technical people in there. They really help out with the onboarding process, and also from the support perspective. They do this with your pay as you go API users all the way up to partners. A lot of communication happens on a regular basis on the partner programs, and also from the support and new feature request perspective as well. 

PW: Going back a half step, Sophie, one thing you mentioned that you want to do is more webinars and more live streams. That's something I'm hearing a lot from providers, this idea of live streaming with their customers and having a little more immediate connection. Can you speak to that? I know you said that it's not something you'd do a ton of, but what's pointed you in that direction that that's the way you want to go?

Torry-Cook: I think it comes from the fact that we do have a lot of engagement with our current webinars. We run these Signable FAQ webinars and they are very interactive. Basically, we open up the chat and we're able to get participants on that webinar to send us in questions live. We have a member of the marketing team and a member of the customer [success] team to answer anything that anybody sends in.

Those webinars have done the best out of any of our other webinars, they've always had the highest success rate. From looking at that and how much people enjoy getting involved and asking the questions that they want, I think that's where it comes from because, again, like you say, we want to build this developer ecosystem. We want to build more of a community where people can share things that they would like to see with the API.

We always want to listen to whatever the developers want. We want to improve the API and do everything that we can to provide the exact thing that people would like. So I think that's where it goes with live streams.

PW: That's great. I’ve heard that a lot in talking with other providers, live streams are really taking off. Some use it as a way to let their audience look over a developer’s shoulder while they work. Others use it as a form of office hours. It's really interesting to see. It seems like live streams get a lot of uptake because the community can feel like they're more involved. I’ve seen different platforms being used like Twitch and YouTube Live, what platform do you use for the webinars?

Torry-Cook: For the webinars we use Zoom. With Zoom, you have your Q&A Function, so I think that's how it was happening before. 

PW: You mentioned that you're getting a lot of engagement on those webinars. Can you talk about some of the KPIs you use, not only for the webinars, but for any of the different ways of engaging with customers that you are trying to measure?

De La Pena: Ultimately, we have this north star and associated metrics we work with and that's obviously  key for us to be able to keep honing and refining what those are, but also continue to figure out how the team can drive towards those.

But there are things like NPS scores and engagement on the customer side. I think that goes for the API and for the app as well, because we do get a lot of communication with customer success and partners, or API users, I think.

PW: Did you say NPS scores? 

De La Pena: Yes.

PW: What is that, if I can ask?

De La Pena: That's a net promoter score. So it's basically a periodic survey that gets sent out to our users and they score one to 10, and we get good engagement on the NPS score and it's really good to get feedback there as well, and we're able to respond to that feedback.

Torry-Cook: Shall I speak from the webinar perspective? In terms of KPIs we have quite a lot of people that join us on those, so the main metric that we would track is obviously how many people join us on the actual webinar. Off the top of my head, I think it's around 70-100 people that join us on the live webinar. We then put the recordings on our website and have them available to download. So we have around at least 50 after the fact as well. So yeah, it's roundabout 150, all in. Obviously, that may sound small in terms of other companies potentially, but for us, that's a fairly big audience that we're able to reach just in one webinar. So I think that's really, really good.

PW: And how many webinars are you currently running in a year, a quarter, whatever the time frame is?

Torry-Cook: We run one once a month. So that would be 12 then over the next year or so.

PW: I took a look at your Developer Portal earlier. Did any of you have a hand in setting up the developer portal as it currently is? Are you looking to make any changes to it? What kind of feedback do you hear from people about your developer portal as it is right now?

Dickinson: I can give that one a go. Our developer portal was written for the version one of the API, and the big movement over the coming year or so will be a release of a second version of that API. So that will bring with it new documentation.

We hope to have more dynamic documentation, possibly using something like Postman, possibly using something like Open API or Swagger to document the API, basically get it into a form that, no matter what kind of developer you are, what world you're coming from, you can consume it really easily in some way.

The other things that we have around the API are our Webhooks. A lot of developers, they need that event-based integration so that will also see improvements over the next year. And the other thing that we currently offer is a PHP SDK which is hosted on GitHub. It's in discussion at the moment, but we hope to have SDKs for multiple languages in the future.

So it's definitely a space [the portal] to watch, but that all being said, I think our developers are quite happy with the current portal. I think it provides enough of the information they need to get up and going and there's the SDK there to hold their hand if they're using PHP. 

PW: Then that raises a couple of more questions if you don't mind. You said there's a PHP SDK. What drove you to using PHP versus any of the other languages currently?

Dickinson: So we are a PHP house. I guess we aren't giving too much away, but it was very easy to write an SDK for PHP. At the same time, looking at usage of different languages on the web at least, PHP is still a massive chunk there. So we found that a lot of our developers who were coming to us were PHP developers. As we grow, we're finding customers coming with a need for more languages. But that's all coming so watch this space.

PW: Without promising anybody anything, are there certain languages that you're hearing from your audience that are really needed? 

Dickinson: I've heard requests for Java, for Python, for Node.js, but all of that is still in discussion.

PW: Last question, and it's very interesting because you said this year you're trying to introduce V2 of your API. Anytime you version your API, that's a big lift on your part, but that's also a big deal for the developers that you have out there. How do you plan to communicate that with your developers? Whether it's a roadmap, email communications, how are you going to let them know that this change is coming down the pipe and these are the steps that they're going to need to migrate over eventually?

De La Pena: In fact, we've already had partners be in touch that want to be involved. So I think involving actual real life developers in the process is really important, not only for the discovery, but also the planning of rolling it out and how the Versioning, and all that stuff, how it works. That's a really important part of it because we need to ensure that the developers come first.
I’d like to thank the team at Signable for taking the time to speak with me and share the company’s approach to developer engagement. This is part of a series of interviews with developer relations experts such as Gregory De Jans at TomTom and Raphael Assaraf at Aircall. Be sure to keep an eye out for future interviews coming soon.

Be sure to read the next Ecosystem Engagement article: How Brian Douglas’ Team of 10 Developer Advocates Supports GitHub’s 65 Million Developers