Partnerships on Auto-Pilot Crash
Design the Partnership Operating Model™ in Appropriate Detail
Too little detail? Partner misalignment. Too much detail? Can’t get the partnership going.
If the Partnership Model is too high-level, the partners are likely to be misaligned on how it will work (and what they will achieve). Customer-impacting surprises will emerge for the first few customers. The lead partner can’t spend too much time on a design of a partnership that is still speculative, but it also can’t come to the other partner with such a high level design that it hides the implications for each partner’s ongoing investment.
If the Partnership Model is too detailed early-on, the partners will feel over-managed and the negotiation of the partner deal will get bogged down.
The Model design must use a Whole-Product perspective to cover all the disciplines that touch the customer (and those that don’t directly, like business continuity). The lead partner should draft the Model to propose what each partner will do to sell, contract, onboard, operate, and support the joint customers.
For some disciplines, the lead partner will be able to design the proposed answer, but for others it will only be able to identify the issues to be worked with the other partner, for instance:
- The lead may be able to propose something definitive about the customer contract like “it will be on our paper”; on the other hand…
- The lead can identify that the partners will have to create an integrated approach to managing a service interruption, but won’t be able to say much more about it before engaging with the other partner.
A loosely-coupled partnership (e.g., a referral model), will yield a simpler design with less detail; whereas, a tightly-coupled model (e.g., a reselling model), will yield a more complex design.
Manage the Partnership
Partnerships on auto-pilot crash
The management of the partnership must be designed to include:
Revenue & Margin Sharing: (1) who gets what?, (2) what are the formulas?, (3) what are the triggers for earning?, (4) what data and process steps are required for reconciliation?
Partnership Relationship Management: (1) who is responsible for success for each partner?, (2) what are the measures of success?, (3) what is the regular review cycle?, (4) what is covered in a review?, (5) what is the process for partnership and client issue co-management?
Partner Enablement: (1) what knowledge must be transferred from one partner to the other?, (2) who is responsible to whom for knowledge transfer?, (3) what are the expected deliverables?, (4) how is evolving partnership knowledge co-managed?
Channel Conflict Management: (1) where are there conflicts?, (2) what market segments are covered by independent selling vs. coordinated selling vs. joint selling?, (3) how are conflicts avoided, then resolved when they arise?, (4) what are the rules for renewals and up-/cross-sells
Client Transition: (1) how is the client handled if the partnership unwinds?, (2) how is the client handled if they switch to a solution that doesn’t involve all partners?, (3) how are the costs and revenue of the transition shared among the parties?, (4) who takes what risks in the transition?
Performance Tracking: (1) what metrics are required to gauge partnership success, operational quality, and issue management?, (2) what is the process for generating those metrics?, (3) what happens when a metric indicates an issue?, (4) what executive summaries will be provided and to whom?
Key Contractual Terms: depends on the design of the Partnership Model but will typically include things like (1) service levels, (2) firm obligations in the execution of the Model, (3) commercial terms, (4) rights & responsibilities for IP, Confidentiality, Liability, (5) impact of partnership winddown on client relationships, etc.
This rounds-out our coverage of the challenges to executing a successful fintech partnership since they are easy to establish and very hard to get right. We also described the best practices to overcome those challenges.
In our next post, we’ll cover the best practice for overcoming one of the two root causes to successful growth execution: too little focus on buyer needs.
Testing from the Development team..
testing