A feature request arrives with the answer already inside it, so the question never gets asked. “Add a Resend button” has already decided that emails will keep failing.
“Add a Resend Email button” and “notifications must reach the recipient”. Both are things somebody wants. Only one leaves you anywhere to go.
“Add a ‘Resend Email’ button for missed notifications.” Built in a day. It works exactly as described.
“Notifications must reach the recipient.”
One names a thing to build. One states what must end up true, and lets the answer be found.
A feature request arrives with the solution already inside it. That is not a criticism of the person — naming a concrete thing is how people make themselves understood. But once ‘Resend button’ is written down, the interesting question, which is why the emails fail, has been skipped without anybody deciding to skip it.
It also expires in a way a requirement does not. ‘Download as PDF’ locks the system into PDF; ‘people must be able to take the report into their own tools’ would have given you CSV as well, and cost nothing extra to write.
Tap a line, then tap whether it names a solution. Then see exactly what each one closes off.
Pick a situation. Every one of these was built exactly as requested and satisfied nobody.
“A red alert banner for overdue tasks.” Built, shipped, and invisible to anyone who cannot distinguish red — because the word ‘red’ was in the request, not the word ‘noticeable’.
Five questions. Nothing is scored.
Five terms, not two. Tap one.
Building from feature requests means you might miss the real need behind the request. You risk locking in one approach, ignoring better options, and repeating work when needs change. Requirements keep you focused on what matters, not how to get there.
A requirement in AI design could be, 'The system must respond to queries in under two seconds.' This names a performance need, not a specific feature or interface.
Requirements should come from people who know the goals, risks, and constraints—often project managers, product owners, or compliance leads. Input from end users helps, but requirements need to capture what success looks like, not only features.
Sometimes a feature request matches a true need so closely that it becomes the requirement. Most of the time, though, a request is only one way to meet a broader need. Always check for the underlying goal.
Missing requirements leads to solutions that do not work for everyone, fail compliance, or create extra work later. Teams often have to rebuild or patch systems, costing time and trust.
Requirements can name fairness, accessibility, or compliance needs up front. By focusing on outcomes, not specific features, you make sure the solution works for more people and avoids narrow fixes that miss the real problem.
| Aspect | Constraint | Requirement |
|---|---|---|
| What it does | Limits the solution | States what must be achieved |
| Example | Must use only public data | Must answer in under two seconds |
| Who sets it | Often legal or technical | Often business or user |
| How it sounds | "No personal data" | "Support all browsers" |
A requirement leaves the door open. A feature request has already shut it, politely, before anybody looked behind it.
Copyright © Pawan Nayar · LLOS.ai · 2026 — Feature request vs Design requirement: a proposed solution, versus the thing that must be true.Original pedagogy, voice, and design — all rights reserved.