The first review said the funnel has no top. The third wrote: “Do not lead with MCP or cross-vendor portability. Both are materially less validated than the strategy assumes.”
I read the verdicts as one complaint: we had built something on top of assumptions about customers that nobody had tested.
A plan like that can read as finished, tangible enough that you could hand it to someone and they’d believe it was already decided. That’s the trap. A prototype that looks finished starts to feel true.
That’s the cost of a convincing plan. Not money out the door, but the harder kind: time spent making a plan look right before checking whether it is.
What “no top of funnel” actually meant
The first reviewer’s line, that the funnel has no top, sounds abstract until you translate it. The document treated the blog as the top of the funnel, and the reviewer called that the thing we were most wrong about.
The third reviewer’s point was the same shape of problem from a different angle. A technical fact that sounds like a selling point still has to be checked against what a customer cares about.
I read both as one root cause: confidence where there was little evidence.
Why ask several readers at once
The useful move is to stop asking “does this sound right” and ask several readers “what’s wrong with this” at the same time.
The slower, less satisfying fix is to ask actual people whether the assumptions in a plan are even in the neighborhood of true, before writing one more page that depends on them.
The prototype wasn’t wrong because it was badly built. It was wrong because it was persuasive before it was tested, and persuasive is exactly the quality that makes you stop checking.
AI Skills
Use this lesson with the AI assistant you already use
Three independent AI reviews of dxdev.com's positioning plan converged on the same flaw within minutes: its funnel and swappable AI engine headline relied on customer behavior that had never been checked. The team stopped building more pages and returned to asking actual people whether those assumptions were true.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Validate Customer Assumptions Before Polishing a Persuasive Prototype
SOURCE: dxdev.com/blog/2026-09-08_prototype-validation-over-build
WHAT HAPPENED: The team built a detailed positioning prototype for dxdev.com, including a visitor path, case studies, and a pitch about being able to swap underlying AI engines. Three AI systems reviewed the same document independently and each identified an unvalidated assumption about what customers would do or value. The plan assumed readers would discover the service through the blog, even though no one had confirmed that path. It also treated the swappable-engine detail as a headline benefit without evidence that prospective customers cared about it. After the reviews converged, the team shelved further prototype work and began validating the assumptions with actual people.
THE RULE: Before expanding or polishing a prototype, test every customer behavior and value proposition assumption that later pages depend on. Treat a prototype's persuasiveness as a reason to seek evidence sooner, because polish can make an unproven premise feel settled.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Can you point to direct customer evidence that the acquisition path assumed by your funnel actually occurs?
2. Can you identify which headline claims have been confirmed as important by prospective customers, rather than only sounding compelling internally?
3. Have independent reviewers been asked to identify the plan's underlying assumptions before additional downstream work is built?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.