Execution Gaps
Gaps are needs nobody serves well. Execution Gaps are the opposite entry point: products that exist, have paying users, and generate a steady stream of frustration. Someone proved the demand. They are just serving it badly.
Gap vs Execution Gap
The distinction matters because they call for different companies. A Gap says nobody has built this: you would be creating a market. An Execution Gap says someone built it and it does not work: the market exists, the incumbent is vulnerable, and the pitch is “like X, but it actually works.”
Under the hood they never overlap. Signals about product quality (reliability, bugs, slowness) are routed to Execution Gaps and kept out of Gap clustering entirely.
Reading the list
Execution Gaps ranks established products by the friction Signals they generate. Each card shows the signal count (how many complaints) and the friction intensity (how angry they are). Related platforms roll up into one card, so a product's iOS and Android complaints count together.
Reading one product
Open a product and its complaints are grouped into distinct weaknesses, because five hundred people rarely complain about five hundred different things. They complain about the same four things in different words. The grouping shows you those four things, each backed by verbatim quotes.
The question to ask of each weakness: is this hard to fix, or just unfixed? A weakness the incumbent has ignored for years despite constant complaints is usually structural. Structural weaknesses are the opening: they cannot fix it without rebuilding, and you get to start from the rebuild.
What to do with one
Treat the weakness list as a validation shortcut. If you are considering a space, the incumbent's Execution Gap tells you exactly what its users would switch for. Cross-check against Gap Explorer: if the same pain also shows up as a market-wide Gap across many products, you are looking at a category-level failure, which is stronger than one bad app.