XMTP Product Context
Version: 0.1.0
Abstract​
The framework introduced here follows a “stack” hierarchy in which each layer should be served by the layer below. At the very top of the hierarchy is our company mission statement. At the very bottom are the metrics we track to understand if we are making progress on that mission. In between are the decisions we make about what we’re building, why, and how, and the factors that motivate those decisions. It pivots on a core segmentation hypothesis that connects our near-term learning agenda with our long-term aspirations.
Mission > Vision > Segmentation > Strategy > Roadmap > Metrics (WIP)
Motivation​
This document seeks to establish shared context for discussing product goals at XMTP. It’s a reflection of current thinking – not an instruction manual – and as such should be continually challenged and built upon.
Since product thinking is a collaborative process, major changes to this document should not come as a surprise as they will likely have been discussed elsewhere first. Nevertheless, changes should be broadcast in order to maintain alignment and understanding.
Framework​
Mission​
We aim to make secure and private communication available to all humans as a fundamental right and public utility.
Vision​
We envision an open source, community-governed protocol and network for high-signal, encrypted messaging between verifiable but private identities.
It will be broadly adopted and made widely available by an ecosystem of applications competing and collaborating to deliver the best end-user experiences.
Segmentation​
We’re focused on web3 because we see composability, data portability, and trustless incentive mechanisms as essential to achieving our vision. We see an abundantly clear yet unmet need in the space, and we believe its primitives are here to stay.
Within this space, we serve web3 developers whose end-users…
- are active participants in web3, and use web3 identities with multiple products
- desire strong security and privacy
- need to send or receive messages using their web3 identities
We don’t currently serve developers and end-users outside of web3, or those whose use cases are satisfied using other types of identity (email, SMS, standalone accounts).
We don't currently serve end-users directly, but understanding their needs is of paramount concern for serving developers.
Core Hypothesis​
Based on many conversations with developers, we hypothesize that the strongest need for messaging between web3 identities is felt by web3 teams and communities (dapps, DAOs, projects, protocols) who have no reliable means to re-engage pseudonymous, wallet-based users or members. We often think about four user persona groupings in this context (two end-user groups, two developer groups):
End-users
- Senders, who are web3 teams (dapps, DAOs, NFT creators, and protocols) that need to re-engage users and customers using only web3 identities.
- Recipients, who are individual users that web3 teams are trying to reach, including token holders, connected addresses, subscribers, and lurkers.
Developers
- Originators, who are building marketing orchestration tools for web3 teams, e.g. “Mailchimp for web3” / “Sendgrid for web3” / “Zapier for web3”
- Destinations, who aggregate user attention and information. This includes wallets, dashboards like Zapper, and even some exchanges.
For now, we aren’t focused on serving developers or end-users whose needs are unrelated to this re-engagement hypothesis.
We also aren’t focused yet on the needs of node operators or miners as a user segment.
Strategy​
Our segmentation and core hypothesis suggest two strategic goals:
- Powering an ecosystem of web3 marketing tools that dapps, DAOs, NFT creators, and protocols use to reach, engage, and deepen relationships with their users.
- Powering a universal inbox that destinations can easily customize to highlight the messages that matter most to their users in the context of that destination.
Our strategy for differentiating from competitors ties back to our vision:
- Decentralized ownership and control. Our software is open source and permissionless (vs Blockscan Chat). Once we’ve seen signs of product-market fit, we’ll begin to decentralize the operation of the network and establish community governance over the protocol.
- Interoperability. We enable web3 developers and teams to reach users where they are (vs EPNS). Ideally any app, on any stack, can implement an XMTP-powered inbox. In the future, senders will even be able to reach users using multiple linked identities.
- Privacy, security, and self-sovereignty. Messages are end-to-end encrypted (vs Blockscan Chat), off-chain, and deniable (vs Dialect, EPNS). In the future users will be able to transfer messages to off-network storage after receipt.
- High-signal end-user experience. We enable client-side spam mitigation via composable/customizable inbox filters (vs Blockscan). In the future, we’ll establish a network-level fee market and customizable gating mechanisms that control which messages enter the network.
Roadmap​
In the medium term, our strategy is best served by a handful of tactical goals:
- Unblock developers from building tools and inboxes using XMTP
- Eliminate the most obvious causes of interaction failure
- Adhere to modern standards for end-user security and privacy
- Lay early foundations for decentralized storage, governance, and spam mitigation
Our work against these goals is tracked in our backlog.
Metrics​
(WIP) This section will discuss:
- constraints on direct data collection
- what we think we can measure
- messages
- messages per conversation
- identities on the network
- “sessions”
- (maybe) conversations with both users participating
- developers adopting
- rate of developers adopting while at hackathons
- partnering with developers to access client-level data
- “aspirational” synthetic metrics using client-level data, including:
- Total addressable wallets (originator reach)
- Conversations with replies (interaction success)
- Conversations with replies per sender
- Conversations per recipient
- Message delivery rate
- Message open rate
- ...