IMG.LY is Going Public… with our Product Roadmap

This post was originally posted on 16th August 2022.

Jan Bussieck

We recently launched our public product roadmap allowing our customers and would-be customers to explore what we shipped with each CreativeEditor SDK release, what we are currently building for the next, what features, and enhancements are coming up and which are still in the planning phase.

More importantly, customers can give us feedback on which features they prioritize most highly, and propose new features and ideas on how to improve our SDKs to better fit their needs.

Many companies such as Front or GitHub have opened up their roadmaps to their users, so why was this an important, worthwhile step for us?

Let’s take a step back. IMG.LY is a B2D company, we build SDKs for any creative editing use case imaginable, from photo and video editing to creating advanced designs and templates.

Since we power the creative editing capabilities of our customers’ applications, we are one step removed from the end users of our product.

This has two important implications.

Firstly, we need to work closely with our customers and understand their use cases and constraints. We cannot recklessly ship features and make changes like the code-slinging cowboys we might imagine ourselves to be.
Our customers’ businesses to a significant degree depend on our judicious and careful planning.

Our relationship does not end with a transaction, rather we become partners in crime. As such we have an obligation to ensure they can smoothly integrate changes we make to the SDK into their product and be cognizant of the fact that they have a roadmap, too, with its own constraints and priorities.

Secondly, our customers’ voices are amplified by the thousands — in some cases millions — of end users they represent. That means we must open as many channels as possible to hear them.

Launch Features & Drive Adoption

Back in the day (really two weeks ago) after a cycle of planning, designing and developing, we would ship a release and announce it by sending an email to our list of customers and publish a blog post and a more or less complete changelog on GitHub.

That was not enough.

Every feature and product improvement that you ship is a tiny launch, and you do not want to launch to crickets.

Our public roadmap affords us the obvious benefit that we can communicate to customers in advance what is coming down the pike. We decided to go beyond simply mentioning a feature in dry technical terms and added graphical illustrations, as well as highlighting benefits to end users. Our goals here are not only to inform, but to educate, demonstrate value and drive adoption.

Building the Right Features

There is a common saying in product management that goes something like this, “If you ask your users what they want, you end up shipping faster horses instead of iPhones” (or something along those lines).

While there is truth to it, and we do have our own vision for our product suite, incorporating customer feedback from sales and support / customer success is an integral part of our product development process.

There are, however, problems with relying exclusively on these two avenues.

On one end of the spectrum, feature requests from the sales side can create a misplaced sense of urgency and often run the risk of drowning out the voice of existing customers.

“We just need feature x to close the deal” it’s an all too familiar refrain, but deals seldom hinge on any one particular feature. In fact, requirements in this phase are often quite inchoate and subject to change.

On the other end, feedback from support comes at a stage when some kind of friction, some pain has already occurred. While great for catching and fixing bugs, often customers utilize an API in a way, we did not intend to realize a certain feature and consequently run into problems.

A great example is our serialization API, allowing users to save and restore the state of the editor. Primarily built to enable cross device/platform interoperability and save work in progress.

Support would get request after request about this feature before we realized what our customers actually wanted was templating, a feature already in the works that we just hadn’t communicated yet.

Now that we have a public roadmap in place, potential customers and customers alike know what is coming and vote to prioritize features.

Not only can our team rest assured that what they are building is being eagerly anticipated, but we also garner more frequent and more balanced input from every stakeholder.

Customer Acquisition: Addressing Objections

Our SDKs form an essential part of our customers’ products.

The decision to purchase a license often comes at the end of assiduous evaluation, due diligence and weighing the pros and cons of make vs buy. Some of the questions that arise naturally during this process are

“Do I have any influence on product development?”

“Will my concerns find an open ear?”

“How actively is the product being improved?”

“Do we stand to profit from the SDK in the long run?”

“When will the missing feature be taken care of?”

Being open about our product roadmap is the best way to answer all of them and address these concerns as early as possible.

What is more, now features we haven’t even shipped can become selling points and conversation starters.

By demonstrating a commitment to continuous improvement in a customer facing manner, your daily business, that is the active and focused development of your product, can become a differentiating factor making you stand amongst your competitors.