Forget about use cases, user stories, 100 pages long product requirements. List your wants first.
“I want more candidates from my recruiting campaigns.”
“I want to know which city can get me the most candidates at the lowest acquisition cost.”
“I want to know when a city is too expensive -compared to others- to move to the next city.”
An innovative ad tool starts with a specific pain, usually as a question: “can I get more candidates with the same budget?”
This is pain coming from an unfulfilled need, which in these high-tech days, a need is the same as a want.
Once you’ve identified your wants (or your company wants as a matter of fact), you can now begin the process of writing down the rules. The “how” you will fulfill those wants. After all, a system is a set of rules.
Following our example above: “Get the spend, candidates, and CPA per city across all the campaigns. Find the city with most candidates. Find the city with the lowest CPA. Look at the past 5 days, if a city is reaching the max CPA threshold, remove it from the audience, and add the next less expensive city in the list.”
This form of requirements is very specific, precise, to the point, which makes our lives as programmers much more easy.