03 · Product · First-phase scope
In-transit is not stock. That sentence may have only one meaning
The product manager decides which document the first phase ships, to which state, and writes a single meaning for cases like transfer in-transit. Conflicting definitions are not made "configurable". After go-live, the next cut belongs to the product owner.
The product manager owns yes-or-no. What it is built as has to be written until it can be accepted
Requirements can list every rule and the project still fails, because the first phase cannot hold them. The product manager's job is to cut. He ranks by business harm, not by who speaks loudest: which document happens every day, which mistake makes stock or receivables unreadable, which gap would leave people on WeChat. Reports that do not run daily, dashboards leaders glance at, analysis that can still be exported to Excel — those stay out of phase one by default. That is not contempt for analysis. It is refusing to build screens on data that has no stable document.
He and the Product owner split at go-live. The product manager signs the first delivery's scope. After go-live the product owner ranks the next cut from real use. If one person promises both "everything in phase one" and "we'll see after go-live", scope flows back in the middle of development. The product manager also writes definitions as a single explanation. Whether transfer in-transit counts as the sending warehouse's stock, the receiving warehouse's stock, or whose stock at count — those three sentences cannot all be true.
Four sections the first-phase paper must have
First: the documents in scope and their end state. A transfer at least has to create, ship, sit in-transit, receive, and close. If receive and close cannot be done, do not tell the customer that transfer has gone live. Second: neighbouring functions that are explicitly out, such as carrier tracking while in-transit, or auto-suggested bin locations. Third: the definition. While in-transit, available quantity at the sending warehouse falls; available quantity at the receiving warehouse does not change; the books may list in-transit as its own column; a count counts only physical warehouses. Fourth: which real-structure document the acceptor walks to the end. Without the fourth, the demo uses fake data that always balances.
When definitions collide, the product manager sits finance and the warehouse together, picks one, and writes why the others were dropped. He decides a single explanation, not a list of switches. Making the conflict "configurable" is the same as not deciding. The Configuration consultant lands only the signed value. He will not invent three more switches on the floor.
Two-warehouse transfer: in-transit was added into both stocks
A chain store pulls goods from a DC. The warehouse says stock should drop the moment goods leave, or the next document can still reserve it. The store says the truck is not there, so it cannot count as their stock, or they will sell what they do not have. Finance wants to see in-transit, or month-end is short a batch. All three are right. The wrong product decision lets each role see the number they like. The right decision is one number, three views: available quantity follows the rule above and exists once; in-transit is its own column; finance, reading the books, counts in-transit into company total stock, but not into any store's sellable stock. The reason for dropping "put it into the store's available first" also goes into phase one: it would sell goods still on the truck.
After this decision is in phase one, the prototype may draw the two actions "ship" and "receive". The middle state is in-transit and cannot be skipped. Testing uses one shipped-not-received document to check three numbers: sending available down, receiving available unchanged, company books include in-transit. If any of the three is wrong, the product manager does not accept "the screens exist" as done. If development privately adds an "into available early" button, that is a scope change and it does not enter the acceptance build. After go-live, if someone wants in-transit to become configurable again, that goes to the product owner as a new use-fact, not back in as a switch by implementation.
Rule sentences are tabled by the Requirements analyst. The product manager owns whether the table is the scope he cut. Carrier tracking that is out of scope goes into the next version's candidates, not into this version's menu.