API-Driven development + Roadmap API + Live Coding

The Roadmap Team

The Roadmap API is here and with it countless ways to customize and prioritize product roadmaps, collect feedback, and engage stakeholders.

We opened our API sooner than most SaaS products at our stage because, aside from a personal bias toward openness and transparency, there were a few things we did early on that saved us time and helped us ship our API.

API-Driven Development

Opening our API was a much easier project because, like the last 4 SaaS products I’ve worked on, I started coding Roadmap using an API-first approach. Like Guy Levin describes here, API first, like mobile first, means that instead of building a product to be consumed on mobile devices, what you are building is an API to be consumed by client applications and services.

By focusing on the API from the start with things like segmentation and a comfortable routing scheme, it helped us ship a more mature, consumable API without having to look back out our app and deconstruct the pieces to expose through the API.

Another advantage of API-driven development is that once you’re ready to build 3rd party integrations, like with Zapier for example, they are much faster and clearer to build.

To do this effectively, you’ll most likely want to think about your app from the start as a single page application (SPA). It might be less intuitive for some at first, but it really helps to ensure the API is not coupled with UI code and is RESTful.

Live Coding Client Libraries in Go, Node, Python, and C#

You can take user focus in your API a step further and build client APIs. Having client APIs means that your end-user will have a smooth experience getting started with your API in their language.

I’m currently building open source client libraries for the Roadmap API via live streaming in Go, Node, Python and C#. I’ll be live coding our client libraries and streaming with Livecoding.tv every weekday at 1pm EST for about an hour until these 4 libraries are complete. Join me here.

Improving our API and expanding client libraries will be an iterative process. Even though our own app is using the entire API, writing the documentation and building client libraries is still additional work we have to make time for.

Our API documentation is also a work in progress. We saved a ton of time with our documentation using Slate , an open source API documentation project by Robert Lord. At first I investigated Apiary, API blueprint and a few others. Swagger is something I might come back to later, but for now I really like the simplicity of a static site generator and Slate was exactly what I was looking for.

Why It Matters

The point of API-driven development isn’t just to make your life easier, it also puts a user focus in your application from the start. Opening your API makes your platform flexible to the creativity of your customers. When you understand your API’s use cases with an agile approach from the start, it makes it easy for other systems to consume and create value with your app.

While there is a big trend toward consolidation, many product teams still use disparate tools to collaborate, prioritize, and make progress with their product roadmaps. Early on we built integrations with some of our favorite tools for getting things done like GitHub and Trello. Then we focused on integrating with our favorite communication tools like Slack and Intercom.

Our first integrations were focused on ‘scratching our own itch’, which is something we learned from Jason Fried. We prioritized these integrations because they solved a problem we experienced and understood after using this stack for several years.

Before we built additional integrations for tools we weren’t personally using we wanted to have our API accessible. This way teams wouldn’t feel their particular tool set or way of working was isolated or incompatible with Roadmap. Prioritizing our API buys us time to collect feedback from users requesting integrations with tools like Jira and Salesforce to make sure we’re building something useful.

How it Works

The API is designed to make customer feedback and product roadmapping exist in harmony as part of a larger ecosystem.

Here are a few examples of things you can do with the Roadmap API:

  • add product feedback to Roadmap from systems of record like CRMs or support desk software
  • track progress of completed work in other project management tools
  • share product roadmaps or updates within your own web app

Learn how to use it here.