How to Get Useful Feedback From Your Publisher

Publisher feedback improves when you improve the questions. Most vague feedback ("the game needs more engagement") is a response to a vague prompt ("what do you think of the build?"). Specific questions get specific answers. Structured updates get structured responses. And disagreements handled well produce better games than agreement that avoids conflict.

Why publisher feedback is often unhelpful

Three structural reasons.

1. Publishers review many games. Your game manager may have ten to twenty titles in their portfolio. Deep feedback requires time they may not have unless you make it easy.
2. General questions get general answers. "What do you think?" invites a survey of impressions. "Is the day-one retention problem in the first session or the second?" invites a diagnosis.
3. Publishers avoid prescribing design. Many publishers deliberately stay high-level because they do not want to be held responsible for specific design decisions. This is actually respectful, but it leaves you with direction rather than instruction.

Understanding these dynamics lets you structure your communication to get the feedback you actually need.

Ask specific questions

The single most effective change is replacing open questions with specific ones.

Specific questions do three things. They demonstrate that you are thinking about the problem. They reduce the effort needed to respond. And they focus the conversation on actionable items rather than general impressions.

Prepare three to five specific questions before every publisher touchpoint. Write them down and send them in advance if the touchpoint is a call.

Structure your updates for feedback

The format of your update determines the quality of the response.

A good update has four sections.

1. What changed since last time. A short list of changes, with each one linked to the reason it was made. "Added a hint system because playtest data showed players stuck on level 4" is better than "Added a hint system."

2. Current metrics. Whatever numbers you are tracking, presented simply. Day one retention, session length, completion rates. Trend over time, not just the latest number.

3. What you are working on next. The plan for the next sprint or milestone. This gives the publisher a chance to redirect before work starts rather than after it finishes.

4. Specific questions. The three to five questions you want answered, numbered so the response can reference them directly.

Numbered questions get numbered answers. Paragraphs get paragraphs. Structure your input to get structured output.

Send the update 24 to 48 hours before a scheduled call. This gives the publisher time to review, check their own data, and prepare a response. Updates sent five minutes before a call get improvised reactions, not considered feedback.

Timing your requests

When you ask matters as much as what you ask.

After a test, not before. Feedback on a build with data attached is more useful than feedback on a build without it. If you have CPI results, retention data, or playtest findings, include them. A publisher responding to data gives different, and better, advice than a publisher guessing.

After you have tried something. "We tried shortening the tutorial and D1 went from 32% to 36%. Should we push further?" is a much better question than "Should we shorten the tutorial?" The attempt changes the conversation from speculation to analysis.

Not too often. Weekly updates are appropriate during active development. Daily updates exhaust the publisher's attention and produce diminishing returns. A publisher who sees your game name in their inbox every day starts skimming.

The submission process and timing are related to the approach in Publisher Submission Checklist.

Handling vague feedback

Sometimes you do everything right and the feedback is still vague. Three techniques for extracting specifics.

Paraphrase and confirm. "When you say the game needs more engagement, do you mean session length is too short, or that players are not returning?" Forcing a choice between two interpretations narrows the feedback.

Ask for an example. "Can you point to a game that handles this the way you are thinking?" A reference game communicates more than a paragraph of description.

Ask for priority. "We have limited time before the next milestone. If we can only address one of these, which one matters most?" This forces a ranking that reveals what the publisher actually cares about.

All three techniques are polite and professional. They signal that you are taking the feedback seriously and want to act on it correctly, which publishers appreciate.

When you disagree

Disagreements with a publisher are normal and healthy. Handling them well is a skill.

Three rules.

1. State your reasoning, not just your position. "We disagree" is a wall. "We tested this and the data showed X, which is why we went a different direction" is an argument. Arguments can be evaluated; walls cannot.

2. Propose a test. "We see it differently. Can we run both versions in the next test and let the data decide?" This removes ego from the disagreement and replaces it with a measurable outcome.

3. Know when to defer. If the publisher has more data from comparable titles, their pattern recognition may be more reliable than your instinct about your own game. Ask what they have seen in similar situations before deciding to override.

The worst response to disagreement is silent compliance. Building something you do not believe in produces a build that reflects that disbelief. If you cannot persuade the publisher, at least make sure the disagreement is recorded so both sides can learn from the outcome.

A publisher who never disagrees with you is not paying attention. A publisher who always disagrees is not a good fit. The useful range is in between.

What to do with the feedback

Feedback is only useful if it enters the production process.

After each publisher touchpoint, write a summary of three types.

• Actions. Specific changes to make, with owner and timeline.
• Inputs. Data or builds to provide for the next touchpoint.
• Open questions. Items that need more discussion or data before deciding.

Send the summary back to the publisher for confirmation. This closes the loop and prevents misunderstandings about what was agreed. A simple "Here is what we took from the call. Anything we missed?" takes thirty seconds and saves hours of misaligned work.

Track actions on your task board alongside development work. Publisher feedback that lives in an email thread and never reaches the task board is feedback that never gets implemented.

What we would do

Send structured updates with numbered questions 48 hours before every call. This single habit produces better feedback than anything else on this list.

When feedback is vague, paraphrase it as a specific question and send it back. Most publishers will clarify when given a concrete prompt. They are vague because they are busy, not because they are withholding.

After every touchpoint, send the three-part summary and track actions on the board. The feedback loop matters more than any individual piece of feedback. A team that closes loops consistently builds publisher trust, and trusted teams get more of the publisher's time and attention.

The short version

• Specific questions get specific answers. Prepare three to five before every touchpoint.
• Structure updates in four sections: changes, metrics, next steps, and questions.
• Send updates 48 hours before a call, not five minutes before.
• Extract specifics from vague feedback by paraphrasing, asking for examples, or forcing a priority.
• Handle disagreements with reasoning, proposed tests, and knowing when to defer.
• After every touchpoint, summarize actions, inputs, and open questions, then track actions on the board.

Prepare your numbered questions before the next publisher call. If you want help structuring your publisher communication, tell us about the relationship.

Related reading: Publisher Submission Checklist, How Publisher Submission Bars Differ, and Read a Publisher Term Sheet.