Lesson Learned: Keep Assumptions Minimal

In October of 2017, I took ownership of our organization’s new “Integrations” product — a comprehensive name for our future suite of API offerings. At the time, we had no real idea exactly what we wanted to achieve with this offering. What we did know is that we were losing a good amount of potential business to prospective clients who wanted the ability to take data from our web application (tool that combines reporting, analytics, marketing automation, and contact management).

Rewinding a bit to ~April of 2017, we had closed a deal with a large, national brand who wanted to make use of this application — but mostly for the reporting, analytics, and marketing automation. They had their own CRM they were using, and did not want to migrate to our application due to their other platform being more robust and specific to their needs. As apart of the deal, the client asked that they be able to push contact data from their CRM into our application so that we could execute our marketing automation (which would occur automatically in the app in a normal implementation). We were able to build a REST API that achieved this for the client, and the connection with our application worked fairly flawless.

While that API performed well for that client (and still does), the feedback we were getting from internal stakeholders (i.e. sales & service reps), is that their clients were wanting to push data out of our app…not pull data in. Thus, the “Integrations” team was built and road mapping began immediately. The previous product owner began researching and defining requirements for this new solution. The requirements were as follows:

1. Its usability has to be super simple for our non-technical clients — they need to be able to implement this using a self-service component that requires minimal support from our service team.
2. Sufficient documentation needs to be written to explain implementation, authorization, and data-sets available in our output.
3. It had to push contact data out of the application, in real-time, for both New & Existing contacts.
4. Finally, the API gateway has to [potentially] be able to process tens of thousands of requests.

After researching how we wanted to build this API, our engineering lead very quickly settled on building a Webhook program within the app. This was by far the best solution as it met all requirements and required minimal development resources — this is around the same time that I took ownership of the product.

Thankfully, we had two things working in our favor:

1. Our engineering lead is a programming wizard.
2. We already had a framework in our application that we could build on and re-purpose to achieve the real-time push for contact data.

Engineering was able to build a completely functional production backend by late November, and the only need was for the UI components to be built into the application. By mid-December (a couple of sprints later), the UI component was completed, and our new webhook offering was available in the production application. Yet, I believe this is when the real challenge began.

Despite having public documentation made available to our clients and the self-service aspect of the webhook configuration, it became evident very early on that this product was not going to be as simple and straightforward as I had originally intended. We made 3 terrible assumptions during our road mapping: that our clients had the necessary technical resources available, that those technical resources had the knowledge necessary to require minimal support from our end, and that our internal sales & service personnel had sufficient information and documentation at their disposal from which to successfully communicate with their advertisers. Instead, what we’ve found is that not all of our clients have access to a technical resource through their data storage vendors and/or 3rd party applications.

We’ve also seen in few scenarios that the client’s technical resources might not have the programming competency to successfully read through our documentation and comprehend the implementation methods. Surprisingly, Authentication seems to give our clients the most difficulty. While we assumed that most engineers / developers should be able to Authenticate using OAuth2, it seems that has our biggest blocker has been jumping on implementation support calls to walk our clients’ technical resources through this process — despite the documentation existing and Authentication being well documented.

Finally, due to our shortcomings in preparing for the first two items, our sales & service personnel have had to be more involved with implementations, ultimately requiring a higher degree of technical competencies that most of them do not have.

To mitigate these shortcomings, I’ve requested our product marketing team to parse through our API documentation to ensure that the implementation steps are clear and comprehensive. I’ve also started work on a training series to elevate the technical competencies of our service teams, as well as involving myself in trickier implementations with our larger clients. Due to the varying degrees of technical knowledge from our sales & service teams, I’ve found that attaching myself to the pre-sales and implementation process often helps ensure expectations are set appropriately, and that we stay within scope of the implementation. I know this is not a common Product responsibility done at most companies (and even other teams within my own company), but it sure saves a lot of headaches for me down the road — and also helps me get some communication directly with our clients/users.

All-in-all, the biggest lesson I learned in bringing this product to market is that we made too many assumptions in our road mapping, which enabled and further embellished the assumptions we would make later in our Go To Market strategy. We should have introduced our Product Marketing Manager to the process much earlier to make sure our documentation was clearly defined and comprehensive. More importantly though, we shouldn’t have assumed the resources available to our clients. The process should have been built around the users least likely to successfully implement on their own, instead around the ideal user with adequate resources available. However, part of this could be that the solutions are being offered to clients who fall out of scope for these products…more research needed for that. Despite that, it doesn’t change that I need to be more mindful of my users when we ship our next solution.

If you enjoyed the article, please give it a clap so others will see it here on Medium — I won’t discourage a share on your social media either! As always, please feel free to comment and share your thoughts. I’m always interested in hearing others’ opinions.