Managing Three Publisher Relationships Without Dropping the Ball

Running three publisher relationships in parallel is common for prototype-track studios, and it only works with a system. Without one, builds go to the wrong contact, feedback from one publisher leaks into another's prototype, and deadlines slip because attention fragments. The fix is separation by default and a lightweight tracking habit.

Why three is the common number

Most publishers want exclusive testing on a prototype, but they do not expect studios to stop all other work. Three active relationships is typical because it matches the cadence.

One prototype is in active testing. One is in revision based on earlier feedback. One is in early concept or pitch stage. They overlap in time but sit at different stages, which is what makes three manageable and four chaotic.

Going below two means your pipeline stalls whenever a publisher goes quiet. Going above four means at least one relationship is getting less attention than it deserves.

The system that prevents mistakes

Five components, all lightweight.

1. A shared tracker with one row per publisher. Columns: publisher name, prototype name, current stage, last contact date, next action, deadline. A spreadsheet is fine. A project board works too.
2. Separate folders per publisher. Builds, feedback, emails, and notes in distinct locations. Mixing them is how builds go to the wrong person.
3. A weekly review. Fifteen minutes to scan the tracker, follow up on anything quiet for more than a week, and confirm deadlines.
4. Named builds. Every build includes the publisher name or a unique code. "Build 47" sent to three publishers is a mistake waiting to happen. "Build-Acme-47" is not.
5. A contact log. Who said what, when. Two sentences per interaction is enough. This prevents the "did I already tell them about that change" problem.

The cost of the system is fifteen minutes a week. The cost of sending the wrong build to the wrong publisher is measured in months.

Keeping feedback separate

The most common error in parallel relationships is applying one publisher's feedback to another publisher's prototype. Their priorities are different, their audiences are different, and their metrics bars are different.

Three rules for feedback isolation.

• Tag every note with the publisher name. Not just the file, but the note itself. When you revisit notes weeks later, you need the context attached.
• Review feedback in publisher-specific sessions. Do not read feedback from all three in one sitting and then work from memory.
• Confirm ambiguous feedback before acting. "Simplify the first level" means different things to different publishers. Ask what specifically they want changed.

When feedback from two publishers contradicts, that is normal and not a problem. Each prototype is being shaped for a different catalogue. The problem only arises if you merge the direction.

Communication cadence

Publishers expect regular updates but not constant ones. The right cadence depends on the stage.

Two communication mistakes that damage relationships.

Updating too often with nothing new. This reads as anxiety rather than professionalism. Wait until you have substance.

Going silent during a slow period. If you are stuck or delayed, say so. A publisher who hears nothing for three weeks assumes you moved on.

The safest default: if a week passes with no contact in either direction, send a one-line status update. It takes thirty seconds and it keeps the relationship alive.

Handling exclusivity windows

Some publishers request exclusivity during testing, meaning you cannot show that prototype to competitors.

This is reasonable and standard, with two conditions.

1. The window has a defined end date. Open-ended exclusivity is not exclusivity; it is ownership without a deal.
2. Exclusivity applies to the prototype, not to you. You should be free to work on different prototypes with different publishers during the same period.

If a publisher asks for studio-wide exclusivity, that is a deal negotiation, not a testing arrangement. Treat it accordingly and get terms in writing.

Track exclusivity windows in your tracker. A missed end date means you are giving free exclusivity, which is a concession without a return.

When to let a relationship go

Not every publisher relationship deserves continued investment. Three signals that it is time to move on.

• No response for a month after a submission. One follow-up is professional. Two is fine. After that, the silence is the answer.
• Feedback that keeps changing direction. If every round of feedback contradicts the last, the publisher may not know what they want, and your prototype is absorbing the cost.
• Terms that do not improve. If early conversations suggest terms that do not work for you, and the terms do not change with progress, the fit is unlikely.

Letting a relationship go does not mean burning it. A clean, polite close leaves the door open for a future prototype that fits better.

What we would do

Set up the tracker before the second relationship starts, not after the third. The cost of retrofitting is higher because you have to reconstruct contact history.

Name every build with the publisher identifier from the first submission. This one habit prevents the most damaging mistake, which is sending the wrong build.

Then run the weekly review as a fixed calendar event. Fifteen minutes is enough. The relationships that go wrong are almost always the ones you stopped paying attention to rather than the ones you handled badly.

The short version

• Three active publisher relationships is typical and manageable with a system.
• Separate folders, named builds, and a contact log prevent the most common mistakes.
• Tag feedback with the publisher name and review it in separate sessions.
• Update weekly during testing, and send a status line if a week passes with no contact.
• Exclusivity windows need a defined end date and should apply to the prototype, not the studio.
• Let a relationship go cleanly when it stops progressing.

Set up your tracker this week before the next relationship starts. If you want help structuring your publisher pipeline, reach out.