The Ecosystem Playbook

When I started building Rhombus' ecosystem function, the platform had seven integrations. Today it has more than sixty-five — across identity, access control, drones, weapon detection, OEM systems, and the enterprise stacks our customers already live in. That expansion didn't just add features. It changed which deals the company was invited to in the first place.

Here's the mechanism most teams miss: an enterprise buyer doesn't evaluate your product in isolation. They evaluate it against the systems they already run. Every integration you ship is a doorway from a tool they trust into a tool they're considering. The platform with the most doorways wins the RFP shortlist before the demo even happens.

• Pipeline

  Partner-sourced and partner-influenced deals arrive pre-qualified by someone the buyer already pays. They close faster and discount less.

• Retention

  A customer who has wired your platform into their access control, identity, and alerting stack doesn't rip out four systems to leave you. Integration depth is the quietest churn reducer in enterprise software.

• Category position

  Interoperability moved Rhombus from a hardware vendor conversation into a platform conversation — and unlocked verticals like SLED and mid-market enterprise that buy ecosystems, not point products.

An integration is distribution. The platform with the most doorways wins the shortlist before the demo happens.

At Rhombus we standardized the motion early: sandbox testing environments, documented integration protocols, and certification standards that told a partner exactly what "done" meant. That structure cut engineering lift per integration and let us scale from 7 to 65+ without the wheels coming off. The pattern matters more than the tooling — and so do the failure modes. I've seen four, over and over.

• 1. The press-release integration

  Built for the announcement, not a user. No customer on either side asked for it, so usage flatlines at zero and both partners quietly stop investing. Test: name the first customer before you write the first line of code.

• 2. The API afterthought

  The integration ships, but docs, error states, and edge cases were never treated as product surface. Support debt accumulates until it eats the relationship. Your API and its documentation are products — fund them like products.

• 3. The single-champion deal

  The whole motion lives inside one person's relationship. That person changes jobs, and the integration is orphaned within two quarters. Institutionalize early: shared docs, named owners on both sides, an exec sponsor who isn't the day-to-day contact.

• 4. The unowned roadmap

  Nobody owns the integration after launch. Versions drift, the partner's API changes, and the first signal of breakage is an angry mutual customer. Every integration needs a post-launch owner and a health check on a calendar.

Name the first customer before you write the first line of code.

I've sat on both sides of this decision — running ecosystem, and before that running engineering operations at the same company. The inputs that matter are strategic adjacency (is this core to the promise customers buy from you?), support burden (who picks up the phone when it breaks?), and time-to-credibility (will customers trust your v1, or the incumbent's v10?).

• Build first-party

  When the capability is core to your customer promise and you'd be embarrassed to outsource the failure mode. Own it end to end.

• Partner

  When a category leader already owns the workflow and your customers want connection, not replacement — identity, access control, visitor management. This is most of the 65+.

• OEM

  When your capability should live inside someone else's surface, or theirs inside yours. Rhombus' OEM technology program lets the platform operate beyond our native console — embedded directly in third-party platforms — which turned interoperability itself into a growth channel.

The failure pattern is defaulting to one answer for everything: engineering-led cultures over-build, sales-led cultures over-partner. Write the decision criteria down and make every capability request walk through them in the open.

Signing a partner takes a contract and a kickoff call. An activated partner — one who sources pipeline without being chased — takes infrastructure: deal registration that doesn't punish them for bringing you business, a portal that answers questions before they ask, tiering that rewards behavior you actually want, certification that means something, and pricing frameworks nobody has to escalate. We built that backbone at Rhombus in year one, and most of it still runs the program today.

1. 01

   Recruited

   Signed agreement, completed onboarding. This is the start line, not the finish.

2. 02

   Enabled

   Certified on the product, knows the pitch, has met their channel manager. Most programs stall here and call it success.

3. 03

   First deal

   One registered, closed deal. The single biggest predictor of long-term partner productivity — engineer the fastest possible path to it.

4. 04

   Repeating

   Sources pipeline quarterly without prompting. Your QBRs shift from training to joint planning.

5. 05

   Co-investing

   Builds their own practice around your platform — marketing spend, dedicated headcount, integration depth. This tier is earned by the program, not the partner.

Recruiting 350 partners is easy. Activating 350 partners is the job.

Ecosystem work fails politically before it fails commercially. If sales believes partner-sourced means "stole my deal," and finance believes partner-influenced means "made up," the function dies in the next budget cycle regardless of how good the work was. The defense is boring discipline: define sourced versus influenced in writing, get sales leadership to co-sign the definitions, and report the same few numbers every month without exception.

• Partner-sourced pipeline

  Deals that would not exist without the partner — registered before any direct contact. The cleanest number you own; defend its definition fiercely.

• Integration-attached win rate and retention

  Compare deals and renewals where an integration is in play against those where it isn't. This is where ecosystem proves it compounds.

• Time-to-first-partner-deal

  The activation metric. If new partners take three quarters to produce, you have an enablement problem dressed up as a recruiting achievement.

Influence is real — integrations show up in deals nobody registers — but report it as a separate, clearly-labeled line. Mixing sourced and influenced in one number is how ecosystem teams lose the room.

Before going full-time on ecosystem, I spent a year and a half leading engineering operations at Rhombus while the org grew from 30 to 200+ — aligning hardware, firmware, CV/AI, and software teams, and helping stand up the AI/ML program from scratch. That seat taught me what partnership requests look like from the other side: undefined scope, no named customer, and an implicit assumption that engineering time is free.

The ecosystem teams that earn engineering's trust do three things. They arrive with a named customer and a definition of done, not a vibe. They absorb the integration work they can — sandboxes, protocol docs, partner-side debugging — so engineering's marginal cost per integration keeps falling. And they close the loop: when an integration ships, engineering hears what it did for revenue, retention, and roadmap leverage. Do that for a few quarters and 'what does good look like for the partner?' starts coming from engineering, unprompted. That culture shift is worth more than any single integration.

Engineering time is the scarcest currency in the building. Ecosystem earns trust by spending it like its own.

1. 01

   Mine your existing customers

   Find the three integrations your customers have already begged for. Support tickets, lost-deal notes, and CSM call logs are your roadmap — not the partner who emailed you first.

2. 02

   Ship one, with a named customer

   One integration, one customer committed to using it in production, one success story you can retell. Depth beats logo count for the entire first year.

3. 03

   Write the activation doc before the partnership doc

   Before signing anything, write down how a mutual customer turns it on, who supports it, and what 'working' means. If you can't write that page, don't sign.

4. 04

   Report one number monthly

   Pick one metric — partner-sourced pipeline is the usual right answer — and put it in front of the exec team every month from day one. Visibility before scale.

5. 05

   Standardize on the third repetition

   After three integrations you'll see the pattern. That's the moment to build the sandbox, the protocol doc, and the certification bar — the machine that takes you from 3 to 65.

If you're building one of these right now, I'd genuinely like to hear how it goes — the signup below reaches me, and new playbook sections ship to that list first.