What is the role of Product Partnership Managers?

Yesterday, I read the story of an engineer who has faced multiple hurdles with providers’ APIs.

However, there was a silent teammate in his rant that I want to spotlight — the person who sourced, engaged, evaluated, negotiated and secured the APIs from that provider. In essence, the Product Partnerships Manager.

Too often, I see people and companies confuse the definitions of a Partnerships Manager and a Product Partnerships Manager (PPM).

Here is the difference:

A partnerships manager belongs to the Sales organisation while a PPM belongs to the Product organisation.

Their activities are similar but the orientation is different. They work from opposite sides of the table.

What is the job of a Partnerships Manager?

This is someone who sells a company’s product and services to channels, or large customers — who typically demand customisations. Any additional upfront effort by the seller (provider) has to be a strategic decision because startups and companies are wired to build once and sell everywhere to achieve scale.

Hence, we call such sales relationships with those “channels” a Partnership because both the buyer and the seller have to give something to make this relationship work.

The selling company will give a financial kick-back to the channel partner and the channel partner will promote its product.

A channel, in this case, is any medium that can get you multiple sub-customers or users.

Sometimes, Partnerships Managers are also referred to as Sales and Partnerships Managers, Strategic Partnerships Managers, Partnerships and Alliances Managers or more loosely, Business Development Managers. It largely depends on the company’s need, sales division and choice of framing.

For instance, say Company A sells flour. It can hire a Partnerships Manager to sell to Culinary schools. A culinary school is not the final consumer of flour, in the way a bread factory is. Rather, through a partnership with the Culinary school that advertises the flour, Company A will get multiple customers. The culinary school can advertise the flour by using it for demos and recommending it in their class. Their class would be typically filled with existing and potential factory owners).

🍞
Note: Cereal flour, particularly wheat flour, is the main ingredient of bread.

To make such an alliance happen, the culinary school might request for the flour to be made with more wheat grain because it only teaches its students (the factory owners) how to make wheat bread.

You get the picture.

So, as the Partnerships Manager, I take that request back to my product team and because of the estimated volume of business I expect to get from that Culinary school, we make a product decision to skew the flour composition that we sell specifically to that Culinary school (as a channel). I don’t have to skew the flour composition for the rest of my client base. Thereby, still preserving my core product.

Now, that’s the basic depiction of a Partnership Manager's role.

📁
If company A sells directly to the factory owner, that would be categorised as a "Direct Sale"

How about Product Partnership Managers?

A product partnership manager, on the other hand, will take the company’s product roadmap and see where providers (aka suppliers) are needed to enable a build.

Following through with our example of the flour-making Company A, the product partnership manager will be the one to source and sign up the makers of wheat, and/or nuts as suppliers of Company A.

🥯
Flour is a powder made by grinding raw grains, roots, beans, nuts, or seeds.

For redundancy, the product partnership manager might decide to onboard multiple suppliers of the same product ingredient.

Back to the article that I referenced earlier. The first lesson that Anthony, the writer, said he learnt was that “If your core business critically depends on a third-party, you had better implement fallbacks early.” Baking in redundancy into your supplier relationships is what allows for the implementation of fallbacks.

Away from the bread analogy, let me tell you a personal story as it relates to the startup and software business I’m in.

Diagram showing where Product Partnerships come in to support the organisation

A Day in the Life of a Product Partnerships Manager (PPM)

After several internships and a master’s degree, my first full-time role was as a Product Manager (Partnerships) for a digital bank. And I’ve gone on to do versions of this role at many other companies.

So, how did my first job as a PPM happen? I’d applied to be a Product Manager (PM) but because there was already an existing PM, the role was split such that one person would focus on the day-to-day (internal) product management while the other would focus on the (external) partnerships needed to make the product work. At the end of the day, we were both responsible for building the product but from different angles. You get?

The company set up, then, was interesting. So, because I was dealing with API providers, I had a back-end engineer assigned to me. As I sourced, evaluated and signed up providers, the backend engineer was there to integrate and also do a second level of evaluation (technical) to ensure that their APIs worked in the way we expected them to.

The first external functionality we (the digital bank) wanted to build out was getting money into the customer’s wallet. One of the methods to do that was via card funding. So, the first provider I signed was a card processing partner, which is the core of many payment gateway businesses. So, to start, I signed Paystack.

Related Article: An objective analysis of seven payment gateways in Nigeria

As part of signing on a provider, you always have to go through their own onboarding process which can be onerous because you are onboarding a business, that you do not own (so you need to collaborate with multiple internal teams).

The requirements to onboard a business depend on jurisdiction and the compliance requirements applicable there but oftentimes, the KYB processes are similar:

  • fill out an application form (paper-based or through an app),
  • negotiate and review SLAs (contains the responsibilities of each party, fees, resolution timelines and other terms),
  • share company docs (incorporation certificate, MEMART)
  • share regulatory license (where applicable)
  • provide shareholding structure in the entity that’s applying to work with the provider
  • provide KYC on UBOs and Directors (acceptable ID & proof of address),
  • a signed board resolution letter authorising you to open an account on behalf of the company, etc.

As you can see above, the Product Partnerships role requires collaboration with Legal & Compliance (to share the company docs etc.), the office of the CEO (to help you get them to sign documents) and the engineering team (to implement the APIs).

Shortly after our product went live. We got pitched by another payment provider offering us better fees than the Paystack I’d initially signed. Guess who? It was Opera (OPay) through Ridwan Olalere (who is now the CEO of LemFi) but was the Director of payment products.

💼
Interestingly, Anthony's time at Opera coincided with my time at Eyowo (early 2018).

Tying it all together, Ridwan pitching Opay to us was him acting in the capacity of a Business Development Manager. His being redirected to speak with me, was because I was the Product Partnerships Manager — a door for evaluating potential provider relationships for your company.

Later on, for additional redundancy, we also signed up Interswitch for their Payment Gateway (IPG). Often, each of the different providers has their strengths (USP) and with enough bandwidth on the engineering team — you can integrate multiple for fallbacks while monitoring metrics to determine how to route.

Part of our review of transactional data helps us see that most of the card funding transactions were from GTB users (known to be tech-savvy, youthful and experimental). So, what did we do? We went to GTB to ask for on-us APIs to process their card transactions on our platforms. Thereby effectively dropping the cost of GTB card funding transactions and ultimately reducing our transaction processing cost.

In summary, product partnership roles are not sales roles. They are product-related roles. My preferred archetype for these roles is someone with a technical and business-related educational background, sound commercial awareness, good relationship-building and communication skills, and product thinkers who can make use of data for decision-making.

Below is a tweet that I made in excitement after figuring out how to use Google Script to save engineering time and still get work done:

Tweet by @DadaBen_

I never got to write that tutorial but you can read about why I opted to flex my programming muscles by using Google Script & Sheets to build a front end for internal data transaction monitoring.


This article was first published on Medium.