The Negotiated/Derived Boundary
The line beneath use cases where a product spec stops being negotiated with anyone outside the team and starts being derived: features from use cases, requirements from features, acceptance criteria from requirements. Most product dysfunction is a category error about which side of it something sits on.
Above the boundary, three constituencies outside the product team supply what the layer means: the market calibrates the vision, the company sets the mission and goals, and the customers define the use cases. None of that is the product team’s to unilaterally decide, and treating it as if it were is one direction of the error.
Below the boundary, nothing is negotiated with anyone outside. Features are derived from use cases. Requirements are derived from features. Acceptance criteria are derived from requirements. Treating a derived layer as negotiable is the other direction of the error, and it is the more common one: a customer dictating a feature, a stakeholder redlining a requirement that was never theirs to redline.
The boundary is not a claim about who has good ideas. Input from anywhere is welcome above and below it. It is a claim about where a decision’s authority actually sits, which is what turns a debate about a requirement into a question with a checkable answer: does it trace back to a use case that was actually agreed, or not.