We must all suffer one of two things – the pain of discipline or the pain of regret & disappointment!
– Jim Rohn
Technology companies launch products/services using their own technology/IP. Occasionally, such products/services are launched based on a partnership between 2 (or more) companies. The nature of the partnership can vary – a partner relationship where both company names are visible (e.g. Powered By) or a white label relationship where only one company’s name is visible.
Partnerships are explored and established typically at C level with involvement from business development, finance, legal, product & engineering. Agreements are inked to settle details such as revenue share, IP ownership, product development, legal liability, customer support, marketing, etc. More often than not, deals are painted in broad strokes (and a generous measure of good faith) while the finer points are left for the product teams to figure out along the way.
Launching well rounded products is hard enough. Launching a product hinged on collaboration across two different companies and teams, the complexity & pain increases threefold because of the challenges involved around less transparency, less control, varied priorities, cultural differences, etc. This blog post attempts to put a framework around what it takes to develop & launch partnership based products/services while minimizing the pain along the way – a useful structure for product teams to ship a well-rounded product.
- Functionality Brief: This is arguably the most important first step. After the deal is signed, Product Heads on both ends should work together a produce a “Functionality Brief”- a 1-2 page document (or a couple of slides) that broadly lists ALL features/functionalities that the partnership intends to deliver. It’s a simple document with one bullet per product functionality. The intent of this brief document is to broadly establish the complete scope of the deliverable – not a long MRD/PRD. The brevity of this document allows the team to see the “forest” without getting lost in the “weeds” of BRDs/MRDs/requirements.
- Meeting of the Minds: While some amount of technology due diligence may have happened during the initial stages of partnership discussions, those discussions usually tend to be guarded. Now that the deal has been established, it’s time to open up the kimono and get down to brass tacks. It’s time to get the architects, subject matter experts and a couple of key engineers from both sides into a room to start whiteboard discussions on what it takes weave technologies from both ends.This sort of meeting MUST to be face to face – conference calls over Webex isn’t going to cut it. In my experience, this event works best when it happens over 2-3 contiguous days. The first day is usually spent with team members knowing each other and getting familiar with technologies on both ends. After the ice-breaker dinner & drinks together on the first night, rapport gets established & the discussions and white-boarding sessions are a lot more lucid and productive on days 2 & 3. By the end of day 2/3, product teams on both ends usually have a pretty good sense of the technology alignment and pitfalls if any.
- Proof of Concept: Depending on the nature of the project & complexity, before beginning full scale product development/integration, it might be useful to do a proof of concept project. Any toxic asbestos or technology incompatibility is best discovered sooner than later.
- Cross Functional Team, Roles & Responsibilities: Once a broad alignment of products/technologies has been established, it’s time to bring in the usual suspects to get the project going – product management, engineering, QA, project management, analysts, etc. and assign clear roles & responsibilities. While BRDs, MRDs, PRDs, requirements, design documents, specs, etc. are useful to manage the execution within each function, the Functionality Brief that was developed as a first step keeps the team on the same page with regards to overall deliverable.
- Customer Support: This item usually gets under estimated & ignored until much later. If company A has to provide support for pieces of product/technology from company B, it takes a non-trivial amount time and energy to get the customer support people trained. If the company A is a large global company with footprint in AMER/APAC/EMEA, the complexity gets further compounded. It’s best to involve the customer support team early on so that they can plan for training, documentation, escalation paths, etc.
- DL for Communication: Create an email DL (distribution list) with members on both sides of the fence – makes it easy for everybody to communicate important details across both teams. While this may seem like a trivial tactical detail, without a DL, you can be sure that some members of the team will be dropped inadvertently on important communication and that creates a different dimension of pain (confusion, transparency, trust, etc.)!
- Strong Program Manager: Given that there are 2 companies and 2 teams involved, its best to have a “stronger & savvier than usual” Program/Project manager who can deftly herd the cats while managing the scope, schedule, risks and resources.
- Executive Sponsors: As product development/integration progresses, issues occasionally come up that require escalation & decision making at higher levels. Identifying executive sponsors on both ends upfront makes it easy to resolve the issues as they come up. Pick a sponsor that has the title/authority to make decisions, bandwidth to handle issues as they crop up and a temperament to work cooperatively with an external partner to resolve conflicts.
Delivering well rounded products based on partnerships can be painful but the above framework makes for a useful pain management!