Usable with a quick edit8 of 10 checks passed
The memo is well-structured, data-driven, and actionable. A quick edit to label the willpower claim as a hypothesis would resolve the only unsupported statement.
Output
Memo: Shared budgets, the 1000x version
To: Ruth | From: Product | Re: Ana's shared-budgets proposal
The short version
The big opportunity isn't a "share a budget" setting. It's turning Pocketbook from a tool one person uses alone into the place a household runs its money and talks about it. Our current users already show this. People who share a budget are 14% of our users. They account for about 36% of users still with us at six months and about 45% of Premium subscribers.
| Group | Users | Retained at 6 mo | Premium |
|---|---|---|---|
| Solo | 182,000 | 17% (~30,900) | 4% (~7,300) |
| Couples | 24,600 | 58% (~14,300) | 19% (~4,700) |
| Households (3+) | 3,900 | 71% (~2,800) | 31% (~1,200) |
The 1000x version
Every household's money runs through Pocketbook: couples first, then the teenager, the parent you support, the roommates, the trip group. Each group recruits its next member at the moment money is shared. We stop selling budgeting discipline to individuals and become the shared ledger and conversation for the people you split life with. The business model becomes a household plan, not a per-person subscription.
The growth engine is the key difference. Solo budgeting apps grow one user at a time through marketing. A household product grows through its members. Each shared rent payment, holiday or new dependent is a chance to recruit someone.
The mechanism: three loops
1. The other person is the reason to open the app. Couples open Pocketbook 11 days a month, against 4 for solo users. Most of those sessions start from a notification about the partner's spending ("Alex spent $48 at the grocery store"). Solo budgeting runs on willpower, which fades. Shared budgeting runs on another person, who keeps giving you reasons to open the app.
2. The product is the money conversation. 41% of couples add a "money talk" note to a transaction in their first month. They do this even though notes were an afterthought. Couples are using us to talk about money, not just to track it. Talk is the habit that holds a household together.
3. Groups grow, and they start at shared-expense moments. 16% of couples add a third person within a year, and households retain best of all (71%). Shared budgets that start from an invite link during rent or a holiday retain best.
Today the growth loop barely works. 3% of solo users invite someone, and 22% of those invitees join. That's under 1 new member per 100 solo users. This is the biggest lever we have.
What could make this wrong
The numbers above are not proof that sharing causes retention. Couples who found today's sharing are self-selected: committed, organised, probably already engaged. The 100% invite and join rates for shared groups are true by definition, not a result.
The real question is whether a solo user nudged into sharing starts behaving like today's couples (58% retention) or stays like a solo user (17%). The plan below is built to answer that.
We also need to confirm how the 19% and 31% Premium rates are counted, per person or per budget, before designing any household pricing.
What we build first (next quarter)
Couples only. We build three things, aimed at the moments the data says matter:
- "Share this" on a transaction or bill. Rent, a trip, a big purchase each generate an invite link that opens straight into a shared budget. This targets the entry point that retains best, instead of a buried settings page.
- Partner activity notifications, on by default. Users get simple controls over what their partner sees, for example categories only or purchases over $X. Privacy is a real risk in couples' money; getting the defaults wrong will cause harm and generate support tickets.
- Notes upgraded to replies on transactions. This turns the afterthought into a lightweight conversation thread.
Not this quarter: - 3+ person households - Roommate or trip groups - Household pricing
These come only if the couples loop proves causal.
How we'll know it's working
We'll run a holdout: a random slice of solo users who don't see the new invite prompts. That lets us measure impact rather than selection.
Leading indicators (readable within the quarter):
| Metric | Today | Target |
|---|---|---|
| Solo users who invite someone | 3% | 8–10% |
| Invitees who join | 22% | 35%+ |
| New members per 100 solo users | under 1 | about 3 |
| Active days per month, new couples (first 30 days) | — | 9+ (vs 11 for today's couples) |
| New couples adding a note in month one | — | 35%+ (vs 41% today) |
Lagging indicators (we'll have early reads; full answer after the quarter): - 3-month retention of new couples against the holdout, as an early read. 6-month retention against the holdout as the verdict. - Premium conversion of new couples against the holdout.
Decision rule: We commit to the household roadmap if both of these hold: - Couples formed through the new flows retain at least twice as well as the holdout at 3 months. - They are active more than 8 days a month.
If they look like solo users, we've learned the uplift is mostly selection. In that case shared budgets stay a solid retention feature for people who already want it, not a growth strategy. That is still worth shipping, but it's a 2x, not a 1000x.
The ask: One quarter for one squad to build the three couples features and the holdout. The household decision goes on the next planning cycle, made on real evidence.
Claims the judge couldn’t find in the brief
- Solo budgeting runs on willpower, which fades.
Grades and run details
Decision model 90 · LLM judge 82
Decision model checks
- passUses the supplied evidence correctly30%
- passAddresses the actual decision94%
- passRespects explicit constraints41%
- passIdentifies material uncertainty100%
- partialAvoids unsupported claims34%
- passProduces the required deliverable88%
- passFinds the mechanism in the data100%
- passExtreme, then back to buildable100%
- partialProposes tests that could fail36%
- passThe big version gets stronger as it grows96%
Run
- Run
- #1
- Time to output
- 46 s
- Submitted
- 5 Oct 2026