Traditional PLM emerged to bring structure and control to increasingly complex product-development information. Instead of relying on multiple documents, spreadsheets, emails, and departmental systems, organizations could create a centralized product record for styles, materials, colors, bills of materials, specifications, tech packs, costing, samples, fit, suppliers, approvals, and development calendars. Traditional PLM established the product record. The opportunity now is to build greater awareness around that record.
Apparel development may be represented by a calendar, but the product itself rarely develops in a perfectly linear sequence. A fabric changes. A lab dip requires another submission. A fit decision affects construction. A supplier identifies a manufacturing constraint. A cost increase requires a material decision. Each event can change what needs to happen next. Consider two styles scheduled to reach the same milestone: one has approved materials, completed fit, confirmed costing, and no unresolved issues; the other has an outstanding material approval, another fit iteration, and a costing decision awaiting final material selection. The milestone is the same. The product state is not.
Product-centered PLM organizes development awareness around the evolving state of the product rather than relying primarily on the calendar or individual workflow activities to explain progress. The style becomes the primary unit of execution. Materials, costing, fit, quality, suppliers, approvals, activities, decisions, dependencies, and outcomes remain connected as the product develops. Instead of beginning with “What tasks are due?”, a product-centered approach can begin with “What is happening with this product?” From there, the team can determine what requires attention and what actions should follow.
Traditional PLM and Product-Centered PLM
These are two approaches to organizing product-development awareness. Traditional PLM emphasizes the product record and workflow: What information do we have? Product-centered PLM retains the fundamental capabilities expected from apparel PLM while emphasizing the evolving state of the product: What is happening with this product? It connects conditions, dependencies, decisions, activity, and status to provide structure, visibility, context, and situational awareness. This does not eliminate calendars, milestones, workflows, or deadlines. It provides better context for using them.
The Kestrel Method™
The Kestrel Method™ is built around a simple principle: Focus on the product so the calendar becomes the result. Instead of asking teams to interpret development primarily through calendar activities, the method centers awareness on the actual conditions surrounding each style. The objective is not to remove process. It is to make process more responsive to what is actually happening.
Does product-centered PLM replace the development calendar?
Is product-centered PLM a different type of software?
Why make the style the primary unit of execution?
What is situational awareness in product development?
Kestrel One™ OS was built around the evolving state of the product. Product information, development activity, decisions, context, and outcomes remain connected around each style—giving teams greater awareness of what is happening and what requires attention.
Explore Kestrel One™ OS