Usable with a quick edit9 of 11 checks passed
The evidence is used correctly and the reasoning is sound; a PM would only need to add a sentence about the condition that would change the North Star to make the decision criterion fully explicit.
Output
To: CEO and Growth Lead From: Head of Product Subject: Simmer's North Star: Weekly Cooks
Recommendation
Make Weekly Cooks the North Star: the number of unique users who reach the last step of a Cook Mode recipe in a given week. It is the best single measure of the value Simmer delivers, and it predicts both of your goals.
Why Weekly Cooks
- It predicts retention. Users who cook two or more recipes a week retain at 61% at month 6. Save-only users retain at 9%, and browse-only users at 4%.
- It predicts revenue. 82% of new subscribers cooked at least three recipes in Cook Mode in their first two weeks. Cooking is what makes people pay for Simmer Plus, which unlocks the timers they use while cooking.
- It can't be inflated by passive traffic. Browse-only users make up 68% of monthly actives, so MAU mostly measures search arrivals who leave after one recipe.
Why not MRR (for the CEO)
MRR is the outcome we want, but it is a lagging indicator. A subscriber who churns in month 6 still counts in month 1. It also moves for reasons unrelated to product quality, such as pricing changes, promotions and billing. Teams can't reliably act on it week to week. Weekly Cooks is the leading indicator behind it, and it is visible within a week.
Why not MAU (for the Growth Lead)
MAU rewards reach, not value. Last year's "recipe of the day" notification lifted MAU by 6%, but uninstalls doubled and Cook Mode completions did not change. We added people who opened the app and left. That result is the clearest evidence that MAU can rise while the product gets no better. MAU stays on the dashboard, but it should not be the target.
Input metrics teams can own
- New-user cooking activation: % of new users who complete three Cook Mode recipes in their first two weeks. Owner: Onboarding. This is the subscriber signal from the data above.
- Save-to-cook conversion: % of recipes saved that are cooked within 14 days. Today, savers who never cook retain at 9%. Owner: Recipe discovery.
- Weekly planning rate: % of monthly actives who plan a week of meals, currently 7% ever. Planners retain at 54%. Owner: Meal planning.
- Search-to-first-cook rate: % of search arrivals who cook a recipe within their first visit or the following week. This turns browse-only traffic into cooks. Owner: Acquisition and SEO.
Each input maps to a step in the chain from arrival to cooking to subscription, so each team can see how its work feeds Weekly Cooks.
Guardrails against gaming
- Define a valid completion. Count only unique completions per user per recipe per day, and exclude completions that take implausibly little time, so no one can tap through to the last step to inflate the count.
- Protect the base. Uninstalls and push opt-out rates have their own thresholds. Any change that lifts Weekly Cooks while pushing these up is rejected. The notification test is the case study.
- Keep MAU and MRR as visible health checks. MAU should not fall below its current baseline, and MRR should not grow through discounts that mask churn.
- Check retention, not just activity. Track 6-month retention by cohort. If Weekly Cooks rises but retention doesn't, the metric is measuring the wrong thing.
- Don't gate cooking to hit revenue. Moving Cook Mode behind the paywall would lift MRR in the short term, but it would also cut the cooking that drives both retention and conversion.
- Test causality. The retention and subscription links are observational. We should confirm them with holdout tests, such as nudging a random group of savers toward a first cook, before we commit roadmap bets to them.
Next steps
- Baseline Weekly Cooks and the four inputs over the last 12 weeks.
- Agree the valid-completion definition with Analytics this sprint.
- Run one holdout test on save-to-cook nudges within 30 days.
- Review the metric and guardrails at the end of the quarter.
Grades and run details
Decision model 95 · LLM judge 83
Decision model checks
- passUses the supplied evidence correctly58%
- passAddresses the actual decision89%
- passRespects explicit constraints35%
- passIdentifies material uncertainty61%
- partialAvoids unsupported claims58%
- passProduces the required deliverable95%
- passAnswers both proposals with the data98%
- passMeasures value created, not captured100%
- passGets the base of every number right72%
- passBreaks it into inputs teams can move100%
- passSays how it could be gamed100%
Run
- Run
- #1
- API response time
- 14 s
- Submitted
- 8 Oct 2026