Product Design: Adding Team Chat and Direct Messages Inside Notion's Workspace

Quick Overview

A product design prompt about building messaging inside Notion, the workspace for documents, wikis and project databases. It tests whether the candidate can justify why Notion needs chat, pick a segment and pain points, prioritize a first version, and define metrics and competitive risks.

Product Design: Adding Team Chat and Direct Messages Inside Notion's Workspace

Company: Notion

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

Notion is a workspace where teams write documents, build wikis and track projects in databases. As a product manager, how would you design a messaging platform for Notion? Decide who it is for, what it should do that existing chat tools do not, and what you would ship first. ```hint What gets lost Most Notion teams already keep a chat tool open beside it. Ask what goes wrong when conversations and documents live in separate places, rather than how to copy a chat app. ``` ### Clarifying Questions - Should messaging replace a team's existing chat tool, or only cover conversations about Notion content, and is it a paid add-on or part of current plans? - Which customers matter most: individuals, small teams that run everything in Notion, or large companies with strict security and retention requirements? - Should external guests, such as clients or contractors who already receive shared Notion pages, be able to take part? - Does version 1 need real-time chat with presence and calls, or is asynchronous messaging enough? ### What a Strong Answer Covers - A clear reason Notion should build messaging at all, and an honest view of competing with established chat tools. - A chosen segment and the specific pain of switching between a chat tool and Notion pages. - A design that uses Notion's own building blocks (pages, databases, mentions, permissions), such as turning a discussion into a task or decision record. - A prioritized first version with success metrics and guardrails, including notification load. - Risks such as shipping a half-finished chat product, real-time reliability, enterprise compliance, and existing integrations. ### Follow-up Questions - A large customer says it will never leave its current chat tool. How does your product still earn usage there? - How would you stop messages from burying important page updates under a flood of notifications? - How would you tell whether messaging made a team's documentation better rather than just adding another inbox?

Overview: A product design prompt about building messaging inside Notion, the workspace for documents, wikis and project databases. It tests whether the candidate can justify why Notion needs chat, pick a segment and pain points, prioritize a first version, and define metrics and competitive risks.

Notion logo
Notion
Dec 6, 2024
mediumProduct ManagerOtherProduct Design & Strategy
0
0

Notion is a workspace where teams write documents, build wikis and track projects in databases. As a product manager, how would you design a messaging platform for Notion? Decide who it is for, what it should do that existing chat tools do not, and what you would ship first.

Clarifying Questions Guidance

  • Should messaging replace a team's existing chat tool, or only cover conversations about Notion content, and is it a paid add-on or part of current plans?
  • Which customers matter most: individuals, small teams that run everything in Notion, or large companies with strict security and retention requirements?
  • Should external guests, such as clients or contractors who already receive shared Notion pages, be able to take part?
  • Does version 1 need real-time chat with presence and calls, or is asynchronous messaging enough?

What a Strong Answer Covers Guidance

  • A clear reason Notion should build messaging at all, and an honest view of competing with established chat tools.
  • A chosen segment and the specific pain of switching between a chat tool and Notion pages.
  • A design that uses Notion's own building blocks (pages, databases, mentions, permissions), such as turning a discussion into a task or decision record.
  • A prioritized first version with success metrics and guardrails, including notification load.
  • Risks such as shipping a half-finished chat product, real-time reliability, enterprise compliance, and existing integrations.

Follow-up Questions Guidance

  • A large customer says it will never leave its current chat tool. How does your product still earn usage there?
  • How would you stop messages from burying important page updates under a flood of notifications?
  • How would you tell whether messaging made a team's documentation better rather than just adding another inbox?