Prioritizing Integrations and Platform Management: Interview with Molly Shelestak
Nikita Zhitkevich lives in the world of partnerships. He leads partnerships and alliances for PartnerStack, which is a leading PRM and partner marketplace.
Nikita shared his insights on when you need a PRM, identifying your ideal partners, strategies to avoid channel conflict, and how he sees the partnership landscape evolving over the next 5 years.
Can you tell me about PartnerStack and what makes it different from other PRMs?
As a graduate of Y-Combinator, PartnerStack has been rooted in helping some of the world’s fastest growing SaaS companies scale. Companies like Asana, Monday.com, Unbounce, Intercom, and Intuit all use PartnerStack to manage and scale their partner programs, and onboard thousands of partners into our platform.
There are a few unique aspects to PartnerStack, which has led us to becoming the #1 platform on G2.
PartnerStack is the only solution that has both the PRM and a B2B focused marketplace that connects vendors with partners. On average, our marketplace drives a 30%+ lift in revenue for customers.
We are extremely focused on partner experience, which is a big distinction for us. Most PRMs are focused solely on the vendor experience. But if both sides of this equation are not having a good experience, then it becomes a problem.
And with PartnerStack, all of your channels can be managed from a single platform - affiliate, referral, reseller and ambassador. We see a lot of companies, agencies, and resellers choosing our platform to help them consolidate their channels into a single view.
How is your partnership team structured at PartnerStack?
Our team is still relatively young, as we launched it in April. The majority of this year has been building relationships and working with both agencies and resellers.
I lead the team, and we have an incredible Account Manager that works closely with our partners, as well as a partner marketing manager that works on any co-marketing efforts we run with partners.
Our partnership team is currently focused on two core areas:
First, working with agencies and resellers that are currently reselling SaaS vendors, bringing those vendors onto PartnerStack.
Secondly, working with agencies and resellers that are looking to shift their existing customers onto a modern partner management solution.
We often work with sales when one of their SaaS prospects wants to launch PartnerStack right away but doesn’t have the internal bandwidth. In those cases, we connect them with an agency partner who we know can do it right away and do it well.
Technology partnerships are also on our radar. We have recently built a number of integrations. One of our goals in 2021 and going into 2022 will be to further build out our technology partner program and our own integration marketplace.
We also plan to enter the app marketplaces of other SaaS vendors, especially CRMs like SugarCRM or Hubspot. CRMs are good partners for us because, with the exception of Salesforce, no CRM has a PRM as part of their product offering. So our software is complementary rather than competitive. And it benefits our customers to have those systems integrated.
“If you’re planning to scale your partnerships at all, you need the infrastructure in place to do this.”
What advice would you give for organizations trying to think through who their ideal partners are?
Ultimately, everything has to come down to revenue. Whether you’re pursuing referral, reseller, or technology partnerships, you have to tie them back to driving revenue.
Especially since you need the support of other departments in your organization, whether it is collaboration with the sales team or the product team to help build integrations, the benefit to the business needs to be very clear.
For agency and reseller partners, I would advise looking to see if they power similar products to yours. I’d also think about whether the partner will continue to evolve over time in the direction you are going and whether they truly understand your product and space.
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.
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.
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.
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.