2 min lesson
What a good pick looks like
Work through the cases in "What a good pick looks like", pairing each signal with the move that fits.
Step 1 of 3
What a good pick looks likethree filters, applied fast
A pain an actual Cursor user feels weekly.
You can name the user and the moment.
Not a feature in search of a problem.
Moves a metric the team would care about.
Fits where the product is heading.
You can say why it matters in one line.
A demoable slice fits in the time box.
Reuses primitives already in the repo.
Has an obvious narrow first version.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Aim for the top-left: real, valuable pain you can demo in the time box. Effort here is your build cost against the clock.
Learn more
Full explanation
Reading a deliberately vague prompt
- 1Pick the user moment. Name a specific person doing a specific task in Cursor - reviewing a big AI diff, hunting a bug, onboarding to an unfamiliar repo. Write the moment in one sentence.
- 2Write the problem statement. One crisp line: who hurts, when and why the current product makes it annoying. This is what you'll open your presentation with.
- 3List assumptions out loud. Scope, target user, what you're explicitly not building. Putting them on paper makes your judgment legible and lets the team correct you cheaply.
- 4Define the demo. Decide the single end-to-end path you'll show before you write a line. The build exists to make that path real.
- 5Send your clarifying questions. Slack the team the way you would on the job - share your plan, ask the two questions that actually change your design, then start.
Learn more
Optional practice
Practice: What a good pick looks like
QWhy is the onsite prompt deliberately vague and what does that tell you about how to spend your first hour?