Most of the risk sits between departments, where everyone is doing their job well and nobody owns the whole picture.
Going into a launch, every department is usually doing its job well: product managing scope against a date, marketing building a campaign from what it was told the product would be, partnerships negotiating terms that depend on an integration landing on time, and engineering making judgment calls about what ships finished and what ships good enough.
Harmonizing across those groups is genuinely difficult, and it tends not to be anybody’s actual responsibility, because everyone already carries a full remit and most teams are stretched thinner than the org chart suggests. Coordination gets left to status meetings, which are where people report progress rather than raise doubt, so what builds up in the meantime is assumptions: each team carries a working picture of the product and keeps moving, and those pictures drift apart slowly enough that nobody notices. The harder version of the problem is that you often cannot see what is missing, because you do not know to ask the question that would reveal it.
What makes the rest of the work possible is settling what the product is actually meant to deliver and to whom, which means not the positioning line or the feature list but the benefit a customer or participant is expected to get and the reason it holds up over time.
The product’s purpose and goals become the grounding everything else can be tested against, so that each department’s picture of the launch gets measured against the same fixed point and any work that does not serve that benefit becomes visible rather than remaining a matter of opinion. Without it you are comparing views with nothing to compare them to, and the loudest account tends to win.
The next step is reviewing the product directly to form an independent view of its state, and then working through the department heads one at a time rather than together, since each of them is looking at the same launch through a different lens and the finished picture only appears when you set those views against each other.
What is worth understanding from each department head:
People rarely volunteer a concern that sits outside their remit when raising it in a group setting would feel like criticising someone else’s work.
None of this is aimed at a perfect launch, which does not exist and is not worth chasing. The aim is to surface the gaps early enough that there is still time to act on them, rather than discovering them in the week the product goes out.
What comes out of those conversations is closer to a living picture of how the teams relate to each other and where their understanding diverges than it is to a checklist. Sometimes what surfaces is a belief shared across several groups that turns out to be inaccurate and needs to be named and addressed; more often it is a gap between what one team expects and what another is building.
And some of what surfaces belongs to nobody at all. The overlap between departments is where a product becomes differentiated in the market, which makes it the most expensive place for a gap to sit. For example, when the economic model is not in conversation with engineering and business development, or when there is no model anyone can rely on, the question has no true owner, and no department shows up as failing because the work was never assigned to one.
Once the missing pieces are on the table the conversation turns to ownership, not in a documentation sense but practically: who can actually do this, and do they have the capacity to do it before the date. Often the answer is no, since people are taxed and there is rarely enough help to go round, which means finding someone who can take it on, supporting the department that needs it so the work actually gets finished, or Electric Gems picking it up directly, which we have done on past engagements. An unowned item assigned to an overloaded person is still unowned.
The value is not the document that comes out of it but the fact that every team ends up working from the same understanding of what is shipping, what it is for, and what state it is in. Sequencing gets considerably easier from there, because the disagreements that would otherwise have surfaced during launch week have already been had and settled while there was still time to act on them.
A short call is usually enough to know whether this is a fit. If it isn't, I'll say so and point you somewhere better.
Tell me what you’re building