Strategy question

A combatant-command planning team asks for custom workflow support in Scale’s military planning product for part of the Joint Planning Process, but platform engineering believes it is a one-off. How would you determine whether the underlying issue is a durable product gap, an integration or data-model problem, or a local change-management issue? What evidence would you gather, who would you involve, and how would you decide whether to build, configure, or say no?

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Whether you can distinguish a durable product gap from a one-off request using real evidence and cross-functional judgment.

Gather evidence beyond the one team's ask: check if other planning teams have raised similar needs, and whether the request maps to a documented step in the Joint Planning Process.
Separate three hypotheses: a durable product gap, an integration or data-model limitation, or local change management (the team has not adopted existing functionality).
Involve the right people per hypothesis: other forward-deployed PMs for demand evidence, platform engineering for feasibility, and the requesting team's leadership for adoption context.
Check usage data if available, for example whether the team tried and abandoned an existing feature, pointing to change management over a true gap.
Decide with the evidence: build only if multiple teams show the same durable, technical need; configure if the data model supports it; say no or redirect to training for a local adoption issue.
Communicate the decision and evidence back to both the requesting team and platform engineering.

Names the three hypotheses explicitly and uses a different investigative method for each, not one undifferentiated question.
Uses cross-team demand signals as the deciding evidence, the right lens for a platform serving multiple commands.
Considers change management and training as a real outcome, not just build or configure, showing balanced judgment.
Closes with transparent communication of evidence and decision to both sides, important for military and engineering trust.

Deciding based only on the one team's insistence without checking for a broader pattern.
Treating build versus no as the only two options, ignoring configuration or training.
Not naming who would gather evidence for each hypothesis.

How would you validate demand without over-indexing on a self-selected, more vocal command?
What would you do if platform engineering strongly disagrees the request is durable?
How would you handle a command that pushes back on a no decision?