In the world of coding, APIs (Application Programming Interfaces) are simple, agreed-upon protocols that software components use to communicate. Almost all apps we use daily have hundreds (if not thousands) of these components. Without such APIs, building apps would be nearly impossible.
In this article, I'll be covering:
- The API metaphor
- How to know when you're doing it wrong
- How to create Team APIs
- Getting-started API examples for PMMs
- Setting the cadence
The API metaphor
The API metaphor is a powerful concept when thinking about how marketing teams and adjacent orgs need to intercommunicate. Basically, your goal is to formalize your information exchanges, frequency, and formats so that you begin to build regular bridges with other important players at your company.
It’s a great metaphor for organizing standard interactions of any kind.
As an example, think about a restaurant as three parties connected using two agreed-upon APIs:
- The waiter/customer API, and
- The waiter/kitchen API
- Gives the order to the waiter
- Gets food from the waiter
- Gets ticket from the waiter
- Gives food to the waiter
These are agreed-upon interactions. Not that there can’t be customizations, but if the basic Gives/Gets aren’t present, the system breaks down!
How to know when you’re doing it wrong…
Ask yourself: how often does your team try to interconnect by scheduling 'status' presentations? Frankly, these are usually one-way report-outs, concluding blunt needs/requests that are never fully completed.
If you’re lucky, this happens once per quarter, luckier if this happens around planning time. Or perhaps you have motivated team members who do a 1-time reach-out for data... never to be repeated again?
These types of interactions are at best inefficient, and at worst, dysfunctional. They’re unidirectional, ad-hoc, and don’t fully fulfill the interrelatedness between teams. It's as if your teams are all working independently, periodically feigning cooperation.
Alternative: How to Create “Team APIs”
My preferred approach is for PMM teams to agree on simple information “gives” and “gets” between themselves and adjacent teams – similar to designing software APIs:
- What joint goals/outcomes are the 2 teams collectively trying to achieve?
- What does team A need to provide (give) to team B?
- What does team A need to receive (get) from team B?
- At what cadence must this happen (e.g. monthly meetings)?
From here, pairs of teams can agree on what to provide, understand why the other needs it, and in what format (meeting, spreadsheet, etc.) – hopefully in pursuit of a corporate goal or OKR. The cadence can be set, and even meetings (or informal information exchanges) can be scheduled on a regular basis.
Even better – and this is a favorite of mine – when quarterly planning occurs, the teams already have cooperative/interdependent relationships and are already prepared to work together on joint goals.
Getting-started API examples for PMMs
The Team API model works for just about any group or team – but I’ve always used it with marketing teams.
Take product marketing’s API relationship with product management and outbound technical teams. These interrelationships are dependent upon joint agreement to determine technical direction, product roadmaps, feature concepts and feedback, and technical user adoption (e.g. developers).
This helps avoid one-way relationships, particularly with product management – often resulting in PMM playing catch-up when product management says it’s ready to push a new feature or release.
Rather, the PMM team should have insight into the roadmap, including providing feedback and guidance on the roadmap itself. Ideally, this API set happens monthly, if not quarterly.
Another critical relationship is when PMM works with customer-facing teams such as sales, channel, and customer success. Massive amounts of customer-centric information have to flow both ways - not just PMM delivering one-way enablement materials or battle cards.
Next, the relationship between PMM and outbound Go-to-Market teams likely already exists. Although outbound teams look to PMM for messaging and target demographics, the danger is that this is often one-way and ad-hoc.
An improved API approach for PMM is to include feedback on how well outbound is working and to cooperate on experiments and message resonance projects.
Setting the cadence
A lynchpin to making the API model work is to use it regularly! Your PMM team should work with other teams to build a regular cadence of info exchanges - particularly in advance of quarterly and annual planning.
I like setting expectations by reserving time on team calendars at least three to six months in advance, the same way you would for planning meetings.
Having your teams think “API-first” is a simple-but-effective way to ensure teams work together, and more importantly, have a structure in place to achieve cross-functional OKRs.
Perfecting your cross-functional collaboration approach
Such is the unique nature of the product marketing role, you need to hone your communication skills and build solid relationships to facilitate success.
The Cross-Functional Collaboration Certified: Masters course has been designed to give you practical tips and strategies to overcome common challenges that a product marketer faces when working with a variety of teams across a business.
Taught by Alison Hayter, Director of Product Marketing at Loopio, you'll learn how to:
📣 Articulate and establish Product Marketing’s mandate internally, the value that you bring to the table, and why you need (and deserve) to be included in strategic business conversations.
🤝 Establish win-win working relationships with your counterparts in Product, Sales, Marketing, and Customer Success.
🎯 Bring in the right people at the right times on the right projects, improving outcomes and increasing the value your business gets from Product Marketing-led initiatives.
👏 Gain the respect, buy-in, and recognition for your efforts that you deserve, from your peers and your executive leadership.
What're you waiting for?Enroll today