How Talking to Customers Helped Us Build a Better API

talking to customers - shopify

Hanging out at Shopify to talk with our customers

We decided to build an API for iDoneThis because many customers had requested it.  It would use OAuth2 for authentication and would support everything one could do through the iDoneThis web interface. You would be able to like entries and comment on them, aggregate exactly who commented how much on which days, and more.

We were ambitious!

But we noticed that a weird thing had happened—after having listened to customers to give that initial impetus to build the API, we stopped consulting them completely!  We didn’t know exactly what they wanted from the API—only that they vaguely wanted it—so our plans included building everything to fill this abstract customer need.

We decided to pause and that before we started building it, we would do some research to validate or invalidate our assumptions.  What we learned surprised us and helped us save an incredible amount of development time by focusing API development on exactly what the customer wanted.

How We Talked to Customers

“Talking to customers” is often referred to as something you should do in theory. Here’s how we actually reached out to talk to customers, synthesize what we learned, and then talked to customers again.

Finding the right customer to talk to

Help Scout made it easy to find customers interested in an API.

Help Scout made it easy to find customers interested in an API.

Rather than sending out an untargeted blast to our user base, we started by looking at inbound messages from customers who specifically talked about wanting an API.

We use Help Scout do handle customer requests. It provides a nice search and allows us to tag requests. That made it easy to find prospective customers to talk to. We emailed those customers and were able to make interview appointments with some of them.

Prepping for and conducting interviews

To prepare for these interviews, we created rough scripts that would remind us of things to talk about. But we were also prepared to follow interesting lines of thought as they arose, so the script was merely a guideline for us to help us not forget important details we wanted to know.

An excerpt from our interview guide.

An excerpt from our interview guide.

We mostly started off with getting a bit of context from our interviewees: where they work, in what role, and how they use iDoneThis in their day-to-day operations.

With this background, it was much easier to understand where actual pain points could lie. We then moved over to talking about which other applications they use, and why they believe those should or should not be connected to iDoneThis. If we were talking to a more technical person, we’d also ask them about the authentication schemes and data formats they would prefer.

Analyzing Interview info

We collected the key points from all the interviews in a document and classified them based on recurring themes.

We found two different motivations: some wanted to solve a real problem through the API, while others would have loved to play with it, for example in a company hackathon.

Some of the themes we found in our customer interviews.

Some of the themes we found in our customer interviews.

Those without a pressing need had some great ideas that we may do more research on later, but for now we wanted to stay focused, so we concentrated on those with an actual pain to solve.

But we didn’t stop here with our classification. Among those with an actual problem, we found that almost all of them were interested in simply being able to post a new entry to their team through an API. About half were also interested in reading the entries their team had posted.

This finding significantly reduced the scope we considered for our initial API: we’d concentrate on doing only these two things, but do them well.

Authentication-wise, we found out that many didn’t want the complexity attached to the OAuth2 authentication scheme, so we also planned to create a much simpler token-based authentication that we had initially considered bypassing. We found valid use cases that would be much nicer to implement using OAuth2, so we planned on providing that as an optional addition.


While we were busy building this focused API, we knew that this kind of customer involvement would also be very helpful for deciding which integrations to offer.

An API by itself is mostly useful for those who are software developers themselves or have access to some in their organization. It’s great for custom solutions that connect iDoneThis to other systems you use, but what connections should we provide that wouldn’t require any custom development?

Our initial gut instinct told us that Slack and HipChat integrations could be very useful. We’d heard requests for these from customers before and internally also use Slack, so it was easy to see for us that a chat bot that you can post your entries to could be valuable. Similarly, having your team’s iDoneThis feed in a separate chat channel would enable everyone to stay in the tools they do the most work in.

But again, we didn’t want to blindly trust our instincts and talked to customers before we started building anything. This time, we were interested in the needs of all kinds if iDoneThis customers, not only those who had asked about an API before. After all, we wanted to solve problems for technical as well as non-technical customers, no matter whether they were able to or wanted to spend resources on a custom solution.

We emailed a short qualitative survey with open-ended questions to some customers who had recently been active on our site. In this survey, we only asked a) which applications they would like to use with iDoneThis and b) how that would be of value to them. Feel free to take the survey here, we’re always interesting in gathering more data! 🙂

Our Qualaroo survey.

Our Qualaroo survey.

To get more diverse responses, we also added the survey to our website as a Qualaroo widget. Again we classified survey responses to find out what kinds of applications customers would like to use iDoneThis with. That helped us come up with a list of 61 different applications — but because this survey was still qualitative, it didn’t tell us numbers we would be able to rely upon.

Based on reasons given and the applications’ characteristics, we then cut down the list to 12 applications to have a more manageable number. This enabled us to create a quantitative survey: one where you would only be required to choose one thing from a list. We again distributed this new survey via email and the Qualaroo widget.

The quantitative survey we sent out.

The quantitative survey we sent out.

After only a few days it became clear that both Slack and HipChat integrations were very desirable — they tied for second and third place. But to our surprise, the number one spot was taken by … Google Calendar!

This again showed us the value of doing research before starting to build: we hadn’t expected Google Calendar to be in such demand, and at the same time got confirmation for our instinct telling us that Slack and HipChat would be a good choice to integrate with.

Since we’re very certain already how Slack and HipChat integrations should work, we are building these first. While we are doing that, we will talk to those who requested a Google Calendar integration to find out how exactly that should work — do you want to add all your appointments to your main team, or do you need more control? For example, should we only add appointments that you tagged in a certain way? What about all-day appointments?

There are a few open questions on this one, but we’re very optimistic that talking to customers will again help us figure out what solution would be the best to focus on first.

* * * * *

Since we’ve started with this research-based development, we’re getting to know our customers better and better. Apart from the API, performance, usability, and a mobile app are in high demand. Rest assured that we’re working on these, but taking our time to do the research first — to make sure we build what you need and you get the essentials as early as possible!

We’ve recently released the iDoneThis API, meaning that developers can now access iDoneThis data programmatically! Our customers can now use integrations with other applications for posting to and reading data from iDoneThis. Examples are an Alfred workflow, a WordPress plugin, and a command line client, mostly written by helpful external developers. More integrations are on their way: right now, we’re working on Slack and HipChat integrations, next up will be a Google Calendar integration.

To get started with integrations yourself, take a look at the list we’ve compiled here! Are you still missing a certain integration? Tell us about it! If you’re a developer, please head over to the API documentation and join our Google Groups API list! We’re looking forward to meet you!

Customer research: you should try it!