Direct Messaging: Connecting the Whatnot Community

As a platform centered on interactions between sellers and buyers, one of the top features requested by our users was direct messages. Direct communications between our users were isolated to just our livestream chats which was sufficient for the duration of a livestream, but sadly all livestreams must end eventually (even Lofi Girl’s), and the only available avenues were either by going off platform or sending messages to our support team as an intermediary between buyer and seller. It became glaringly obvious that delivering on direct messages as a feature was a necessity, to both support users connecting with one another outside of the ephemeral livestream as well as being the first step in creating a community flywheel by connecting users over shared interests and topics, independent of seller initiated livestreams. Through the sheer force of will, as well as ruthless prioritization and tradeoff decisions — which we will delve into in this post — we were able to get this feature out the door in one month.

The prioritization tug of war

One of the biggest and most frequently asked questions throughout a project is: “What is the tradeoff?”

When we first started planning out this project, the task seemed simple enough (in retrospect, this was a foolish thought): Build a way to allow one user to communicate with another user directly. What did this technically mean? From the client perspective, it meant core components such as a conversation interface, message inputs, ability to upload images, and a consistent entry point (at minimum). From the backend, we needed to serve messages in real time, maintain conversations and track new conversation states, and manage notifications at least.

These requirements were just scratching the surface, and we quickly realized that while the fundamentals of direct messaging might be easy to comprehend, it would be a monster to build. Before we spiraled further in the details, we considered what we knew were the nonnegotiables we knew going into this project:

1. We don’t have the luxury of several engineers spending months on this project because we want to ensure that everyone maximizing their impact
2. We should solve the fundamental requirements of direct messaging while maintaining user safety, and thus user trust, in our platform
3. We need to provide clear solutions for the primary pain points for our users, particularly ways to hammer out logistical details or following up on order as quickly as possible

What this ultimately meant was we entered into a delicate game of tradeoffs.

Working wisely with what we have

For this project, we were able to pull together 3–4 engineers across two teams to collaborate together. With the limited resources, we narrowed our focus based on platform priorities, landing on:

1. iOS, owning the monster share of watchers
2. Web, the platform particularly friendly to sellers
3. Android, last but not certainly least, landing there mostly due to limitation of resources

In an ideal world, we would be able to launch direct messaging across all of our platforms simultaneously, but the cost in time felt too high. Instead, we decided to launch first with the top two, targeting the platforms that could have the largest impact on both our buyers and sellers, and made plans to fast follow for Android after.

Tradeoff: launching for two platforms within 6 weeks vs. building for three platforms within 12 weeks

Are the messages coming from inside the house?

Our immediate thought during the conception of this project was to use an already existing chat API out of the box and effectively cut the amount of work we would have to do to integration and customization details. However, the more we dug into it, the more we realized that doing so would both limit us in the long run — our requirements for direct messages will only increase with usage and be more specific to our user needs, such as addressing order specifics or livestream updates — as well as likely delaying the inevitable of us building in-house.

Thankfully, the decision was made clear when Simon, one of our backend developers, quickly pointed out that we could easily piggyback on our functionality for livestream chat, which was functionally direct messaging in the form of multiple users directly messaging a livestream channel. Although clients would still need to build new components in order to provide a smooth direct messaging experience, the win with livestream chats decreased complexity and engineering time significantly that made the tradeoff for in-house worth it.

Tradeoff: spending over a month to build in-house gives us full control over functionality and user experience vs spending < a month to use a chat api service out of the box with restrictions on customization

A solid foundation

Aiming for perfection is noble but unrealistic, and not to get too philosophical, but building the perfect product is not possible. We knew we wouldn’t get this exactly right in our first attempt; we knew we wouldn’t even be able to provide a majority of the features that our users would appreciate given our goal to maximize impact; what we did want to guarantee, though, was to build a simple and very safe direct messaging experience for our users as soon as possible. Anything outside of this scope we considered as non-critical iterations, such as:

• Group messaging
• Quick action follow-ups in conversations (such as one click address modification or order cancelation)
• Emoji responses + gif selections
• Order detail cards
• Message search, vanish mode, typing indicators, read receipts, threaded replies, and more

While the above features would have had some value added for our users, they were not mission critical to the act of communicating from one user to another, so they were scoped out to enable our engineers to focus fully on producing a well polished foundation.

Tradeoff: building a strong foundation for core direct messaging actions in 6 weeks vs making direct messaging more convenient with a surfeit of features in v1 and it taking numerous months

What does it mean to build a safe DM experience?

The Community and Trust & Safety team was the primary stakeholder in this project, so it was a nonnegotiable for us to maintain user safety as much as possible. Whenever a new interaction is introduced on our platform, there are always trust & safety implications: sometimes it’s minor and other times we could be introducing an entirely new abuse vector. With direct messaging, we knew it would be the latter and we couldn’t walk into that situation blind. Bad actors will always exist, but we want to ensure that the channels that they can exploit are limited. This means that we cannot allow anyone to message everyone else on the platform as they wish.

To combat abuse on a platform, there’s generally two buckets: reactive measures and proactive measures.

The big blocker

The most obvious reactive measure (and one that’s highly effective) is to allow users to block one another. With user blocking, it is:

➕ Fully in the user’s control

➖ Preventing future abuse, as the unwanted messages will have already been sent and seen

➖ Not built yet as a feature on our platform

That last con was blocking’s, well, biggest blocker, and with the intention of limiting scoping as much as possible, we considered giving users a full on opt-out option to direct messaging…truly a case of trying to get rid of a mosquito with a sledgehammer.However, we ultimately lucked out when Radek, another one of our backend developers, was able to quickly pull together user blocking purely for direct messaging.

Do we open up the floodgates?

On the flip side, we considered proactive measures to limit abuse. How do we prevent unwelcome messages from reaching our users in the first place?

In its most restrictive form, we limit direct messaging to be only between mutual followers so that:

➕ If users follow one another, there is some implied trust in place — at least in the content they have produced

➖ Sadly, neglected solving a crucial user problem which was to give buyers and sellers a way to communicate on orders between them

Ultimately, we chose to phase how we tackle this problem by first only allowing messages to be exchanged between mutual followers and if there is an existing, valid order between them, but ultimately allowed free flowing messaging between users, with the intention that bad actors will be blocked. The evolution of this will ultimately come in the form of inboxes in a future iteration, so stay tuned.

Requirements finalized

With the product requirements scoped down enough so that we could deliver on an effective MVP in a short time frame, our engineering team of 1 iOS, 1 Web, and 2 backend developers got to work. In retrospect, it’s wild to see that the direct messages feature we built in-house came out of ~one month of eng work. We wouldn’t have been able to do it without exemplifying some of our core principles at Whatnot: Move uncomfortably fast, Set audacious goals, and Prioritize impact ruthlessly to name a few. In the process, it illuminated just how complex direct messaging can be, even when it’s pared down to its core functionality requirements.

To get some insight into the technical implementation and architecture of how we built this, stay tuned! We will be following up with a part 2 that delves into those details.

What’s Next?

Delivering on this MVP really is just the first step. When we started testing the feature internally, it became exceedingly obvious that we can expand on this considerably more to help our users. Our team of four engineers could spend the rest of the year following up on the foundations that we’ve built, but in the spirit of prioritizing impact ruthlessly, we’ve shifted our focus to other crucial features to help power Whatnot, and will be returning later this year to continue iterating. Some improvements we’re eyeing are:

• Incorporating orders and quick order actions within conversations between buyers and sellers
• Different message inboxes to clearly delineate between conversations with trusted users and new message requests from unknown users
• More abilities for sellers to message their followers or livestream viewers when there’s an update or a change
• And so much more!

Building direct messages reflects a huge leap forward in terms of addressing our users’ most dominant pain points, as well as bringing us one step closer to our goal of being a user’s go-to marketplace.

Acknowledgements

A huge thank you to the cross functional tiger team we put together to complete this project: Simon Zelazny, Radek Morytko, Bartek Hyzy, Adam Sinda, Sophia Feng, and Andy Byrnes!

If you’d like to be a part of this high velocity team + journey, are interested in building impactful features, or would just like to learn more, check out some of our other engineering blog posts as well as our open roles. We’re hiring across the board, so come build with us!