Designing a Two-Sided Integration Marketplace for DocuSign

You are a product manager at DocuSign. The company wants a place where customers can discover and install apps that extend DocuSign or connect it to their other software. How would you create this marketplace: who should it serve, what should it offer at launch, and how would you tell whether it is working? ```hint Two sides, one shelf A marketplace needs developers who build apps and customers who install them. Decide which side you must win first, and think about what a customer sees on the day it opens. ``` ### Clarifying Questions - Who builds the apps: outside developers and partners, DocuSign's own teams, or both? - Is the main buyer an administrator who installs apps for a whole organization, an individual sender, or both? - Should DocuSign earn revenue from paid apps through a share of sales, or is the aim adoption and retention? - Are there existing integration partners whose apps could be listed at launch, or does the marketplace start empty? ### What a Strong Answer Covers - A goal for the marketplace tied to DocuSign's business, and a deliberate choice of which side and which segment to win first - Pain points for customers (finding, trusting and installing apps) and for developers (building, distributing and getting paid) - A launch scope built around a few high-value app categories, with security review and admin controls included from the start - A plan to avoid an empty marketplace on day one - Metrics for both sides of the marketplace, with guardrails for app quality and data security ### Follow-up Questions - An app in the marketplace leaks data from signed agreements. Which controls should already exist, and what do you do in the first day? - Would you charge developers to list, take a share of paid app sales, or keep the marketplace free? What evidence would change your mind? - How would you decide whether DocuSign should build an app itself when a partner already offers one in the same category?