A software factory is a delivery organization structured around throughput rather than outcomes: 'translator' roles convert business requests into prioritized backlogs, work is funded as discrete projects, and delivery follows a fixed pipeline — prototype → story points → development → ticket marked 'done' → handoff to a separate infrastructure/ops team for deployment → team dispersal to the next project.
At Palace Hotels (~150-person tech org) this model coexisted with agile ceremonies and titles, producing Transformation Theater — the appearance of a product organization wrapped around factory mechanics. Contrast with Product Model (vs. Roadmap Model), where teams persist around a problem/customer area and are funded and measured on outcomes rather than shipped output. See also Roadmap (Feature/Project List) for the feature-list artifact this model consumes.
Palace Hotels' pre-transformation delivery pattern had a named 'translator' role whose job was to take business-dictated feature lists and prioritize them into a pipeline: prototype → story points → development → marked 'done' in Jira → handed to a separate deployment team → team disperses to the next project. Naming the translator role makes the anti-pattern easy to spot elsewhere: if there's a person or role whose job is specifically to convert business asks into a prioritized backlog for a team that won't own the resulting software afterward, that's the Software Factory Delivery Model running under an agile-shaped surface (story points, Jira) — i.e. Transformation Theater. Contrast with Team Topology by Business Vertical (Durable Ownership Teams), where the same team stays attached to the product area instead of dispersing at 'done.'
Without proper strategy and insight work upstream, an organization defaults to building exactly to stakeholder spec instead of validating the real problem — this is the waste-generating core of the software-factory pattern. The team executes faithfully, ships on time, and still produces the wrong thing, because the input was a spec rather than a validated problem. See Outcome-Based Roadmap Reframing and Stated Preference vs. Revealed Behavior.
Из тем: The Product Operating Model