# 04A Defining the First Useful Version

Before I ask someone to build a feature, I need to describe the result that I want a user to achieve.
For a content tool, the goal might be to find relevant posts, prepare a reply, and choose a suitable publishing time.
These activities form the core workflow, and every additional requirement should have a clear connection to that practical goal.
I would like the first version to support account connections and scheduling, but I do not need advanced reports immediately.
The difference between a necessary function and an interesting extra becomes important when time and attention are limited.
I write the requirements as observable actions so that another person can tell when the work is complete.
For example, a user should be able to select a date and save a post without publishing it immediately.
We must also explain the limits, including which accounts are supported and what happens when an external service is unavailable.
Clear limits make the first version easier to review and reduce the chance of different people imagining different products.
I can always expand the scope later, after the basic workflow has proved useful in real situations and ordinary daily tasks.
A clear example makes those boundaries easier for everyone to understand.