Today’s process

Usually, when we talk about what’s going on with our APIs, we’re focusing on new features and other technical changes. However, we don’t talk much about our processes – how we figure out our roadmap and strategies for the year ahead, how we decide on which features to work on and how to implement them, and how we work with partners and customers to build new features.

Traditionally, many companies have tended to conduct their development according to the preferences and instincts of one or a couple of people in charge. This approach can be very successful, but it can also lead to time wasted on building features that end up being used by very few customers.

At e-conomic we have always emphasized listening to the input and needs of our users. In the API team, we have now decided to take that approach even further and actually involve external partners in the planning and development process.

Collaborating with FTZ

Earlier this month we introduced the ability to send e-conomic API invoices via MobilePay Invoice. For this project, we partnered up with FTZ that asked us early on if we would support MobilePay in our REST API. Together with them we defined requirements for this project by looking into what the changes in REST should look like in order to expose MobilePay Invoice, and what exactly needed to be exposed.

We decided to leave the entire setup of MobilePay to be conducted inside of the web application, which allowed us a quicker time-to-market, and build things in MVP fashion. To further speed up time-to-market, we didn’t stop at defining requirements together – we actually did parallel development together with the FTZ engineers.

This way, we were able to together work on the implementation, with us working on exposing the feature in the API, and FTZ working on consuming MobilePay Invoice in their custom solution.

Working together also allowed us to fix some potentially major issues which occurred during the deployment. They were caught quickly and communicated by FTZ, allowing us to solve the issue before it was noticed by any other partner.

We also worked together on the business level in order to roll out this feature. The entire marketing campaign was coordinated between us and FTZ so that on the day of release we were able to quickly see the uptake of MobilePay Invoice by the end-consumers.

This wouldn’t have been possible without a close collaboration, and we wouldn’t have been able to see the usage for the first few days and weeks after the release. Thanks to this partnership we were able to get instant confirmation that our proof of concept actually worked and could easily be used by other partners.

Defining requirements with partners

For our next major project – building an accounting (/journals) endpoint in REST – we’re taking an even more structured approach to the development process.

We have teamed up with five partners who have each provided their input to what this endpoint should include. They represent very different domains and sizes, thus ensuring that we cover the needs of all our end-consumers. All companies showed a very collaborative approach and they were happy to contribute to this project.

It’s still to early to discuss the full output, but from what we can see just from the requirements-gathering process this collaboration will be fruitful. For one thing, it has given us a much better insight into the expectations of our partners and allowed us to reduce the possible feature-set on accounting. This saves time which can instead be used to develop other endpoints or entirely new features, which is a win-win situation for all of us!

We’ve been using Trello as a collaboration tool and have worked with the partners on refining requirements so that we now have nice-to-have’s and need-to-have’s for the endpoint clearly set out.

By involving partners in the process like this, we’re in a much better position to build new endpoints that actually reflect the needs and concerns of those who are going to use the endpoints.

As we build the accounting endpoint (/journals), we will move forward together with the partners to ensure that we stay on the right path and make the right decisions for creating the most useful endpoint we can. By the end of Q1, we expect to be ready with the first results of our work on the endpoint.

Sharing the roadmap

On the note of when we expect to have features ready, we’re also planning to share the roadmaps for what we will be working on in both the short-, mid- and long-term. This is also an initiative related to the focus on increased collaboration with partners.

By sharing roadmaps, we will be giving partners a much better and fairer chance of planning their work around what we will be building. This even applies to developers with integrations to our SOAP API. Knowing what is coming up in REST could be very useful when they determine which features to focus on.

A very important note in relation to roadmaps: They are meant to reflect our view of future work at a specific point in time, meaning that the longer we get into the future, the less certain and reliable they are. Even in the short-term, we may re-prioritize or shuffle features around based on changes in the outside world or shifting priorities internally. But they are still useful as a general guideline for what we will be working on.

We will be sharing our roadmap on our developer portal within a few days – stay tuned.

Want to contribute to the e-conomic API development?

We’re continually looking for partners with great domain knowledge that would like to collaborate with us on defining requirements and building new features and endpoints for the e-conomic APIs.

If you’re interested, please contact the API Team and let us figure out how we can collaborate and help each other going forward.