Four Challenges When Launching a Product Partnership

Four Challenges When Launching a Product Partnership

Product partnership is the coming together of two products wholly or partially. Consumer-facing companies often engage in partnerships with other companies for promotions, integrations, and marketing, among other mutually beneficial business functions. In one recent example, DoorDash partnered with Chase Bank, giving Chase cardmembers a complimentary DashPass, a perk that launched in January, 2020. 

Partnerships like these involve tremendous planning and effort from strategy and operations, product, marketing, support, and engineering teams. From a product engineering perspective, building a product as part of a partnership is different than building one internally. Product partnership collaborations have unique challenges including managing intra-team collaboration, establishing security protocols, building a testing methodology, and defining the scope.

Addressing these challenges before writing up scoping and planning documents, and committing to milestones, timelines, and launch dates, can help processes run smoothly when teams get down to work.

Managing intra-team collaboration

Communication, collaboration, and project management styles may not be identical between the two product partners. For example, some companies follow traditional or waterfall-like project management, in which software development phases are demarcated and sequenced, while others follow agile or scrum methodologies. Bringing these two development styles together can often make it difficult to adjust pace on the fly, resulting in project management challenges and delays on both sides.

There is no one way of dealing with this challenge, but knowing that this could be a challenge is a major win in itself. If there is over-communication and process on one side and most of the meetings are not adding value from an engineering perspective, try setting up tech-focused sync-ups to which only engineers and tech leads get invited. These meetings can facilitate faster resolution of technical questions and the prevention of blockers. Also, encourage regular demos and checkpoints to confirm that both parties are aligned on the progress.

Be aware that companies in certain industries may not use popular messaging and video conferencing tools for security reasons. In the initial stages of a partnership, it is important to establish which tools teams can use to communicate and collaborate. Some companies may require a set up and approval process before onboarding a tool that is taken for granted in the industry at large.

Establishing security protocols

Any partnership typically involves data exchanges between two platforms or systems. When there are two different systems talking to each other, it becomes paramount to protect each other’s data and follow agreed upon security standards.

Security standards and protocols are basic building blocks and are not meant to be changed overnight. Moreover, not all companies follow the same protocol. The starting point of any technical discussion should focus on the security standards used by each company and an agreement on which protocol to use, as the efforts involved in implementing the protocol may not be trivial. Security engineers from each company should take an early role in these discussions. 

Here are few useful questions to ask during security sync-ups:

  1. What are the authentication and information exchange protocols for the partner’s company? For instance, if one partner uses a JSON web token and the other uses an OAuth API key, then one of the partners needs to bear the overhead of adding the support to handle the other’s authentication standard.
  1. Does the data exchange take place using APIs or webhooks? In either case, the data needs to be shielded from direct access by the partner or any fiddling from the outside world. It is always a good practice to exchange data through a wrapper service, as shown in Figure 1, below:
Figure 1: Data should never be directly exposed to an external partner. Instead, a wrapper service can provide an extra layer of security.

 

  1. What is the most secure way to store the data? How will the data storage method be validated to ensure that it meets the given standards?
  2. Are there any known security pitfalls? If yes, what would it take to mitigate them?
  1. Are there any new legal standards that must be met for data storage. For example, when partnering with a company subject to the European Union’s General Data Protection Regulation, it may be necessary to comply with that legal standard.

Building a testing methodology

Any experienced engineer knows that testing does more than just check the code’s correctness. Testing involves coming up with a well-defined and thorough test plan. A test plan document covers a list of features that need to be tested, success and failure criteria, testing methods, test data, and the test environment setup.  

Testing ensures:

  1. Alignment from stakeholders on product requirements
  2. Expectations are clarified
  3. Scope creep is avoided 

Setting up a test environment between two systems in a product partnership could be a challenge, especially with pre-prod or staging environments, as these environments are typically not meant to be exposed to the outside world. In such cases, infrastructure teams need to investigate the possibility of whitelisting ingress and egress IPs. Teams will also need to mock data that looks as much like production data as possible to accurately test all scenarios and ship with high confidence to production.

User acceptance testing and load testing are also important. One of the partners might have a consumer base of millions and the other one might have a comparatively smaller user base. The partner with the smaller user base needs to have load testing in place to ensure that this integration will scale up gracefully and have enough available data center resources to handle what could suddenly be an overwhelming load.

Defining the scope 

The scope of any project mainly comprises deliverables, milestones, and timelines. We define scope by understanding stakeholder requirements, fleshing out dependencies, and creating thorough tech designs.

Scope creep, on the other hand, is an unaccounted and uncontrolled growth in a project’s scope, and is often caused by:

  1. Misalignment or inability to freeze or clarify expectations and requirements
  2. Inadequate knowledge of dependencies

Scope creep can result in delayed deliverables, delays in marketing launches, and overworked engineers.

Here are a few ways to rein in scope creep:

  1. Documentation, including product and tech specs, design docs, and meeting notes, is the source of truth for partnerships. Often, people change teams in a company even in the middle of a project. Good documentation sets the right context and background for newer folks. It is also very important to document the notes from all meetings with the partner to have the product and tech decisions, known pitfalls, follow-ups, and action items on the record.
  1. Define the minimum viable product (MVP), must haves, nice to haves, and fast follow-ups. Everyone, including engineers and internal and external stakeholders, should have a clear picture of the final product that will be launched. Every new ask and change from the partner should be triaged by product engineers so that the teams remain focused on the delivery of the MVP.
  1. Ensure timely sign-offs on the project’s progress by arranging for demos and walkthroughs between the partners. Engineers should schedule meetings to demo end-to-end integration flow for every milestone and deliverable. Meetings such as these harvest timely feedback and early detection of possible failure in flows.
  1. Know the partner’s expectations about uptime, load capacity and peak load, and other SLAs. Ideally, the design and architecture should be tailored towards the expectations about these metrics. Waiting to address these issues closer to launch might put the release date at risk.

Conclusion

For the engineers, internal projects and product partnerships share many similarities. However, working with an external partner presents unique challenges, as we highlighted above. Addressing these areas early can prevent them from becoming headaches as the partnership progresses. 

Ultimately, a successful partnership lies in understanding that each company wants to make their customers happy and satisfied with the product. At DoorDash, we take a customer first approach and it is our driving factor in delivering robust, scalable, and easy to use products.

 

Feature photo by Kaleidico on Unsplash.

Manori Thakur works as a Software engineer on DoorDash’s product engineering team. She’s been at DoorDash since October 2018, primarily working on Android applications and taking part in designing end-to-end solutions.