Prioritizing Integrations and Platform Management: Interview with Molly Shelestak

Molly Shelestak has worked managing platforms and integrations for a decade, at companies like Google, Neustar, Rentlytics, and most recently as a Platform Engineering Manager for Andela. She shares her advice on prioritizing integrations, aligning internal and external stakeholders, tools for managing APIs and integrations, and why you should always set longer timelines for building integrations.

How did you get into managing platforms and integrations? 

I started dabbling in integrations and platforms during my time working at Google as a Technical Account Manager for the DoubleClick Bid Manager, where I managed the feature set and roadmap for one of our largest customers, Omnicom. I led a team of five working with the customer to define the scope and requirements for the feature set and integrations that would support their overall digital marketing strategy and goals across the full suite of DoubleClick products. I was a liaison between product and engineering, i.e., the PM for the customer.

I took our customer’s business goals and transferred them into a product roadmap based on what would add the most value; my analysis showed that integrations were key to accomplishing their goals. 

I operated as the technical point of contact for each of the integrations: I owned the communications, requirements, timeline, testing, etc. for each of the integrations.

After successfully delivering one among these integrations, a partner recruited me to join their team as Senior Product Manager for their Platform Infrastructure team.

The scope of this role included platform work, our ETL pipeline, internal integrations, external log file integrations, and providing assistance to our integrations team with any necessary technical specifications and support.

In this and subsequent roles, I owned everything related to platform, core services, data model, and integrations, including the scope of developer operations and general upkeep of our solution, management of the technical roadmap, technical debt, and R&D work.

How do you define a platform?

Platforms define common infrastructure, tooling, services, etc. which make it easier to scale development in a reliable and consistent way. Think of platform features and functionality as developer building blocks: anything from a common logging platform service to an event service to capture and report on business events.

Platforms come in all shapes and sizes and can support many use cases.  Throughout my career, I have worked on: data management platforms, developer platforms, IoT platforms and a talent marketplace platform.

One of these platforms helped manage and scale integrations and report processing pipelines; another helped manage IoT devices, integrations and automation. For the talent marketplace, it enabled us to scale our product offerings and increase velocity of the engineering teams.

At the end of the day, it comes down to business and team needs. Many teams start with a monolithic application which evolves over time into a platform as the business scales and expands.

Do you have a framework for prioritizing which integrations to build first? 

Many frameworks could be used for prioritizing integrations. I use the “Cost versus Value'' matrix most frequently because it’s simple and easy to implement quickly.

This framework partitions integrations into 4 categories: low impact/low cost, low impact/high cost, high impact/low cost, and high impact/high cost; these categories help weigh customer value against the effort to build and support the solution. This exercise can be done multiple times to help prioritize more granularly.

This process is merely a starting point for prioritization: we still need to gather input from stakeholders which may reshuffle the roadmap. The important part is having a starting point with which to justify prioritization. Then I can take this to stakeholders to help them inform next steps.

At Andela, for example, we map different integrations to our revenue funnel.

As a talent network, we have users drop off at each stage in the onboarding process. As an organization, we are focused on improving the rate at which we retain users at the top of the funnel. Therefore, we decided to first build integrations that improve the early user experience to increase the number who move to the next stage. For us, this was more pressing than improving the experience of users who were already far into the platform.

Every situation will be different. Ensure you have identified all the stakeholders and their business goals so that you can factor that information into your initial prioritization. 

Do you have advice on successfully working with other departments to build and launch an integration?

Communication and alignment are two of the most important aspects of delivering successful integrations. Identify all stakeholders and define success criteria up front. Define expectations around timeline, outcomes, communication cadence, etc. in advance of kick-off. Ensure all players involved -- internal teams (business, engineering, product, marketing, etc.) and external teams (integration partners and clients) -- are aligned and onboard with the integration plan.  

Take time to ensure stakeholders understand all that is involved with a successful integration, the level of effort required to build it, and the impact on the current roadmap.

This is where the prioritization exercise comes in handy: it provides a common language for discussing integrations amongst stakeholders across different business units and acts as a tool for helping stakeholders assess trade-offs early. 

By investing more time upfront working with stakeholders, you force requirements, goals and expectations to the front. This will help minimize surprises and sets you up for success. Make sure your partners’ priorities are aligned with yours, and the timeline is going to work for both parties.

Related Content: How to Integrate Systems Like a CTO: 10 Best Practices

Is there a common mistake you see in managing the build of integrations?

Time estimates - as related to expectation setting and alignment (see above).

I advise doubling or tripling the initial estimate. It’s always the edge cases that kill you. Once you begin testing the initial iteration of the integration, you’ll find anomalies in the data and edge cases that are implementation-specific. 

More interaction points also increase time to delivery. If you have to talk to the customer in order to talk to the integration partner, for instance, the added latency means accomplishing tasks and resolving issues takes longer. Ideally, work directly with a dedicated technical support team member on the integration partner side and directly access your customer’s account with that partner to expedite testing and implementation. 

Integrations span organizations, which can exponentially increase collaboration complexity -- vacations, exits, time zones, and priority changes all affect timelines. Planning ahead with “extra” time will avoid mistakes made under pressure and smooth the roadmap. 

Are there any tools you would recommend for APIs and integrations?

I recommend Apigee as an API management tool if you are Enterprise and can benefit from help with API infrastructure, maintenance, and monetization.

For integration documentation, testing and development, I highly recommend Postman.

Postman can help you communicate integration examples and requirements to your engineering team. You can set up API collections, helping customers integrate with your platform. Collections can also help internal business teams easily access internal platform data. Mock servers can help decouple frontend and backend dependencies. 

During my time at Softbank, I needed to integrate with Brain Corp, who built the navigation solution for our commercial autonomous vacuum cleaning robot. I had no company contact and they had little to no meaningful API usage documentation -- I had to reverse-engineer their APIs by running our robots in our office! I did it all in Postman, which allowed me to record, document, and reproduce the results for our engineers.

How do you provide a good third party developer experience?

Documentation, documentation, documentation - I rarely encounter sufficient investment in developer experience!

Focus on what a developer needs to be successful and remember that a developer is not a product manager: the more business context for the API, samples, and use-case descriptions the better!

It isn’t always the case that engineers have sufficient context for the integration they are building: a specification can only be so detailed and often misses critical elements. The better the developers understand the product and what it is being used for, the more likely they are to build a great integration.

I was just working with EMSI, for example, which has a ton of data in the labor market space that allows you to understand what skills are marketable and valued at in today’s job market. I partnered with their team to implement a solution. They sat on multiple calls and demonstrated their UI. We talked through their data and APIs and collaborated on a solution with representatives of each engineering team.

This made for a great experience that helped us align business and engineering. Since our developers were on the call, we were able to get to a solution we all understood and aligned behind. This type of partnership collaboration makes everyone more invested in the outcome and leads to solutions more likely to satisfy the business needs on the first try.

Related Content: The Pros and Cons of Offering Your SaaS Customers Native Integrations vs Third Party Integrations

What do you advise product managers who are new to integrations?

Communication is king. I can’t stress enough how important it is to manage stakeholder expectations around integrations. Spend time defining the problem you are solving, key customers, key stakeholders, goals, timelines, expectations, deliverables, success metrics, etc. Document everything and ensure you have alignment and buy-in from all parties involved. You want everyone on the same page when you begin to ensure you will be set up for success. 

Related Content: Building a Support Strategy for Your B2B SaaS Integrations: Key Considerations for Product and Technology Partner Managers

Here are a few tips that have helped me over the years:

1) When you come up with your timeline, pad it. 

2) Ensure you have invested clients who will help uncover and address edge cases as they arrive, which are often a big cause of delays.

3) Incorporate an alpha and beta roll-out of the integration with key success criteria and expectations. 

4) Success criteria for the beta program should be very clearly defined. Two weeks with no bugs, for example, might be one requirement. Write out the expectations and decision points clearly, and make sure all stakeholders are aware and bought in.

5) Don’t engage customers who aren’t responsive or a churn risk. 

6) Come up with a list of beta customers that will cover multiple use cases of the partner app and communicate very clearly what it means to be part of your beta. 

7) At Rentlytics, for example, which handled property and financial data, we picked 5 customers who were managing their properties quite differently.

8) Come up with a launch plan and rollout strategy. Once beta testing concludes, everyone should know what will happen next and when. 

9) Inform business teams and executives of this rollout plan -- they can pull levers when needed and prioritize their own resources. If executives are out of the loop or you blow through your timelines, they may lose faith in the initiative and fail to support you at critical junctures.