Product and Design Processes for Remote Teams

Knoop says Zapier began with a broad aim to help software tools work together as SaaS grew. The team built 50 to 60 integrations itself, then relied on partners to add more. For those early partners, Zapier offered a way to meet customer requests and improve retention, even before it could offer much distribution.

Remote work began as a practical choice: the founders could not afford an office, and the first support hire lived in Chicago. As the company grew to eight or nine people, retreats helped confirm that remote work was succeeding. Knoop says autonomy was also part of the founders’ goal: people should control their schedules and take action without waiting for permission.

Knoop says remote work makes teams clarify decision-making, communication, and processes earlier. Zapier sets expectations for when to move from Slack messages to a video call, such as when many people are typing. The company also treats a direct Slack mention as something to acknowledge within 24 hours, while expecting people who are blocked to find other useful work.

Zapier pairs product managers, designers, and engineers around shared goals, using team OKRs to focus on customer impact. Teams can choose their own working practices, while common interfaces, tools, and ownership boundaries help them coordinate. Knoop describes OKRs as a way to prioritize and discuss trade-offs, not to define every task.

Zapier uses Slack for day-to-day discussion, Async for weekly work updates and decisions, and Quip for lasting documentation. As the company grew, the volume of Slack messages and Async posts became hard to follow, so the team added curated feeds. Knoop’s advice for starting remote is to build habits of autonomy and written communication early, including sharing status so colleagues across time zones can keep moving.