Ask for a Feature in Three Lines

Start with a sold-out product

Say you run an online shop and one product just sold out. You want a button that lets shoppers ask to be told when it returns. You could write three paragraphs of instructions. Instead, write three lines:

• As a shopper looking at a sold-out product
• When I click "Email me when it's back"
• Then the site saves my email and sends me one message the moment it returns to stock

Three lines, and you already know all three

That is the whole tool. As a [who], when [something happens], then [what should happen]. It is the same shape the pros call a user story¹ with its outcomes written as given-when-then,² minus the jargon. You know your product better than anyone, so you can fill in all three today, the same way you can describe a whole site one component at a time.

Deciding how to get it built? The free Vibe Code or Hire a Developer assessment scores your project in 8 questions and tells you whether to vibe code it, use a site builder, hire, or split the work.

"As a" names who it is for

The first line is the person. A shopper, a logged-in admin, a first-time visitor. Naming the who keeps the feature honest, because a button for customers is a different job than one for your staff, even when the two look identical on screen.

"When" is the exact moment

The middle line is the trigger: the precise moment the feature wakes up. A click, a page opening, a cart left sitting for an hour. Pin the moment and a developer knows exactly when your feature should fire, with nothing left to guess.

"Then" is what should happen, and what you can check

The last line is the result you can watch with your own eyes. An email is saved. A message goes out. A banner appears. If you cannot see it or check it, it does not belong on this line. You name the outcome; picking the machinery behind it is your agency's job.

The trick: every edge case is three more lines

Here is where it earns its keep. Each "but what if" is just another three-line block. You do not argue about them in a meeting, you write them down:

• When the same shopper clicks twice, then their email is saved once, not twice
• When the item returns to stock, then everyone waiting gets one email, once
• When the item is already in stock, then the button never appears

Leave the "how" off every line

Notice what is missing: no database tables, no "run it as a background job," no framework names. That half of the work belongs to your agency. Your three lines say what should happen; how they build it is their call to make.

Where the three lines go next

Each block becomes one item on your list, ordered the way you want in your backlog. And the "Then" line quietly doubles as your test. When a feature comes back and the outcome does not match what you wrote, you are already holding half of a clean bug report.

The whole move in one line

Name who it is for, name the moment, name what should happen. Three lines, no code, and every edge case is just three more. It is the same rule this whole series runs on: say what should happen, and leave the how to the people you hired to build it.

References