Usable with a quick edit9 of 10 checks passed
The 90-day target for 6-month retention creates a minor timeline inconsistency, but it is otherwise complete, evidence is correctly used, and a PM can adjust the metric timing with a quick edit.
Output
Memo: Shared Budgets, the 1000x Case and a First Build
To: Ruth From: PM, Pocketbook Re: Ana's shared-budget proposal
Recommendation
Commit next quarter to shared budgets, scoped as a household product rather than a feature. Start with the invite and the partner-activity loop, and hold the wider household roles until the couple data holds up.
The 1000x version
Today, Pocketbook is a product for one person. Shared budgets make the household the unit. The 1000x version is a household financial operating system: the place a couple, and eventually a family, runs its shared money. That covers bills, spending, savings goals, allowances for teens, and money support for a parent.
The scale argument rests on what the data already shows:
- Couples are worth far more per user. Couples retain at 58% at six months against 17% for solo users. Their premium conversion is 19% against 4%.
- Shared users are 14% of our base and about 45% of premium revenue. Our 24,600 couples and 3,900 households produce roughly $35k a month in premium revenue. Our 182,000 solo users produce about $44k.
- The invite is the bottleneck, not the product. Solo users invite at 3%, but 22% of invitees join. Most people who would share have never been asked.
If couples alone reached 1000x today's count (about 24.6M couples) and kept today's 19% conversion, that would be roughly 4.7M premium users, or about $28M a month. Conversion won't hold at that scale, so treat this as an upper bound. The point is the shape: one shared budget brings in two daily users and a higher-value subscription. Households add a third person, which the data suggests happens for 16% of couples within a year.
The mechanism
Three loops drive it.
- Notification pull. Couples open the app on 11 days a month, against 4 for solo users. Most sessions start from a message about a partner's spending ("Alex spent $48 at the grocery store"). Each shared budget creates a second daily user who is pulled back by the other person's activity.
- Conversation as the product. 41% of couples add a "money talk" note to a transaction in their first month. The note was an afterthought, but it is the behavior that most resembles what the product is for: couples discussing money inside the app. Making it a first-class feature deepens the habit.
- Expansion through real life. Couples who add a third person (a teenager, a parent they support) move from a two-person budget to a household budget. Households retain at 71% and convert at 31%. Each expansion raises value per account.
The invite is the entry point. Shared budgets started from a shared-expense moment, such as rent or a holiday, retain best. The invite should appear at the moment money is actually shared, not as a generic "invite your partner" button.
What we build first
1. An invite anchored to a shared-expense moment. When a user sets up a recurring shared bill (rent, utilities) or tags a transaction as shared, offer to bring in the partner. This targets the 3% invite rate directly.
2. Partner-activity notifications, with controls. The data says these drive sessions. Ship them with clear, per-transaction hiding and easy unsharing from day one.
3. Promote the money-talk note. Make notes on transactions a visible, first-class part of a shared budget.
Deliberately deferred: third-person and household roles, teen allowances, and parent-support flows. We should build these only once the couple version shows retention holding up.
Guardrails. A product where one partner can see the other's spending creates real risk, including financial control in abusive relationships. Before launch we need: - Opt-in visibility, with each person able to hide transactions from the other. - Unsharing that is easy and fully private, with no notice to the partner. - A separate review of defaults and copy with the trust and safety team.
How we'll know it's working
Set baselines now, and measure against cohorts rather than the current group averages.
| Metric | Baseline | 90-day target |
|---|---|---|
| Invite rate among solo users | 3% | 6% |
| Invitee join rate | 22% | 30% |
| Share of new couples started from a shared-expense moment | not tracked | 50%+ |
| Couples adding a money-talk note in month one | 41% | 50% |
| New-couple 6-month retention | 58% (cohort, not yet measured) | at or above 50% |
| Couple premium conversion | 19% | 15%+ |
Caveat on the data. The invited-someone and invitee-joined columns read 100% for the couple and household groups. That is true by definition, since these groups only exist because someone invited a partner. The real comparison is the solo invite rate (3%) against the join rate (22%). The 58% and 71% retention figures may also overstate the effect of shared budgets: couples who stay together may be the ones who stick with the app. We need a randomized holdout, with invited and non-invited users matched on tenure and activity, before we credit the product for that retention.
Kill or rethink criteria. If invites don't lift past 4% within the quarter, or if new-couple retention doesn't separate from the holdout, we stop expanding the feature and keep the notifications and notes as solo-plus-partner improvements.
Grades and run details
Decision model 80 · LLM judge 100
Decision model checks
- failUses the supplied evidence correctly53%
- passAddresses the actual decision99%
- passRespects explicit constraints31%
- passIdentifies material uncertainty100%
- partialAvoids unsupported claims45%
- passProduces the required deliverable83%
- passFinds the mechanism in the data100%
- passExtreme, then back to buildable100%
- partialProposes tests that could fail59%
- passThe big version gets stronger as it grows72%
Run
- Run
- #1
- API response time
- 20 s
- Submitted
- 8 Oct 2026