DIRECT ANSWERComplete fields prove only that format checks passed. Launch readiness also requires distinct scenarios, supported claims, working tracking and review of the final experience.
The plan looked complete at first glance.
Ad groups, headlines, body copy, images, landing pages and links were all present. Length and format checks passed. Each row looked deliverable when opened on its own.
Then I assembled the experience a client or user would actually see. Three groups used nearly the same composition. The copy changed a few nouns but repeated one idea. The logo appeared twice in the final page. One image included a precise match score and a “verified” state that looked like a real product result but had no evidence behind it.
The table passed. The finished work did not.
Field validation can prove that the required pieces exist. It cannot prove that the product is represented truthfully, that several ads test different ideas or that the template and creative behave correctly once combined.
Remove the internal labels and the ads become the same
The plan used different scenario names. Because the team knew what each group was intended to test, it was easy to read difference into the rows.
The user never sees those internal explanations.
With the labels hidden, the final copy, image and destination were hard to distinguish. Headlines and bodies restated the same benefit. The visuals reused a similar person and card composition. The spreadsheet had three rows. The user saw three versions of one ad.
The problem was not the art direction. The test hypothesis had failed to reach the final creative. A scenario becomes distinct only when the user task, product evidence or information priority changes.
When a client says “these images look too similar,” I no longer jump to three unrelated visual styles. I first ask whether the repetition comes from the subject, the product evidence or the copy strategy. Otherwise visual variety only hides the strategic duplication.
A polished image can quietly invent a capability
The image was also making claims.
Characters, result cards, exact scores and certification-like states made the asset feel complete. They also invited the user to assume the product could produce those exact results.
I checked the current website, product material and landing page. The evidence was not there, so the elements had to be removed or replaced with something the product could actually support.
This changed how I handle new claims in feedback. A requested benefit is a question to verify, not an automatic edit. It enters the plan only after the capability, destination and usable evidence have been checked.
Feedback can identify a problem. It cannot serve as evidence for a product claim.
One logo in the source became two in the final page
The logo issue was simple and useful.
The source asset contained one correct logo. The destination template added the brand again. A row-level check still passed because the logo field existed and was correct.
That led to a deliberately basic rule: after copy, image, logo, link and page template are assembled, open the exact result a user will see.
- Without internal group names, are the ads still distinguishable?
- Do headline and body complement each other or repeat one sentence?
- Is every capability shown in the image supported?
- Is the brand duplicated, cropped or distorted?
- Does the landing page continue the promise made by the ad?
The final experience is not a screenshot of the source file. It is a new review object.
“Direction approved” and “ready to launch” are different states
Another issue was hidden in the word complete. Several stages had been collapsed into one status.
| State | What this stage must prove | What it cannot claim yet |
|---|---|---|
| Proposal | The direction is worth discussing | Final creative and tracking are ready |
| Client draft | The client can understand and respond | The plan can be launched immediately |
| Launch-ready | Every launch dependency has been confirmed | Missing items can wait until later |
| Post-launch | Data and actions can be traced | Platform numbers equal business results |
Without explicit state, reviews swing between two failures: applying launch standards so early that useful exploration stops, or accepting a launch because the direction looks reasonable.
Four gates for launch readiness
I turned the repeated failures into four gates: product and scenario, structure and fields, content and evidence, then the final experience and launch dependencies.
The gates are not extra approval theater. Deterministic errors stop early. Human attention stays on product truth, meaningful variation, evidence and remaining risk.
Format errors belong to automated checks. People should spend their time deciding whether the product is understood, whether the scenarios differ, whether the evidence is sufficient and whether the residual risk is acceptable.
Plans arriving from different sources can also be normalized into one structure and sent through the same pre-launch review. A repeated project failure should become a rule, not remain inside one person’s memory.
Why this plan did not pass
The result was not “AI cannot generate ads,” and it was not “the entire plan is bad.”
It could continue as a client draft. It could not be marked launch-ready until the scenarios were separated, unsupported results were removed, the duplicated logo was corrected, and tracking and destination continuity were confirmed.
Passing the gate would still not guarantee performance or platform approval. It would mean only that known dependencies were verified and known blockers had an owner.
I now begin a review with two questions: What state is this work in, and am I looking at the source file or the experience the user will actually receive? If I am still looking at the source, the review is not finished.
Related Writing
PUBLIC NOTEThis article comes from real work. Client details, data and non-public implementation details have been removed.