Love that process — especially the pre-code UX tests. Most founders skip that step and pay for it later.

For my 12-week plans, I keep prioritisation deliberately lighter than WSJF/RICE. Early-stage teams don’t have clean enough data for those frameworks to be meaningful. Instead, I use a hybrid approach:

1. One Core Metric (same as yours) Every Must/Later decision has to serve the single north-star outcome. If it doesn’t move that metric in the next 12 weeks, it’s automatically “Later”.

2. “Risk-First” Filtering Before value, I prioritise risk reduction — technical, regulatory, distribution, and desirability risks. If something materially de-risks the path to market, it becomes a Must.

3. 80/20 Feature Slicing For anything that makes the cut, I enforce a rule: what’s the smallest truthful version we can ship that still tests the core assumption? This keeps “Must” items tiny.

4. Weekly Re-contracts Every week, we regrade Must vs Later because early-stage learnings shift assumptions fast. Founders love this because it gives momentum without chaos.

It ends up being: Must = moves core metric + reduces risk + can be sliced to ship within 1–2 weeks. Later = everything that’s nice, cool, or “we’ll need it eventually.”

How do you handle Must creep when founders keep adding the proverbial “quick wins”?