.svg)
Your Product Line Is Being Built Outside PLM
Inside the spreadsheets, creative tools, presentations, and meetings where apparel teams decide what gets developed.
VibeIQ Research · Apparel Product Creation · 8-minute read
Executive Summary
By the time a product enters formal development, merchants, designers, and cross-functional teams have often already decided its role in the line, explored alternatives, reviewed multiple assortments, and added, cut, recolored, or repositioned it.
Most of this work happens across spreadsheets, presentations, creative applications, visual boards, meetings, email, and chat. Product decisions and the resulting product data end up in different places.
Product lifecycle management (PLM) remains an essential enterprise foundation. It gives organizations a structured environment for managing product information and development processes across the lifecycle. But a formal product record does not contain the full history of decisions that produced it: why the product belongs, what it replaced, which alternatives were considered, or why it changed.
Across VibeIQ's conversations with apparel, footwear, retail, and consumer-product organizations, one operating pattern recurred. Teams build a parallel operating layer around enterprise systems to perform the early, visual, collaborative work of shaping the line. Its tools are flexible and familiar; the connections between them depend heavily on people.
Teams recreate product views for meetings, transfer information between files, update the same decision in several places, and rely on individual memory to preserve what changed and why. A missed update can leave one team acting on information it does not know is obsolete. A lost rationale leaves downstream teams with an outcome they cannot fully interpret.
This report examines that space between planning and PLM. The perspective draws on VibeIQ's product-team research and the experience of CEO Brian Lindauer, who helped architect PTC's FlexPLM before founding VibeIQ. Its central findings are:
The product record begins after the decision.
Significant line planning, assortment shaping, visual exploration, and cross-functional evaluation may occur before an adopted product is ready for formal development.
The real vulnerability lies in the handoffs.
Using several tools is not inherently the problem. Risk appears when people must manually reconstruct and synchronize the product and its context every time work crosses a boundary.
A source of truth is necessary but insufficient.
Organizations also need continuity across the environments where product decisions are made, communicated, executed, and revisited.
AI can connect decisions or fragment further.
Faster generation creates limited value if images, attributes, concepts, and technical outputs become another set of disconnected artifacts.
The opportunity is to connect decisions made before, between, and around enterprise systems with the processes that execute them afterward, without replacing PLM or forcing every activity into one application.
1. What PLM is—and what this report is not arguing
PLM solves a demanding enterprise problem.
PTC, one of the major PLM providers, describes PLM as the product-information backbone for a lifecycle extending from conception through design and manufacturing to service and retirement.
PLM's formal scope is broad. Early concept and design may sit within a PLM implementation, and PLM does not inherently begin only after the assortment has been decided. Its role remains essential.
“PLM is super, super important. It’s essential. It’s a centralized, aggregated system. It does all the things it’s supposed to.”
Brian Lindauer, CEO, VibeIQ
PLM provides the structure, governance, and technical precision required to turn product ideas into manufacturable products.
Depending on the organization and implementation, it may manage product and style records, materials, bills of materials, technical specifications, costing, suppliers, workflow status, development milestones, compliance, and production readiness.
This report compares PLM's theoretical scope with the operating reality observed inside many apparel organizations.
Teams may do substantial line-level work before they are ready to create and maintain complete product records. Early possibilities change rapidly, and many will never become developed styles. Commercial and creative teams need to compare the line from several perspectives before individual products are stable enough for formal development.
The practical question
Where do apparel teams actually shape the line, and what happens to the context created there when an adopted product moves into formal development?
In practice, the working view of the line develops ahead of the enterprise record: Teams are often ahead of the product in documents and behind it in enterprise systems.
The system of record remains indispensable. The focus here is the work that precedes and surrounds it.
2. The space between planning and PLM
Most large product organizations have systems for financial planning and systems for formal product development.
Planning systems help establish the quantitative shape of the business: revenue and margin goals, category targets, inventory, volume, channel plans, and other financial expectations. PLM helps teams define, develop, source, cost, and produce the products intended to meet those expectations.
Between those environments sits a less clearly owned space.
It is where teams determine what the product line should contain.
What does the global assortment look like?
How should it vary by region, channel, customer, delivery, price point, or category?
Which concepts fulfill the merchandising strategy?
Which ideas duplicate products already in the line?
What should be added, changed, or removed before the organization commits development resources?
That space is where financial intent encounters creative possibility. It is also where an abstract seasonal strategy must become a coherent set of products.
Working definition
The product decision layer is the space in which strategy, commercial targets, creative possibilities, and cross-functional judgments become an adopted product line.
Why this layer stays fragmented
In many organizations, no single system or formal process owns this layer. Teams assemble it from Excel, PowerPoint, creative applications, visual boards, line-review meetings, and the knowledge held by individual employees.
This arrangement persists for sensible reasons. Spreadsheets make it easy to create and revise commercial structures. Creative applications let designers explore visually. Presentations help teams organize a narrative for senior review. Physical or digital boards allow people to see the line together. Meetings accommodate disagreement, ambiguity, and negotiation.
These tools are useful. The weakness lies in the connections between them: teams must reconstruct the product and its surrounding decisions whenever work moves from one environment to another.
3. Inside the workflow: concept through PLM handoff
To understand why the product decision layer exists, it is useful to follow an assortment from seasonal intent to formal development.
What happens before a product reaches PLM
Nine stages where teams shape the line, make product decisions, and prepare adopted concepts for formal development.
01 — Strategy
Sets the season’s commercial and creative direction.
02 — Line Plan
Translates strategy into product, price, volume and delivery targets.
03 — Design
Develops silhouettes, materials, colors and product concepts.
04 — Visual Review
Brings the line together visually for cross-functional evaluation.
05 — Adds & Drops
Products are added, removed, revised or repositioned.
06 — Regional Edits
The global line is tailored for regions, channels and customers.
07 — Reconciliation
Teams synchronize changing data, imagery and assortment views.
08 — Adoption
Final products, colorways and assortments are approved to advance.
09 — PLM Handoff
Adopted products enter PLM for sourcing, costing and production.
The transition
Before formal development, the organization is primarily deciding what should exist and what belongs in the line. Inside formal development, it increasingly determines how an adopted product will be specified, sourced, costed, tested, and produced.
Much of the reasoning behind adoption was created elsewhere. PLM receives the product record, while the alternatives, trade-offs, disagreements, adds, drops, and commercial rationale may remain distributed across the parallel operating layer.
4. Why teams wait to enter information into enterprise systems
Delayed entry into enterprise systems is often treated as a compliance or adoption problem. In early product creation, it may instead be a rational response to the nature of the work.
Early concepts are incomplete. They change often. Many will never be developed. Teams do not want to create and maintain structured product records for every possibility while also updating the working documents in which the line is actively changing.
Observed pattern
Enterprise-system procrastination: when teams delay entering evolving product information into formal systems because doing so creates another representation of the product that must also be maintained.
The underlying problem is duplication
When a possibility exists in both the active working environment and the formal system, someone must keep the two representations aligned.
This helps explain why the product record can lag behind the product decision. Forcing earlier entry without changing the surrounding workflow may simply move the reconciliation burden rather than remove it.
The apparent data-discipline problem may actually be a workflow-design problem: teams defer structure because the product is still being decided.
5. The parallel operating layer in product-team conversations
We analyzed recent customer and prospect conversations across apparel, footwear, retail, and consumer products. The research is qualitative, but the same operating patterns surfaced repeatedly. Four stood out.
Decisions live in spreadsheets
Teams described using spreadsheets for line plans, assortments, range plans, tech packs, product attributes, commercial targets, data analysis, and final buying decisions.
One organization managed visual line planning in Excel while maintaining a second visual representation elsewhere. Updates had to be made in both places without a direct connection between them. Another built merchandising line plans in Excel, sent products through PLM development, and then downloaded finalized information back into Excel for planning. A third described an assortment process requiring four different programs merely to understand what was entering the line.
Spreadsheets remain central because they are flexible. But they often become a system of decision without the connected governance and propagation expected of a system of record.
“The decision-making is all happening in spreadsheets.”
Merchandising leader at a consumer-products organization
Product views are reconstructed for review
Several teams described exporting images or product information and rebuilding presentation materials for line, business-case, selling, or sample reviews.
In one sample-review process, development teams took images and data from PLM, created PowerPoint decks, and manually recorded notes during meetings. Another team translated data from its product environment into PowerPoint to create consistent product slides. Elsewhere, business-case updates remained split across Excel files and presentations, leaving teams scrambling to gather information for checkpoint meetings.
The reconstruction separates the review from its underlying information. The deck is correct when it is assembled, but it begins aging as soon as the source changes.
Creative and commercial work evolve in different environments
Design teams continue to work in Illustrator, Photoshop, Miro, Figma, 3D tools, and other specialist applications. Merchandising and planning teams frequently operate in spreadsheets, planning tools, or line plans. Formal product data may live in PLM.
Creative and commercial disciplines need different interactions. The weakness appears when a change made by one function does not reach the other. Commercial placeholders and creative concepts can evolve in parallel until somebody manually brings them together.
One organization reported that designers rejected using a formal system for ideation and built a separate engine. Another observed that merchandising received clear workflow benefits from a platform while designers performing additional data entry did not experience the same reward.
Adoption cannot be solved by requiring every function to work identically. A shared product process must connect different ways of working.
People become the integration layer
Across the source material, teams manually exported, uploaded, copied, pasted, rekeyed, reformatted, reconciled, and communicated changes between systems.
One organization said uploading product data from Excel into PLM could take days. Another described manually entering data one size at a time into a legacy environment. Another exported a full dataset and deleted duplicates because it could not obtain the specific view it required.
A product leader summarized the broader pattern:
“We do something in one place and then have to manually hand it off to someone else to do the next step, rather than having a fully immersive conversation throughout the entire process.”
Product leader at an apparel company
The team does the product work while also preserving the connections between the tools used to perform it.
6. The handoff is where information becomes risk
Productivity is the most common business case for connecting fragmented work: fewer hours spent transferring data, rebuilding decks, and checking files. The consequences also reach product decisions.
The evidence suggests four forms of risk.
01
Time loss
Rebuilding decks, extracts, line plans, and upload files.
02
Data-integrity risk
Different versions of the same product diverge.
03
Decision latency
Teams wait for information to be verified before acting.
04
Context loss
The outcome survives, but its rationale does not.
When product information changes but the change does not propagate, organizations make decisions using information they do not know is wrong.
7. Product data is not product context
Formal product data is indispensable. It allows the organization to define and develop a product consistently. But it does not necessarily explain the decisions that made that product part of the line.
The product record
Product data
The decision context
Product context
Why the distinction matters
A product record can show that a color changed. Context explains whether the change addressed a regional request, a sourcing constraint, duplication in the assortment, or a change in seasonal direction.
A record can show that a product was dropped. Context explains whether the cause was minimum-order quantity, material availability, margin, timing, consumer relevance, or a judgment that the line already contained a stronger alternative.
The distinction matters when decisions travel between functions. Technical development may inherit an adopted product without seeing the commercial debate that shaped it. A future merchant may see what survived without seeing the alternatives that were considered. An AI system may read every field in the product record without understanding what the organization is trying to achieve.
A product record tells the organization what it is developing. Product context explains why that product belongs in the line.
The decision layer is where much of this context is created. Connecting it to the product record gives downstream teams more than current data; it gives them continuity.
8. Why one source of truth is not quite enough
“A single source of truth” is a familiar objective in transformation programs, and organizations do need trusted, governed product information.
But the phrase can conflate two different requirements
A trusted source for the current product record
A shared environment for making and understanding product decisions
Centralizing the record does not automatically centralize decision-making.
System of record does not equal system of decision.
The objective is continuity, not another monolith
Organizations do not need another monolithic system. No single system will contain all the information about the product line, sales history, creative work, and development process.
Different systems and specialist tools will continue to perform different jobs. The objective is continuity across them.
A practical continuity test
Can the organization move from seasonal strategy to line architecture, concept, assortment, adoption, and development without repeatedly reconstructing the product, its status, and its history?
Can a product change in PLM remain visible in the collaborative view used for review?
Can an adopted concept and relevant context move downstream without re-entry?
The goal is to stop rebuilding the product every time work crosses an application boundary, while allowing each function to use the applications suited to its work.
9. AI could connect the decision layer, or fragment it further
Generative AI is increasing the speed and volume of early product creation. Teams can explore concepts, imagery, colorways, attributes, copy, and even preliminary technical materials faster than before. But faster generation alone does not create a faster or better product process.
AI can accelerate an activity while creating another handoff
We are observing early signs of a new fragmentation pattern:
In each case, AI accelerated one activity but created or preserved a handoff around it. Its value in product creation depends on whether it helps the organization make a better line-level decision, not simply on how much material it can produce.
What product AI needs to understand
An AI system evaluating a concept should ideally understand more than the product record itself.
Without that context, AI can create more ideas for teams to sort, reconcile, and manually connect.
Product AI needs product context, not only product data.
Product AI should bring possibilities into the decision layer, evaluate them against the line, preserve the reasoning behind choices, and carry approved outputs into the systems responsible for development. Otherwise, it becomes another disconnected creative island.
10. What a connected product decision layer should do
A connected decision layer gives the organization continuity across specialist environments rather than trying to replace them.
01
Shape the line before formal development
Make possibilities visible before formal development. Teams need to compare incomplete ideas without treating each one as an adopted product, while keeping concepts related to the commercial need or line-plan placeholder they may fulfill.
Connect creative and commercial context. Product imagery should sit alongside assortment role, category target, price, margin, consumer, region, channel, delivery, and other relevant constraints.
Manage the line as well as individual products. Teams need to see whether a new product fills a gap, creates duplication, unbalances a delivery, or pushes the assortment beyond a category target.
02
Maintain continuity as decisions move
Support multiple views of one product universe. Global, regional, channel, customer, delivery, category, price, and color views should remain connected to common product identities.
Preserve decisions and rationale. The organization should be able to see what changed, who decided, which alternatives were considered, and why a product was added, dropped, reinstated, or modified.
Keep reviews connected to current information. Teams should be able to evaluate the current line and record decisions without rebuilding a deck before every meeting.
Carry adopted products into PLM, with development updates flowing back. Approved information and relevant context should move into PLM without repetitive entry, while later development changes remain visible in collaborative product views.
03
Close the loop
Return downstream learning to the next line. Adoption, sales, sell-through, markdown, returns, and consumer response should reach the people shaping future assortments.
Connect AI outputs to the product and its context. Generated concepts and attributes should remain tied to product identity and downstream workflows.
The objective is a better system of connection, not a larger system of record.
11. An executive diagnostic: Where is your decision layer?
Transformation begins by making the current decision layer visible. Leaders can start with the following questions.
Strategy and line architecture
Where does seasonal strategy become a product-level line architecture?
Can teams connect category, revenue, margin, price, delivery, and newness targets to visual product concepts?
Product visibility
Where does the first complete visual view of the proposed line exist?
Can teams examine the same product universe by region, channel, customer, delivery, category, price point, and color?
Reviews and decisions
What must be exported, reformatted, or rebuilt before a line, milestone, selling, or sample review?
Can the organization see why a product was added, dropped, changed, or reinstated?
Handoffs and integrity
How many places must be updated when a product changes?
Which transfers depend on copying, pasting, rekeying, uploading, or emailing?
PLM transition
When does a product first enter PLM?
Which information and rationale travel with the product record?
Do changes made during formal development flow back into the collaborative line view?
AI readiness
Are the organization’s AI tools connected to the line architecture and product record?
Can AI evaluate an idea in the context of the assortment, or only generate it in isolation?
Does AI eliminate a handoff or create another one?
For many organizations, the first transformation step is not replacing an enterprise system. It is identifying the decisions, files, meetings, and manual connections that currently surround it.
Conclusion: Connect what happens around PLM
PLM remains essential to modern product development. But before a product reaches formal development, an apparel organization may spend months deciding what the season needs, balancing creative and commercial priorities, evaluating the line, and choosing what should advance. Those choices determine the commercial shape of the line.
The operating problem is continuity
When those decisions live in a parallel operating layer, people must repeatedly reconstruct the connection between strategy, product imagery, assortment architecture, review outcomes, and enterprise data. The result is duplicate effort, slower decisions, lost rationale, and a risk that different teams act on different versions of the same product.
Creative teams, merchants, planners, developers, sourcing teams, and commercial leaders will continue to need specialist tools. The objective is not to replace those environments. It is to connect the decisions made across them, preserve what changed and why, support multiple views of the line, and carry adopted products and relevant context into formal development.
AI raises the stakes
The same question now applies to AI. It can generate more possibilities and accelerate individual activities, but better product decisions require more than faster output. AI must understand the line, the commercial and creative constraints around it, and the decisions that shaped what already exists.
The product record may begin in PLM. The product decision begins much earlier.
See what a connected product decision layer looks like
Bring us one of the workflows your teams use to shape, review, or hand off the line. We’ll show you how VibeIQ can connect the product, decisions, and context around it without replacing the systems you already rely on.