Looking to better promote our full-featured software platform to external developers, I decided we should lead by example.
After investing a great deal of energy in overhauling the publicly available programming interface to our cloud-based platform, our company was ready to release it to the masses. Our marketing team was developing a campaign to promote our revamped REST API but I felt that something was missing.
What drove this decision
Our original, SOAP-based programming interface, while feature-rich, was considered outdated and had truly lost favor with external software developers. It was time to embrace the new RESTful paradigm and we knew that we had some work to do to reengage this audience.
So, in tandem with the launch of the new REST API itself, the company was erecting a developer-focused, community-style web site to include a full set of method-level documentation and source code examples. We also planned to highlight a few partners and customers that had invested in the new API and who had built their own integrations to our platform.
But to really show off the power of this new API, to lead by example, we needed to do even more.
The decision: Build our own API-based application as a reference model for the developer community
Several months before this decision, our Product team had started plans to deliver a lightweight, mobile-friendly application that would help our customers gain insight into the business processes that they were automating with our platform. However, we had not landed on the specific architecture we would use to build this new application.
This decision to create a reference app for the REST interface helped us connect a few important dots. We now had a path forward that would showcase the new API while also delivering value to our customer base.
Plan of attack
To pull this off, we first had to put ourselves in the mindset of the external developer - which was a bit harder than we expected. We would build our new mobile application as if we were operating entirely from outside the organization. We would try to limit our use of any internal tools or frameworks to artificially accelerate development or to negotiate deployment shortcuts. Only after we went through what our target audience would experience would we truly appreciate the effort involved.
The details of our implementation, which covers everything from negotiating API keys, session authentication and runtime usage governors to UX library components, responsive design, and error handling are beyond the scope of this post. What is more interesting perhaps is that we decided to chronicle the entire experience and share it publicly on the developer community site.
The impact
The greatest impact of this decision was a delay in getting our new mobile application to market. Choosing to go the full API route resulted in more time being spent configuring and troubleshooting the code for our mobile application - AND debugging the API itself.
There were up front costs and delays while we developed a parallel release environment and deployment schedule, separate from our primary code base; however, this ultimately helped us deliver iterations of the mobile application much more frequently as it could evolve independently without any direct dependencies on the underlying platform.
In the end, we would deliver our mobile application to happy customers who were completely unaware of our internal implementation decisions. But the payoff was magnified as we also delivered a complete application blueprint to external developers looking to embrace the platform.
Look for more reports from theProductPath around product investments, go to market choices, and software platform promotion here on PM Decisions.
To address one of the most critical problem areas for customers using our software platform, I decided to roll up my sleeves and conduct the fieldwork myself.
The Product Decision: Enlist the help of our User Research expert to coordinate formal interviews with a suitable group of administrators and end users from our active customer base.