Two teams describe what sounds like the same product and end up with wildly different builds. Not because one was careless, but because the things that actually shape a software project are almost never the things in the feature list. The feature list is the visible part. What determines the shape of the work sits underneath it, and it is knowable in advance if you look at the right things.
The feature list is the least informative document
Ask what a system needs to do and you get nouns and verbs: a dashboard, user accounts, reporting, notifications. Every one of those can be an afternoon or a quarter, and the words give you no way to tell which.
"Reporting" is the classic. It can mean a page showing five numbers pulled straight from a table. It can also mean letting people define their own views across data that lives in four systems, with permissions deciding who sees which rows. Same word, same position on the list, entirely different pieces of engineering.
What separates them is not size. It is how much meaning the software has to hold. The five-number page holds none — it reads what is there and prints it. The self-serve version has to understand what a valid combination is, what a row means to different roles, and what should happen when two sources disagree. Meaning is the expensive thing, and it never appears on a feature list.
