The autumn range launches. Six weeks of long days, a shared spreadsheet, three people working evenings, and a launch that mostly holds together. Then everyone goes back to their real jobs, and in January the spring range starts and none of it is written down.
The work was not the problem. The absence of an operation was.
Short answer: product content is a repeating process with a measurable throughput, not a series of projects. Give it named roles, a definition of done per stage, a queue with a service level, and a capacity plan that accounts for peak. The gains come from removing waiting, not from working harder during the six weeks.
Four roles, whoever holds them
These are functions, not headcount. In a small team one person holds three of them, and that is fine as long as everyone knows which hat is on.
Producer. Owns the schedule and the sample flow. Knows what is arriving, what is booked, and what is late. This is the role most often unfilled, and its absence shows up as samples that arrive without a shoot slot.
Cataloguer. Owns the record. Attributes, taxonomy placement, completeness against each channel. Cares about the model and is the person who notices when a new product does not fit it.
Asset owner. Owns the library. Ingest, metadata, rights, versions, and the answer to “which one is current”.
Approver. Owns the decision, and only the decision. If the approver is also doing the work, approval is not a control, it is a formality.
The common failure is that the cataloguer and asset owner are the same overloaded person, and the queue between their two jobs is invisible because it is inside one person’s head.
A definition of done for each stage
Half of all rework in this pipeline is caused by work moving forward before it was finished, because “finished” was never written down.
Write one sentence per stage. For example: shoot is done when every frame on the shot list exists, is in focus, and is named or tagged with the SKU. Ingest is done when the assets are in the library, associated with a product, and carry creator, date and rights. Enrichment is done when the record passes the completeness rule set for every channel it is destined for. Approval is done when a named person has recorded a decision with a date.
These sentences are boring and they eliminate the most expensive class of problem, which is work that has to travel backwards. A queue that flows one way at a steady rate is fast even when each stage is slow. A queue that flows backwards is slow no matter how fast each stage is.
Measure throughput and waiting, and nothing else at first
Two numbers, tracked weekly, will tell you more than a dashboard.
Throughput. Products fully published per week. Not products touched, not assets processed. Completed.
Waiting. For products currently in flight, how long since each last moved. Sorted descending, this is your problem list, and the top ten items are usually the same three causes.
Resist adding more metrics until those two are stable. Utilisation in particular is a trap: a pipeline where everyone is a hundred per cent busy has no slack, and a queue with no slack has a waiting time that grows without bound. The team that looks slightly underloaded is often the one shipping faster.
The mechanics of finding where the waiting is concentrated are in the product image workflow, which walks through instrumenting the handoffs.
Capacity planning for a peak that happens every year
Seasonal peaks are not surprises, and the plan for them should not be overtime.
Work out the peak in units per week rather than in feelings. Six hundred products over eight weeks is seventy-five a week, against a steady-state throughput you now know. If steady state is forty, you need either double the capacity for eight weeks or a longer runway, and both of those are decisions to make in advance rather than discoveries to make in week three.
Three levers, in order of preference:
- Start earlier. The cheapest capacity is a longer window, and it usually requires only that samples arrive sooner.
- Reduce the work per unit. Removing the crop production step, standardising the shoot setup, and generating variant records instead of typing them all reduce the per-unit cost permanently rather than for one season.
- Add hands. Real capacity, real cost, and the least effective of the three if the bottleneck is approval rather than production, because adding producers to an approval-bound pipeline just lengthens the queue.
Standards, kept short enough to be read
Every operation accumulates a document nobody opens. Keep three, each on one page.
The shoot standard. Setup, lighting, angles per category, and the shot list template. This is what makes this season’s images match last season’s, which matters more on a product grid than any individual image quality.
The metadata standard. Which fields are mandatory at which stage, what the controlled vocabularies are, and who maintains them. Not the full schema, just the operating rules on top of it.
The naming and identifier standard. What the SKU means, what the asset identifier means, and the explicit rule that neither is ever reused. Reuse is the single most damaging convention violation in this domain, because it silently corrupts history.
If a standard is longer than a page it is a reference document, which is fine, but it is not the thing people follow during a launch week.
What is the smallest version of this that works?
For a team of three, running a few hundred products a season, the whole operation fits in one page and one board.
Write the four roles on it with a name against each, even if two names repeat. Write the definition of done for each stage. Put every product on a board with one column per stage and a hard limit on how many can sit in any column at once. Review the waiting list once a week for fifteen minutes and fix the top cause.
That is enough to stop each season being a rebuild. Software helps once the process exists and reliably formalises the wrong thing when it does not, which is the same warning as in the product image workflow. When a launch does come, the catalogue launch checklist is the pre-flight version of this page, the channel-facing half of the work is in syndicating product data to marketplaces, and the capacity question specific to imagery is in product photography without a studio backlog.
Two external references worth keeping near the metadata standard: the IPTC photo metadata specification for what travels inside an image file, and the Dublin Core terms as a sanity check on your own descriptive fields. Neither is a system to adopt wholesale. Both are useful for settling arguments about what a field is supposed to mean.