Tag: Capacity

Throughput against peak demand, planned in units per week rather than discovered in week three of a launch.

  • Product photography without a studio backlog

    Product photography without a studio backlog

    A studio can shoot a lot of products in a day. Almost none of them reach a product page that week. The gap is where the backlog lives, and it is mostly not photography.

    Short answer: three things create studio backlogs. Setups that are rebuilt from memory each session, so images do not match between batches. Shot lists that are agreed after the shoot, so frames are missing and products come back. And a post-production step whose main output is crops, which should not be produced at all. Fix those and throughput roughly doubles without a second studio.

    Standardise the setup, then never rebuild it

    Consistency across a product grid matters more than the quality of any single frame. A customer scrolling a category page reads inconsistency instantly and quality barely at all.

    The way to get consistency is to stop treating the setup as a creative decision each time.

    • Fix the camera position, lens, height and distance per category. Write them down with numbers, not adjectives. Mark the floor.
    • Fix the lighting. Same modifiers, same positions, same power. Photograph the setup itself and pin the photograph up.
    • Shoot a reference target at the start of every session. A grey card and a colour checker take ten seconds and make colour correction deterministic instead of subjective.
    • Keep a physical reference product. Shoot it first each session and compare against the last session’s frame. If they do not match, something moved, and you want to know before three hundred products go through.

    The gain is not only visual. A standardised setup means the crop and the framing are predictable, which means downstream processing can be automated instead of eyeballed.

    Agree the shot list before the sample arrives

    Reshoots are the most expensive failure in the pipeline because they consume a slot, a sample and a second round of everything after.

    The shot list should be a property of the category, not of the shoot. Every chair gets these seven angles. Every garment gets these five plus a detail. Written once, reused every season, and known to the person booking samples so that a product without the required angles never leaves the studio.

    Two additions make it much more useful. First, mark which frames are mandatory for each channel, so the studio knows the square-on-white is not optional if you sell on a marketplace that requires it. Second, treat the list as a manifest for ingest, so the pipeline can tell you which frames are missing rather than someone noticing later. That is the same manifest idea described in the product image workflow.

    Macro of colour checker patches under raking teal light, five reading as a consistent sequence and the sixth amber and out of sequence

    Stop making crops

    Look at what post-production actually spends its time on. A share of it is real work: cleanup, colour, background, product accuracy. The rest is producing the six or eight sizes and aspect ratios that different destinations need.

    That second part should not exist. If renditions are derived from an approved master by parameter, the studio ships one file per frame and the destinations take the shapes they need. This removes a step, removes a storage problem, and removes the whole class of bug where the product page updates and the marketplace listing keeps the old crop.

    Two mechanics make it work reliably at scale.

    Content-aware cropping. A centre crop of a wide product shot cuts the product in half. Automatic subject-aware cropping, such as gravity-based cropping, gets it right for most frames without a person choosing a focal point. Set a focal point manually for the exceptions.

    Background handling as a transformation. Cutting out a product against white is genuine post-production work, but a large share of it is now doable as a transformation on delivery rather than as a file someone produces. Treat it as a first pass to be reviewed rather than as a finished result, and keep the master untouched underneath.

    The point is not that the tooling is clever. It is that the studio’s output becomes one master per frame, which is the smallest thing it can be, and everything downstream is a parameter.

    Add capacity without adding a studio

    When the shoot slot genuinely is the bottleneck, the options are cheaper than a second studio.

    Batch by setup, not by product. Shooting every product that uses the same setup consecutively removes the rebuild time between products, which is often more than the shooting time. This can double throughput on its own and it costs nothing.

    Shoot in a fixed rhythm. A standing weekly session that always happens is more productive than an ad hoc session that gets scheduled around availability, because samples can be prepared against a known date.

    Separate the easy from the hard. Most catalogues are eighty per cent products that need seven standard frames and twenty per cent that need art direction. Running them through the same process paces everything at the speed of the hard ones. Split the flow.

    Consider a second location for the standard eighty per cent. A fixed, standardised setup can be replicated. An art-directed one cannot. This is the argument for outsourcing the simple flow rather than the complex one, which is the opposite of what usually happens.

    A three by four grid of framing templates with teal crop guides, ten centred and two amber with the subject offset and clipped

    Preserve metadata through post-production

    Every export step is an opportunity to lose the information that makes the images findable later.

    Capture software can write the SKU, the shoot date, the photographer and the campaign into the file at capture. Retouching software can strip all of it on export, and often does, depending on the export preset. IPTC photo metadata fields are the standard carrier for this, and ExifTool is how you check whether yours survived a round trip.

    Test your own pipeline once, deliberately: write known values at capture, run a file through the whole post-production path, and read them back at the end. Whatever is missing is missing for every image you have ever shipped, and the fix is usually one export preset.

    What does good throughput look like?

    Ranges rather than targets, because category matters enormously. A standardised tabletop setup with a fixed shot list will comfortably do thirty to sixty products a day with one photographer and one assistant, where a product means seven frames. Art-directed lifestyle work is a different activity and comparing them is not useful.

    What is worth comparing is your own before and after. Measure products published per week, not frames captured, because frames captured is the number that looks good while the backlog grows. The operating model that keeps that number stable across a season is in running product content as an operation, and the pre-launch version is in the catalogue launch checklist. For what the images should carry once they land in the library, see what a DAM actually does.

  • Running product content as an operation

    Running product content as an operation

    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.

    A cumulative flow chart, teal completed band rising steadily, pale in-progress band steady, amber waiting band widening sharply on the right

    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.
    Four cards in a row joined by teal arrows, the second arrow doubled in amber and looping backwards from the third card to the second

    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.

    Related field note

    Continue with A practical checklist for product photography handoffs.