Usable with a quick edit9 of 11 checks passed
The output is well-structured and evidence-based; a PM could add a sentence about what would change the decision with a quick edit, without redoing any reasoning.
Output
To: CEO and Growth Lead Recommendation: Make Weekly Repeat Cooks our North Star.
Define it as the number of unique users who complete at least two cooking sessions in Cook Mode in a rolling seven-day period, across free and Plus. A completion currently means reaching the final step. Count separate cooking occasions, including cooking the same recipe again, but exclude duplicate events.
Why this, rather than MRR or MAU?
Simmer’s value is helping people turn recipes into meals—not simply attracting visits or collecting subscriptions. Repeat cooking is our strongest available signal that we deliver that value consistently.
The retention evidence is compelling: users who cook at least twice in a week have 61% month-six retention, versus 54% for weekly planners, 9% for savers who never cook in Cook Mode, and 4% for browse-only users. Cooking also precedes monetization: 82% of new subscribers cooked at least three recipes in their first two weeks.
Those are associations, not proof that inducing more Cook Mode completions causes retention or subscriptions. Nevertheless, repeat cooking is the best-supported hypothesis to organize around and test.
MRR remains our business outcome. Our $840,000 MRR matters, but making it the product North Star could reward price increases or tighter paywalls without improving customer value.
MAU remains a reach metric. With 68% of monthly actives browsing only, it mixes meaningful use with fleeting visits. Last year’s push test illustrates the danger: MAU rose 6%, uninstalls doubled, and cooking completions did not change.
Weekly Repeat Cooks combines breadth with repeated value. Counting people rather than total completions also prevents a small group of power users from masking weak adoption.
Three input metrics teams can own
| Owner | Input metric | What it encourages |
|---|---|---|
| Discovery and activation | First-cook activation: percentage of new users completing a first Cook Mode session within seven days | Attracting people with cooking intent and helping browsers or savers make their first meal |
| Core cooking experience | Second-cook conversion: percentage of first-time completers completing another session within the following six days | A successful first experience and an easy path to cooking again |
| Retention and planning | Repeat-cook retention: percentage of a week’s Repeat Cooks who also qualify four weeks later | Durable routines through useful recommendations, saved recipes, and meal planning—not reminders alone |
Report cohort sizes alongside these rates so improvements cannot hide shrinking reach. Meal planning should be a means to repeat cooking, not a forced behavior: only 7% of monthly actives have ever tried it.
Guardrails against gaming
- Protect measurement integrity. Reaching the last step is a proxy for cooking, not proof. Deduplicate sessions, flag implausibly rapid or automated completions, and audit the proxy through sampled “Did you cook this?” feedback. Never reward shortening recipes, auto-advancing steps, or making completion obligatory.
- Protect user experience. Monitor uninstalls, notification opt-outs, and cooking satisfaction. Set experiment stop thresholds before launch; do not repeat the push test’s trade-off.
- Protect business health and access. Track MRR, paid conversion, subscriber churn, and refunds alongside the North Star. Segment results by free versus Plus and acquisition channel so paywall changes or traffic shifts cannot masquerade as better product value.
- Require sustained impact. Validate changes with controlled experiments and follow-up retention—not just a launch-week lift.
First, establish the North Star’s baseline; the supplied MAU and subscriber totals cannot tell us how many Weekly Repeat Cooks we have. Then set a target grounded in cohort performance.
Grades and run details
Decision model 95 · LLM judge 83
Decision model checks
- passUses the supplied evidence correctly64%
- passAddresses the actual decision58%
- passRespects explicit constraints59%
- partialIdentifies material uncertainty48%
- passAvoids unsupported claims68%
- passProduces the required deliverable80%
- passAnswers both proposals with the data76%
- passMeasures value created, not captured100%
- passGets the base of every number right76%
- passBreaks it into inputs teams can move100%
- passSays how it could be gamed100%
Run
- Run
- #1
- Time to output
- 38 s
- Submitted
- 5 Oct 2026