Verified against ChatGPT · 2026-08-12
Tear down a competitor's UX for one specific flow, not their whole product
Compares your product against named competitors on a single, specific user flow, producing concrete differences that explain a metric gap rather than a broad, unfocused 'what they do better' review.
The prompt
Ready to copy — highlighted parts are example details you can swap.
OUR PRODUCT AND FLOW BEING COMPARED
Our new-user trial signup flow: email -> password -> company name -> plan selection -> credit card -> confirmation.
COMPETITORS TO ANALYZE
Competitor A (direct competitor, similar pricing) and Competitor B (larger enterprise player, different market segment but often mentioned by prospects).
WHY THIS COMPARISON MATTERS RIGHT NOW
Trial-to-paid conversion has dropped 8% over two quarters and we suspect the signup flow itself, not the product, is the cause.
WHAT WE ALREADY SUSPECT IS WEAKER
We suspect asking for a credit card before the trial starts is costing us conversions that competitors avoid by not requiring it upfront.
Scope this analysis to OUR_FLOW specifically and the equivalent flow in each competitor from COMPETITORS — do not expand into a general "how does their whole product compare to ours" review, which produces a report too broad to act on. For each competitor, walk their equivalent flow step by step the same way you'd audit your own product, noting at each step what's structurally different (fewer steps, different information order, a decision deferred to later versus asked upfront) rather than surface-level visual opinions ("theirs looks cleaner") that don't translate into an actionable change.
For SUSPECTED_WEAKNESS, check specifically whether the competitors actually address it differently or whether the suspicion doesn't hold up under a real side-by-side comparison — do not simply confirm the suspicion because it was suggested; if a competitor's flow has the same weakness or a different one entirely, say so plainly rather than finding evidence to fit the assumption.
After the step-by-step comparison, identify patterns that repeat across more than one competitor (if two or more independently made the same structural choice, that's a stronger signal than one competitor's one-off choice) versus a single competitor's idiosyncratic approach that may not generalize as a lesson. Tie every recommendation back to COMPARISON_REASON — a difference is only worth acting on if it plausibly affects the specific metric or problem that motivated this comparison in the first place, not every difference that exists.
WHAT NOT TO DO
Do not produce a feature-checklist comparison table ("they have X, we don't") as the primary output — that format flattens structural UX differences into presence/absence checkboxes and misses the actual reason a flow performs differently. Do not recommend copying a competitor's approach wholesale without checking whether the surrounding context (their user base, their business model, constraints they operate under) actually transfers to our product.
OUTPUT FORMAT
1. Step-by-step comparison table: step in our flow | equivalent step per competitor | structural difference noted.
2. Whether SUSPECTED_WEAKNESS held up, partially held up, or didn't hold up, with the specific evidence.
3. Patterns that repeat across 2+ competitors vs. single-competitor idiosyncrasies.
4. Two to three recommendations, each explicitly tied back to COMPARISON_REASON, with a one-line note on what context might not transfer from the competitor to us.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Scoping the analysis to one named flow rather than "the competitor's product" prevents the default shape a broader prompt produces — a wide-ranging, feature-by-feature comparison that reads as thorough but has no single actionable thread running through it, because a model given room to compare whole products will treat every difference as equally worth mentioning rather than concentrating on the one flow that actually matters to the business question at hand. Requiring the suspected weakness to be genuinely checked rather than confirmed by default counters a specific and common drift: when a prompt states an assumption ("we suspect the credit-card step is the problem"), a model without an explicit instruction to test rather than validate it will tend to find supporting evidence for the stated hypothesis, because agreeing with a stated premise reads as more helpful and coherent than contradicting the user's own framing — an instruction to say plainly if the suspicion doesn't hold up is what keeps the analysis honest rather than confirmatory. Distinguishing a pattern that repeats across multiple competitors from a single competitor's idiosyncratic choice matters because not every observed difference is a lesson — a change that only one competitor happens to have made could easily be a mistake or an artifact of their specific business model rather than a validated best practice, and treating every observation as equally instructive is how competitive analyses end up recommending changes that don't actually transfer. The explicit warning against copying an approach without checking whether surrounding context transfers addresses the single most common way competitive UX recommendations fail in practice: a structural choice that works for a company with a different user base, sales motion, or price point can make a real product worse if adopted without that context, and a model isn't naturally inclined to flag that mismatch unless told to check for it.
What you get back
Suspected weakness check: partially held up. Competitor A does defer credit-card entry to end of a 14-day trial (matches the suspicion); Competitor B still asks for a card upfront but only after showing a personalized setup step first, suggesting the actual lever may be sequencing/perceived value rather than the card requirement itself. Pattern across both competitors: both defer plan selection until after the user has seen the product working with their own data, which our flow asks for before any product interaction — flagged as the stronger, repeated signal worth acting on first.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
