Group Message History
One of WhatsApp's most-requested features and biggest onboarding challenges solved
What’s the project? Group members can send past messages to new members when they join a group, getting them up to speed and engaging in conversations faster.
Problem
User problem: New members of a group join with no context. They can't see past conversations, pinned messages or events. The burden of onboarding falls on existing members and admins who bulk forward messages, which creates noise.
Business problem & risk: Users choose WhatsApp because they know their messages are private. A feature that shares their past message to new group members they may not know, risked user trust.
Solution
Product solution: Allow group members to send message history to new members so new joiners can catch up without disruption to others. It’s surfaced in-chat with clear visual differentiation from current messages.
Content solution: Create a scalable system that protects user trust, brand privacy reputation and maintains extreme simplicity, user comprehension/transparency.
Impact
+.14% US Group Sends per DAU
Neutral privacy sentiment
Increase user orientation + group activation
My role & impact - TLDR
-
Naming
Built a multi-lens framework to pressure-test naming options
Ensured ecosystem terminology coherence
Aligned XFN on final name
-
Product framing
Protected WhatsApp’s e2e encryption promise
Neutralized user privacy sentiment
Shaped GTM in partnership with marketing
-
Legal + privacy alignment
Navigated deep legal, privacy and integrity constraints
Evaluated + aligned on high-stakes tradeoffs on trust and privacy
-
e2e content
Mitigated brand risk
Landed strategic positioning
Incorporated user transparency
Simple end user experience
Crossroad moments & how my judgement shaped our feature
Final feature
My approach to product framing
Constraints
Content needed to make clear that:
Messages remain E2E encrypted
WhatsApp never stored or accessed messages
Sending is always user-initiated and optional
Grounded in principles
I craft principles long before I start drafting. This ensures a grounded strategy that I can come back to when XFN swirl begins.
These principles were data backed, met user need and protected the WhatsApp brand.
The word choice that carried the feature.
Language - key decision.
Receiver experience - clear distinction that history was SENT and WHO it was sent by. Design showcases this with a different wallpaper to distinguish history from new messages.
When user was sent message history after joining i.e. not during the add-member flow
"Send" was chosen as the primary action verb used throughout multiple flows — it’s one word but had significant implications and impact.
Why I chose it:
It places the action with the user, not the platform. It made WhatsApp’s role feel invisible.
It activates WhatsApp's existing E2EE mental model — when you send, your device encrypts and delivers, the server never reads it.
Language that was NOT chosen and why
“Share” - Implies WhatsApp stores messages. Did not feel deliberate or aligned with the user mental model of message history.
“Forward” - I needed to set message history apart from forwarding (the current workaround) and set the precedent that it came with different constraints i.e. per message attributions were not included.
“Allow”/ “Show”/ “Can view, read” - Held the risk of it seeming like a curtain was being lifted, and messages were there AKA being stored vs WhatsApp newly collecting messages and sending them.
Naming.
Leaning on an existing mental model to build user trust.
"Message history" was chosen after a multi-stage evaluation of criteria based on ecosystem coherence, scope accuracy, privacy framing, internationalization and GTM alignment.
I worked across privacy, legal, comms and product marketing to build shared understanding of user need, potential risks and tradeoffs.
When less onboarding was the right call
One of the sharpest calls I advocated for: no NUX. No intro bottom sheet, no tooltip, no interstitial. This took convincing and alignment with leadership and Marketing.
My thinking:
A NUX would have made WhatsApp the protagonist.
Promoting a feature built on the premise that WhatsApp isn't the middleman was a contradiction.
The feature needed to feel organic. The sender finds it, evaluates it, and then decides.
Integrity pushback — key decision
Integrity initially required that we include a disclaimer in both sender and receiver experience, “History may not always be accurate or complete.” Due to complex technical reasons, this was true.
I built shared understanding
I first met with legal to more deeply understand the reason behind the request. I mocked up their request, but ultimately worked to build a shared understanding of user and product needs between the two teams.
I communicated rational against the disclaimer language from a user needs and brand protection POV.
Creates fear and distrust of the feature and WhatsApp - this was an edge case. Priming users to second-guess content that is almost always accurate was the wrong default posture.
Introduces confusion - This is an ambiguous statement. Without more context users are left asking, “what does that mean?”
Violates WhatsApp's core design principle: simplicity.
I problem solved a mitigation approach to reveal the disclaimer within a progressive disclosure approach in a ‘learn more’ link.
Settings placement, IA, & XFN alignment
The initial proposal was to nest the message history setting control inside Advanced Chat Privacy — and I pushed back. I led, in partnership with PM and PD, a campaign to allow admins control over who can share message history in their groups.
ACP is a restriction layer: screenshot controls, forwarding limits, things you switch off. Bundling message history there would have framed it as a constraint rather than a capability, which contradicted everything we were building toward. Message history belongs alongside "who can send messages" and "who can add members" — admin governance decisions that live in Group Settings, not privacy suppressors.
I aligned product, design, and privacy stakeholders around that distinction and landed the setting in Group Info, where it signals correctly: this is a feature admins can offer, not a risk they need to manage.