This week, some guy I don’t know popped into my comments to ask me a question.

This question, to be exact...

Talk about great engagement... he’s getting an entire post!

I started writing a response, and after 15 minutes of trying to type this out on my phone and being completely unable to answer the question to an extent I was comfortable with, I finally posted this...

He mentioned a couple of vendors he’s using but you’ll have to click the link to learn who they are...(cue evil laughter on annoying redirect)

Then, a relatively new contact named Wendy Wen that’s new to the game of PartnerOps dropped me a DM to ask me about PRMs before ultimately getting to the heart of it... ’What would be your dream state?’

And now here we are. Real exciting stuff, I’m sure.

My dream state

PartnerOps is the foundation of a great Partner Experience. We’re seeing the latter concept pop up more and more these days, often tied to Program or

Enablement.

I understand the reasons for both.

Enablement seems like a natural place to rest experience guidelines — experience is at the core of designing great learning content, after all. Programs also make sense as the first-in-hire building out everything necessary to stand up the first program, and the terms therein are critical to alignment. 

Experience, however, is more than just the learning model or the Program details. Experience is found in every click of effort to drive revenue as an ecosystem. Clicks mean code, code means software, and software means...operations!

If you’re looking to build a world-class experience you’ll do it on the back of a solid operational foundation that’s driven by the mission, values, and vision of the Ecosystem.

The role of Partner Ops

The first thing to clarify is that I do, indeed, have preferred vendors. Or maybe the reality is that I have preferred people, and they happen to work for those vendors? Therein is the nature of partnerships, I suppose.

Working in Operations for any length of time, however, generally means developing a sense of agnosticism around the actual platform. Partner Operations is still a later-stage hire (Series C and later for fully dedicated roles) and thus comes into organizations carrying some amount of technical debt around existing implementations and processes.

It’s nice to have strong opinions, but at virtually every stage, we’re looking at uphill battles to get our ’preferred’ vendors in the door.

Early vs. late-stage challenges

Early-stage hires are often coming in to help stand up core architecture, build influence, and drive cross-functional alignment with what is currently in place. Tech acquisition may or may not be on the roadmap, and the name of the game is leverage — how can we use what we HAVE to drive what we NEED?

Tech acquisition is driven heavily by business needs (i.e., revenue generation activities like referral management, deal reg, marketplace/directory, etc).

Which platform gets us core functionality, and at what speed?

How much time do we have? Do they have integrations for our CRM? Do we have to do it ourselves, or do we get implementation support? What PRM is driving the need for a dedicated operational role now vs. earlier?

Later-stage hires are most definitely building from established systems and rhythms. Major projects will be looking at tech to replace legacy systems in line with higher-level OKRs. This includes a lot of compromise and technical considerations.

What systems do we have to keep? Which ones are working ’well enough’? How aligned are renewal dates? Do we have the capacity for the project? What’s our capacity for maintenance?

Wherever we enter is often behind the ball and out of position for immediately influencing any immediate significant change in technology unless that change is already on the horizon and/or driving the hiring process.

And then there’s the tech

Partner tech is in a bit of a headwind right now. The Canalys Channel Ecosystem Landscape highlights 223 companies with nearly $4 b-b-billion in revenue with an upside prediction of nearly $9 billion by 2027 (yes... four years from now).

The solutions on this map cover the gamut in terms of functionality, feature depth, and approach. There are solutions arguing to your all-in-one and your one-for-all.

There are solutions to highly specific problems and solutions offering flexibility for whatever you might dream up. Some solutions are fully-integrated and some are happy to build an integration.

All of them want your budget, and I have a hunch the vast majority are just now starting to consider how AI and LLM will impact their efforts. Hint: It’ll be significant, and many will see it too late.

Here are a few examples of how the tech itself challenges preferential treatment.

Example 1: Account Mapping

Reveal and Crossbeam are competing for Account Mapping dominance with user bases split across geos (EMEA and US, respectively). Most companies need both to work with all partners right now.

There’s still PartnerTap to consider as well though they are a bit quieter as far as I can tell. All three do basically the same thing, though Reveal has a differentiating ’nearbound’ feature that’s been a bit lost in the marketing effort, but without a strategy, you’re just adding new tech and dumping in new data and debt.

What’s your plan for the data? Who will be using it and how? Where does it need to be managed? How are you measuring success? Which vendor makes that easiest based on your current needs? It might be different for your org.

Example 2: Marketplace/Directory

Clearly needed to drive customer-facing lead gen and virtually every "PRM" will offer it. PartnerPage and Partner Fleet compete in this space (not the only ones of course) and offer slightly varied nuances on the concepts as well as feature depth.

They also might take issue with that description and are welcome to reach out and educate me here.

Questions you might ask include:

• How do integration and/or synchronization models impact your organization as a whole?
• Are you looking for both a Marketplace and a Directory?
• What about an in-app listing? Does your product team have tolerance or interest in in-app marketplace alignments?
• Do you need multiple instances to support multiple versions of the directory, say one for internal and one for external stakeholders?
• How are they managed, collectively or separately?
• How much can you impact yourself versus needing vendor or partner support?

Example 3: PRMs

If you’ve followed me for any amount of time, you know that I’ve got opinions about PRM. There’s a plethora of vendors in the market taking a variety of approaches to solving this challenge.

Understanding the platform features is one piece of this puzzle. Unraveling their approach to partnerships and ensuring it fully aligns with your own is a different question entirely.

Saying, "I love this PRM for these reasons..." is a challenge that extends from a deep understanding of your business needs, your existing technical landscape, your long-term vision, and a strong vetting process for your final selection.

Preferences, for me, are highly challenging as people in Ops know that every choice comes with caveats.

You need to make sure your core architecture is in place for how you want to manage your Partners and lean into that as a guide for the tools and systems you select to bring in.

The dream

All that in consideration, my dream state is built around ideals over specific technology solutions. I know...that feels like a cop-out after all this. Surely I could tell one, or maybe even two tech companies I really like.

I could.

But...I’m reluctant to do so.

Why?

Good question, and it probably goes back to my general agnosticism around tech. There’s definitely tech I like, brands I enjoy, and other stuff I’ve used.

For now, my dream state exists only in my mind, and what’s more important to me is how that state acts as a driver for how technology impacts partner experience.

In my dream state...

• Partner Operations is seen as the strategic harbinger of partner experience, realized in the organization of technology solutions to deliver on a defined vision for Partner Experience.
• Partner Experience is recognized as a threefold concept impacting Customers, Partners, and Colleagues. Each audience has unique experience needs that are realized through ecosystem technology plans.
• The collection of software used to build these experiences are, in essence, considered a ’product’ in and of itself, and thus treated in line with typical product standards around user experience, development, and delivery.
• As a ’product,’ we’re now looking at layered technology like we would any product: Data Layers, UI layers, Security Layers, Workflow Layers, and Engagement/Enablement Layers, all intentionally working together and influencing the org-wide selection and adoption of technology.
• In this model, the software you choose acts within these layers with a variety of other solutions, sometimes solving specific challenges, others broad, but always working together to deliver an experience in a meaningful way for each group of stakeholders.

Protip: If you really want to hear a few vendors I’m watching, check out this week’s podcast episode.

The wrap-up

Every time I sit down to tackle my article, I look back and wonder how many more weeks I could have gotten had I just broken it up a bit.

This is potentially a month-long series that I’ve crammed into a single write-up.

Then I think about how much I like to have as much information as possible about a given topic in a single place and feel okay with it.

I hope it continues to prove as useful for you, mystery, as it does for me. Until next time...

Have a great week!