1000x an idea

To: Lena Brandt, Aisha From: Product Re: Shared lists, from one partner to the whole household

The bet

Pantry becomes the place a household runs its groceries, not a list one person keeps.

The 1000x version

People already share logins to get this today. The need is real, and the login is a workaround. At full ambition, the household is the unit. Any number of members share lists, a pantry view, and a live "what's running low" view. Members claim items ("I'm getting the milk") so nobody buys it twice. The app learns the household's routines, drafts the next list, and tracks what's in the house from what members tick off. Once Pantry holds a household's shopping state, it becomes the natural front end for delivery and reordering, and the household becomes the Plus tier.

Location is where this gets tempting: "your partner is two aisles away," or "you're near the store and the list just changed." Legal allows this only with opt-in from the person being located and from the person viewing. If we ever go there, we design that consent in from the start. It is not part of this quarter.

What the data says

• The behavior already exists without us. 11% of lists are edited from two or more devices.
• Those users are still active at month 3: 71%, against 22% for everyone else. This is correlation. Heavy households may both use the app more and share more. We need an experiment before we claim the feature drives retention.
• On those lists, 38% of items are added from the second device. Sharing is doing real work.
• Last quarter, 1,900 support tickets were about duplicate purchases. That pain is specific and measurable.
• Recipes and meal plans get 4% monthly opens. Our record on features people don't reach for is weak, so I'd treat "it needs AI" with caution.

On AI: the shared-list problem is mostly coordination. Who has claimed what, and whether "milk" and "whole milk 2L" are the same item. Rules and simple matching can handle much of that. We add a model where matching visibly fails, and only after we've seen where.

What we build this quarter

Two-person shared lists, aimed at duplicate purchases:

1. Invite one partner by link. Both accounts edit in real time.
2. Claim an item. Claimed items show who has them.
3. Duplicate warning when an item is already on the list or was ticked off in the last few days.
4. Activity feed so each person sees what changed.

Both members use it free. Putting the core behind Plus would cut off the free users who look most like our retained group, and it would test pricing rather than the product. We can test Plus separately later.

Not this quarter: location, groups larger than two, AI, delivery integration.

Team: two engineers on sync and invites, one on matching and duplicate detection, one on claims and activity, and the designer on the flow across both accounts.

How we'll know it's working

Randomize. Among eligible users on multi-device lists, half see the invite prompt and half don't. Without a holdout, we can't separate the feature's effect from the users who would have stayed anyway.

Leading indicators (weeks 2 to 6): - Both-active rate: share of invited lists where both members add or tick items within 14 days. Proposed target: 30%. - Share of items added by the second member on invited lists, compared with the 38% baseline.

Outcomes (month 3 of the cohort): - Retention lift for invited lists over the holdout. Proposed target: at least 5 points. This number is a guess until we have a holdout baseline, so we'll set it properly in week 1. - Duplicate-purchase tickets down 30% from the 1,900-per-quarter run rate.

Guardrails: - No drop in list completion or ticking for solo users. - No rise in unsubscribes or privacy complaints. - Invitee Plus conversion tracked, not targeted.

Decision rules: - If the both-active rate is under 15% after six weeks, the invite is the wrong shape. We revisit before building more. - If retention lifts but tickets don't fall, the next investment goes to matching and claims, not to new sharing features.

Recommendation

Approve the two-person build with the holdout. Keep the household vision as the direction we're testing toward, and let the week-6 numbers decide whether we earn the next step.

To: Lena Brandt, Aisha Subject: From a shared list to the system that runs household replenishment

Recommendation

Commit next quarter to testing household coordination, not merely adding a second editor. Aisha’s proposal is the smallest entry point into a much larger opportunity: Pantry becomes the trusted system that ensures a household has what it needs, without anyone having to manage every purchase.

The 1000x version

Today, Pantry remembers what someone typed. At its most ambitious, Pantry coordinates the entire replenishment cycle: noticing needs, resolving preferences, assigning responsibility, finding the right purchase, and confirming arrival.

Imagine: “Keep our household stocked within $150 a week.” Pantry learns recurring needs from explicitly connected purchase history and household corrections, drafts a replenishment plan, reconciles conflicting requests, and coordinates whoever—or whichever service—will fulfill it. Eventually, users could authorize bounded automatic purchases, with spending limits, explanations, and easy overrides.

The expansion is from one person’s checklist to a household’s purchasing agent, then a demand network connecting households to retailers and delivery providers. Core sharing could remain free; trusted automation could support Plus, with optional transaction revenue later. Recommendations must serve household preferences, not whichever retailer pays most.

AI belongs in interpreting messy requests, recognizing equivalent items, and proposing replenishment—not in deciding whether two phones agree. Synchronization must be reliable software. This is an ambition, not a forecast or next-quarter roadmap.

Why this is the right starting point

Users are already working around our product: 11% of lists are edited from multiple devices with different phone numbers. Second devices contribute 38% of items on those lists. This looks like genuine joint work, not occasional viewing.

Those users retain at month three at 71%, versus 22% for others. That is compelling but not causal: committed households may naturally retain better, and devices are not verified partners.

The clearest unmet need is operational: 1,900 duplicate-purchase tickets last quarter. Meanwhile, only 4% opened recipes or meal plans last month. We should earn the right to expand by preventing “we both bought the milk,” not by launching another planning destination.

What we build first

With four engineers and one designer, ship a narrow, free, two-person shared-list pilot:

• Separate accounts; a simple invitation, acceptance, and removal flow.
• Fast shared additions and check-offs, with clear sync status and safe recovery after disconnection.
• An explicit, visible “I’m buying this” claim, followed by “bought,” so coordination happens before checkout. Surface conflicting claims; never imply an offline claim is confirmed.
• Clear attribution and controls to leave sharing without exposing other private lists.

Test with existing login-sharing households first. Do not require location: voluntary item claims solve the immediate problem with less risk. Any future location feature requires explicit opt-in from both the person being tracked and the intended recipient, plus revocation controls.

For Lena’s AI question: time-box a prototype that flags likely duplicate entries such as “milk” and “whole milk.” Test precision with users; never silently merge. It ships only if useful and does not delay the coordination foundation. No ordering, retailer integrations, inventory prediction, or meal-planning expansion this quarter.

How we know it works

Instrument the funnel from invitation through acceptance to both people contributing and completing a shopping cycle. Weekly active collaborating households is our adoption metric—not invitations sent.

Randomize eligible initiating accounts to invitation access or control, keeping linked partners in the same experiment. Compare outcomes by assignment, not just among successful sharers.

Before launch, power the test around these proposed decision thresholds:

• At least a 20% relative reduction in self-reported duplicate purchases per shopping trip.
• A five-percentage-point improvement in day-28 retention, followed by month-three measurement.

Track sync failures, lost edits, accidental sharing, notification complaints, and Plus cancellations as guardrails. Support tickets are corroborating evidence, not the sole outcome.

Expand only if households repeatedly coordinate and randomized outcomes improve without material trust failures. If invitations succeed but duplicate buying persists, fix coordination before broadening the vision.