1 min lesson
Bucket two: one bigger bet
Rebuild the parts of "Bucket two: one bigger bet", then say why each one matters.
Step 1 of 2
Bucket two: one bigger bet
Pick one larger idea and structure it so an engineer can argue with it. State the user, the hypothesis and the measure before you describe the feature. Vague vision is a red flag; a falsifiable bet is the signal.
- User
- Who, specifically: an individual power user, a new hire onboarding, an enterprise platform team
- Hypothesis
- "If we ship X, then behavior Y changes." Falsifiable, with a prediction you could be wrong about
- Measure
- The one number that tells you it worked: activation, retention, acceptance-that-survives, daily usage
- Kill criterion
- What result would make you stop. Pre-committing to this is what makes you credible
Lead with user, hypothesis and measure. The feature description comes last.
User: an engineer in their first week on a large repo.
Hypothesis: if a starter Project Rule built from the repo's AGENTS.md is offered at first run, week-one agent answers are grounded in the team's conventions more often.
Measure: the share of new users who run a second agent session by day 7.
Kill criterion: no lift after four weeks, or the rule's added context slows replies.
This is an example of the shape, not a roadmap item. The only product facts it relies on are that Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition. and AGENTS.md exist.