Daniel sent us this one — and it is deeply practical. He's found that AI-assisted purchase research has a near-perfect hit rate for him, from a vertical mouse to height-adjustable desk legs, and he wants to know how to systematize that. The core question is: how do you structure a product spec prompt so the AI returns exactly what you want, instead of what the affiliate-content internet wants you to buy? And how do you handle the data freshness problem and regional availability — because a perfect product that only ships to Nebraska is useless if you're in Jerusalem.
This is one of those areas where AI genuinely outperforms everything that came before it, and the reason is counterintuitive. Most people think AI is bad at factual tasks because it hallucinates. But product research is different — it's a constraint-satisfaction problem with dozens of dimensions, and AI is exceptionally good at holding all those dimensions in its head at once. A human salesperson can juggle maybe three or four requirements before they start dropping things. An AI can handle thirty.
Which is exactly why the vertical mouse worked. Daniel didn't just say "recommend a mouse." He presumably described his hand size, his grip style, the fact that he wanted vertical orientation, probably a budget, probably a preference about wireless versus wired. And the AI didn't have to skim eight tabs and cross-reference — it just held the whole spec in context and filtered.
And the contrast with Google is stark. There was a study by The Markup in twenty twenty-five — a year after Google's big algorithm update that was supposed to nuke affiliate content farms — and they found that sixty-three percent of top search results for product queries still contained affiliate links. Sixty-three percent. The update didn't clean the well. It just rearranged which affiliates got the top spots.
The SEO equivalent of sweeping the dirt under a different rug.
And the average consumer spends about three and a half hours researching a major purchase across eight or more tabs, according to McKinsey. That's not research. That's triage. You're not evaluating products — you're evaluating which review sites are least obviously bought.
The thesis here is: the bottleneck isn't AI capability. It's how we write the spec. And most of us are terrible at it because we've been trained by Google to type three words and hope.
That's the episode. Let me walk through the specific example that changed how I think about this — the desk legs.
This is the IKEA failure that prompted the whole investigation. He bought adjustable legs — the kind you twist to change height — and could never get them to match. One corner always sat a millimeter high or low, and on a hardwood floor that meant a wobble that would slowly drive you insane.
Here's the thing: the product he bought wasn't defective. It was exactly what it claimed to be — adjustable threaded legs. The failure was in the spec. He didn't know to specify "must not require manual threading to achieve matching height." He didn't know that "locking casters" was even a category of caster. He didn't know that gas-lift adjustment mechanisms existed for desk legs. The implicit requirements were invisible to him until the product failed.
Which is the central problem of purchase research. You don't know what you don't know you need to specify.
That's where AI flips the script. If you give it enough context about your situation, it can surface those unknown unknowns. It can say, "Based on your hardwood floor and the fact that you need precise leveling, you probably want legs with independently adjustable feet, not threaded posts. Also, here are three options with locking casters rated for your desk's weight.
It can only do that if you tell it about the hardwood floor. Which brings us to the framework.
The SPEC framework. S-P-E-C. Situation, Preferences, Exclusions, Constraints.
Sounds like something you'd find in a defense procurement office.
That's exactly where I borrowed it from. Engineering procurement has been doing this for decades — writing formal specifications that vendors bid against. The difference is we're adapting it for consumer use, and the "vendor" is an AI that's searching across the entire internet.
Walk me through it. Start with S.
Situation is the context of use. For the desk legs, it's not just "I need adjustable legs." It's: my desk is a hundred and sixty centimeters wide, it's made of walnut veneer over particle board, it weighs about forty kilos empty and up to fifty-five with equipment, it sits on hardwood flooring in a room with some direct sunlight, the current legs are fixed-height and I want to be able to switch between sitting and standing. That's situation. The AI now knows the physical world the product has to live in.
If you skip that, it might recommend legs rated for thirty kilos, or legs with feet that will scratch hardwood, or legs whose metallic finish clashes with walnut.
All of which happened in the IKEA failure. The threaded legs had small, hard plastic feet that left divots in the wood. Nobody mentioned the floor type in the original search, so nobody filtered for that.
P is Preferences.
This is where you rank desires. And the ranking matters enormously. "Must have locking casters" is different from "would prefer gas-lift adjustment but threaded is acceptable if it has a locking mechanism." You're giving the AI a priority hierarchy. In natural language, you can just say: "High priority: locking casters on all four legs, each rated for at least seventy-five kilos static load. Medium priority: gas-lift height adjustment with a range of at least fifteen centimeters. Low priority: matching walnut finish, but black or dark grey metal is acceptable.
You're not just listing features. You're weighting them, which lets the AI make trade-offs when no product has everything.
And this is where most people's prompts fall apart. They list twenty must-haves, the AI finds zero products that match all twenty, and it either returns nothing or starts silently dropping constraints. If you tell it which constraints are soft, it can tell you, "I found a product that hits all your high-priority items and two of three medium-priority items. The trade-off is that the finish is only available in black.
The must-not-haves. This is the section that would have saved the IKEA purchase. "Must not: require manual threading to match leg heights. Must not: have fixed-position feet that can't be independently micro-adjusted. Must not: use plastic components in the load-bearing adjustment mechanism.
The AI doesn't know you want to avoid those things unless you say so. It assumes you're neutral on threading versus gas lift unless you express a preference or an exclusion.
The exclusion section is also where you block entire categories. "No products from brands with a known history of discontinued parts." "No products that require proprietary tools for adjustment." "No products where the casters can't be replaced with standard M8 threaded stem casters.
That last one is the kind of thing you only learn to specify after the first failed purchase.
Which is why the framework includes an iteration loop — but we'll get to that. C is Constraints.
Budget, geography, timeline.
These have to be brutally specific. Not "affordable" — "under four hundred shekels including shipping." Not "available in Israel" — "must ship to Israel with delivery within fourteen days, or be available from a local distributor with confirmed stock. Flag any product that requires a freight forwarder.
The Israel constraint is a real one. Daniel's mentioned this before — so many AI recommendations fall apart at the shipping address.
That's where the regional variability problem gets acute. An AI trained on mostly US data will happily recommend products from American retailers that either don't ship internationally or charge more in shipping than the product costs. You have to bake the geography into the constraints explicitly, and you should also include it in a system prompt so it persists across the whole session.
What does that system prompt look like?
Something like: "Assume the user is in Israel. Only recommend products available with local shipping or through official Israeli distributors. For any product that requires international shipping, flag it explicitly and estimate the total landed cost including shipping, VAT, and customs. Prefer products available on Israeli e-commerce platforms. If a product is only available on Amazon US, check whether it ships to Israel before recommending.
That alone probably eliminates two-thirds of bad recommendations before the AI even starts searching.
And the budget constraint needs similar precision. "Under four hundred shekels" is fine, but you might also add "I am willing to stretch to five hundred if the product is dramatically better on the high-priority preferences." That gives the AI permission to show you a stretch option without ignoring your budget entirely.
Let's see the before and after. What did the original desk leg prompt look like, versus what it became with SPEC?
The original was probably something like: "Find adjustable desk legs with wheels that I can use for a standing desk conversion." That's it. That's what most people type.
Google would return a page of affiliate listicles titled "Ten Best Adjustable Desk Legs in Twenty Twenty-Six.
Every single one of which would have been written by someone who's never assembled a desk. The SPEC version is more like: "Situation: I have a desk that is one hundred sixty centimeters wide by eighty deep, walnut veneer, approximately forty-five kilograms loaded weight, on hardwood flooring. I want to convert it to a sit-stand desk by replacing the fixed legs with height-adjustable ones. Preferences — high priority: must have locking casters rated for at least seventy kilograms each, must allow height adjustment without tools, must include independent micro-adjustment on each foot for floor leveling. Medium priority: gas-lift mechanism preferred over threaded, black or dark grey finish to complement walnut, at least twenty centimeters of height adjustment range. Low priority: matching walnut finish, cable management clips. Exclusions: no threaded-post designs where height matching requires manual twisting, no fixed casters without locks, no plastic load-bearing components, no brands with a history of parts discontinuation. Constraints: budget four hundred shekels, must ship to Israel within two weeks, prefer local distributors.
That's maybe two hundred words. And it would return what?
In the actual case, it returned exactly one product that hit every high and medium priority, with the trade-off being the low-priority cable management. Not ten pages of results.
Which is what you actually want. You don't want options — you want the option.
That's the paradigm shift. We've been trained to think more results equals better search. But for purchasing, the ideal outcome is a single recommendation that fits your constraints so precisely that the decision makes itself.
We've got the SPEC framework down. But there's a catch — and it's the one that almost derailed the whole desk leg search. The data freshness problem.
This is where it gets interesting. AI training data is frozen at some cutoff date. If you ask a base model for product recommendations without any real-time search integration, it's working from whatever was in its training corpus — which might be twelve to eighteen months old. Products get discontinued. Retailers stop shipping to certain regions. A perfect recommendation from training data might be completely unavailable in the real world.
Daniel's solution was to integrate a search API like Exa.
Exa is fascinating. It indexes over a billion web pages with structured metadata — so it's not just keyword matching, it actually understands that a page is a product listing with a price and an availability status. You can query it for "height adjustable desk legs with locking casters available in Israel under four hundred shekels" and it returns actual current listings, not SEO spam.
How do you integrate that into a prompt workflow?
There are a few approaches. The cleanest is to have the AI first generate a search query from your SPEC prompt, then run that through Exa, then synthesize the results back into a recommendation. You can do this manually — write your spec, ask the AI to extract the key search parameters, paste those into Exa, then feed the results back to the AI. Or you can use a tool that chains these steps automatically. Perplexity's online mode does something similar, though with less structured metadata.
The workflow becomes: write the SPEC prompt, let the AI parse it into search terms, query real-time data, then have the AI evaluate current products against the original constraints.
That evaluation step is critical. The AI needs to explain its reasoning. "I found three products that match your high-priority constraints. Product A hits everything but is fifty shekels over budget. Product B is within budget but the casters are only rated for sixty kilograms, slightly below your seventy-kilogram requirement. Product C is perfect on specs but only ships from Germany with a three-week delivery time. Here's my recommendation and why.
That transparency lets you override the AI's judgment. You might decide the sixty-kilogram casters are fine because your actual load is only forty-five.
Which brings us to the iterative refinement loop. Your first prompt won't be perfect. And that's fine — the framework expects iteration.
How do you structure the feedback?
You treat the AI's first recommendation as a draft. Find what it missed or got wrong. Then feed that back in the same structured format. "That product is out of stock at the Israeli distributor. Please re-run with the same SPEC constraints but add to Exclusions: products not currently in stock at verified Israeli retailers." Or "The casters on that recommendation don't lock in both directions — add to Preferences high priority: casters must lock both rotation and swivel.
Each iteration tightens the spec. By round three, you've usually got something that fits.
Here's the thing — this iteration takes maybe five minutes per round. Compare that to the three and a half hours the average consumer spends across eight tabs. You're getting a better result in a fraction of the time.
Let's talk about the input method, because Daniel raised a good point. Typing a two-hundred-word spec is tedious. Voice dictation changes the economics.
Voice typing averages about a hundred and fifty words per minute versus forty for typing. That means you can dump a full SPEC prompt in about ninety seconds of talking. The friction drops so low that you're actually willing to be exhaustive.
Dictating structure is tricky. You need to signal sections somehow.
You use punctuation commands. Most voice dictation systems support them. My desk is one hundred sixty centimeters wide..." You speak the structure into existence. It feels a bit stilted at first, but you get used to it within a few attempts. And the alternative is typing "Preferences — high priority colon" with your thumbs, which is the ergonomic equivalent of self-flagellation.
I'd also add: record the voice memo, then spend two minutes editing the transcript for structure. Don't try to get it perfect in one pass. Dump everything you can think of verbally, then organize it.
That two-pass approach is exactly right. The first pass is capture — just get every requirement, preference, and exclusion out of your head. The second pass is structure — arrange it into the SPEC quadrants, rank the preferences, tighten the language. The whole process takes under five minutes.
Let's shift to the CRM example, because it's a completely different category of purchase and it tests whether SPEC generalizes.
A business CRM is a perfect stress test. It's software, so there's no shipping constraint, but there are a dozen other dimensions: deployment model, integrations, user count, budget, compliance requirements. The free-association approach Daniel described — "needs contact management, pipeline tracking, email integration" — that's a starting point, but it leaves out everything that actually determines whether a CRM will work.
What does the SPEC version look like?
"I run a small business with five users. We currently manage contacts in a shared spreadsheet and track deals in email threads. We're losing visibility into our pipeline and we're double-entering data. Our tech stack is Linux-based, we use Postgres for our database, and we self-host everything on our own servers. We need a CRM that integrates with our existing email system — which is Fastmail, not Gmail or Outlook.
Already that eliminates about ninety percent of CRM recommendations. Most CRMs assume Gmail or Microsoft integration, cloud hosting, and a Windows or Mac environment.
Preferences: "High priority — must be self-hosted on Linux, must integrate with Postgres as the primary database, must support email integration with Fastmail via IMAP or API, must include visual pipeline management with drag-and-drop deal stages. Medium priority — open source preferred, REST API for custom integrations, mobile app for deal updates on the go. Low priority — built-in quoting and invoicing, marketing automation features.
Exclusions for a CRM would be interesting.
"Must not: require a cloud subscription with vendor lock-in for core CRM functions. Must not: store customer data on third-party servers outside our jurisdiction. Must not: require a Microsoft or Google ecosystem for email integration. Must not: exceed fifty dollars per user per month for five users, total monthly cost under two hundred fifty dollars.
The constraint that would catch most people out — the Linux and self-hosting requirement. That's the kind of thing you only think to specify after the AI recommends three SaaS products that won't work.
That's exactly what happens. The free-association prompt gets back Salesforce Essentials, HubSpot, Pipedrive — all perfectly good CRMs that fail on the self-hosting constraint. The SPEC prompt surfaces things like Twenty, EspoCRM, or Monica — tools that actually fit the environment.
Twenty is an open-source CRM that's been gaining traction. Self-hosted, modern interface, Postgres support.
It probably wouldn't appear in the first page of a Google search for "best CRM." But it's exactly what the spec calls for. That's the power of constraint-based search — it surfaces the thing that fits rather than the thing that's best-marketed.
Let's talk about the "I didn't know I needed to specify that" problem. It keeps coming up.
This is where the AI can actually help you write the spec, not just execute it. Before you even start searching, you can give the AI a rough description and ask: "What am I probably forgetting to specify?" For the desk legs, it might ask: "What type of flooring? What's the loaded weight? Do you need the casters to lock in both directions? Are you in a seismic zone where the desk needs to be anchored?" Questions you wouldn't think to answer until it's too late.
The AI as a requirements elicitation tool. It's reverse-engineering your situation from incomplete information and surfacing the gaps.
This works for almost any product category. For headphones, it might ask about your audio source, your typical listening environment, whether you wear glasses, whether you need sidetone for calls. For a backpack, it might ask about your torso length, your typical load weight, whether you need a luggage pass-through, whether you're in a rainy climate. These are things that experienced buyers in each category know to ask, but first-time buyers don't.
Step zero, before you even write the SPEC, is to ask the AI: "I'm looking for X. What information do you need from me to make a good recommendation?
That meta-prompt alone will save you from the most common failure mode — the underspecified prompt that returns a plausible-sounding but wrong recommendation.
Let's address a misconception that I think a lot of people hold. They assume AI product recommendations are just regurgitated affiliate links from training data — that the AI is basically a Clever clone with better grammar.
That's the cynical take, and it's wrong for a specific reason. When you give an AI a properly structured SPEC prompt with real-time search integration, it's not reciting a review it memorized. It's synthesizing across dozens of sources — product spec sheets, user reviews, forum discussions, compatibility databases, shipping policies — and applying your constraints to that synthesis. It's finding products that don't appear in any single review because no human reviewer has ever evaluated exactly your combination of constraints.
The vertical mouse is a good example. There are probably no reviews titled "Best Vertical Mouse for Someone with Medium Hands Who Uses a Claw Grip and Wants Wireless with USB-C Charging Under Two Hundred Shekels Available in Israel." But the AI can assemble that recommendation from spec sheets, user reviews mentioning hand size, and availability data.
Another misconception: you need to be a prompt engineer to get good results. The SPEC framework is just structured common sense. Anyone can learn it in ten minutes. S — describe where and how you'll use the thing. P — rank what you want, highest to lowest priority. E — list what you absolutely don't want. C — set your budget, location, and timeline. That's it. That's the framework.
It's basically a more rigorous version of how a good salesperson would interview you, if good salespeople still existed for most product categories.
Which they don't, because the economics of retail have shifted to self-service and algorithmic recommendations that optimize for margin, not fit.
There's a third misconception worth addressing — that more detail always means better results. There's a sweet spot, and you can overshoot.
If you specify twenty hard constraints and no soft ones, you'll often get zero results. The AI can't find a product that doesn't exist. The skill is knowing which constraints are hard — "must ship to Israel" is hard, "must be black" is probably soft. And that's why the priority ranking in the Preferences section matters so much. It tells the AI where it has permission to compromise.
I've also seen people get too specific on dimensions. "Must be exactly seventeen point three centimeters tall" — when what they really mean is "must fit on a shelf with seventeen and a half centimeters of clearance." If you specify the clearance rather than the exact height, you give the AI room to find products that work.
That's a great distinction. Specify the requirement, not your guess at the solution. "Must fit in a space seventeen point five centimeters tall" is a requirement. "Must be seventeen point three centimeters tall" is a guess. Let the AI do the solution-finding.
We've covered the framework, the data freshness problem, the iteration loop, and the input method. Let me pull out four concrete takeaways for someone who's never tried this approach.
First: always start with the SPEC framework. Write it out before you open the AI chat. Situation, Preferences, Exclusions, Constraints. It takes five minutes and it transforms your results from hit-or-miss to near-certain. The structure forces you to think through things you'd otherwise skip.
Second: use voice dictation for the initial spec dump, then edit for structure. The friction of typing leads to underspecified prompts. You'll talk for ninety seconds and produce more useful detail than you'd type in ten minutes. Then spend two minutes organizing the transcript into the four quadrants.
Third: always include a must-not-have section. The AI will optimize for your stated desires, but it won't know what you're trying to avoid unless you tell it. The IKEA desk leg failure was entirely avoidable with one exclusion: "no threaded legs that require manual height matching.
Fourth: build a feedback loop. Treat the AI's first recommendation as a draft, not a final answer. Read it carefully, find what it missed, and feed the correction back in. By round two or three, the spec is tight and the recommendation is usually right.
I'd add a fifth, implicit in all of this: ask the AI what you're forgetting before you start. That -question alone will catch the unknown unknowns that would otherwise ambush you after purchase.
Where does this leave us? I think we're at the beginning of a fundamental shift in how we shop — from searching to specifying.
The search paradigm is "I'll know it when I see it." The specification paradigm is "I know what I need, now find the thing that fits." And AI is the first technology that can actually execute the specification paradigm at scale, across any product category, for any set of constraints.
Which raises an open question. Will AI eventually replace product review sites entirely? Or will it create new forms of review fraud — like prompt injection to bias recommendations toward certain brands?
The second one is almost certainly going to happen, if it isn't already. We already saw SEO poisoning for Google results. There will be an equivalent for AI recommendations — product pages and reviews written specifically to match the constraint patterns that AI agents look for. The arms race never ends, it just changes venue.
There's a future implication that I think is under-discussed. As AI agents gain the ability to make purchases autonomously, the skill of writing precise specs becomes even more critical. Your agent can only buy what you can describe. If you're vague about what you want, you're going to get whatever the agent's default assumptions produce — and those defaults might be set by whoever trained the model, or whoever paid for placement.
The specification is the new interface to commerce. It's the difference between saying "buy me a good office chair" and getting whatever Amazon's algorithm thinks has the best margin, versus describing your height, weight, sitting habits, back issues, floor type, aesthetic preferences, and budget — and getting the chair that actually fits your life.
Here's the challenge for anyone listening. Next time you're about to buy something — anything — try the SPEC framework. Record a voice memo with your Situation, Preferences, Exclusions, and Constraints. Feed it to your AI of choice. See if the recommendation beats your own research. I suspect you'll be surprised.
If you're feeling ambitious, try it on something you bought before AI and regretted. See what the spec approach would have surfaced instead. It's a good way to calibrate your own spec-writing skills.
Now: Hilbert's daily fun fact.
Hilbert: In the high medieval period, Azorean whalers discovered that sperm whale ambergris — a waxy intestinal secretion — could be processed into a fixative that turned otherwise fleeting pigments like Tyrian purple into colorfast dyes. The chemistry involves ambrein, a triterpene alcohol that oxidizes into ambroxide, which binds to fabric fibers and stabilizes organic chromophores against photodegradation for decades.
...right.
I now know more about whale intestinal chemistry than I strictly needed to.
This has been My Weird Prompts, produced by Hilbert Flumingtop. If you got something out of this episode, we'd love a review wherever you listen — it helps more people find the show. Find full transcripts and past episodes at myweirdprompts.I'm Corn.
I'm Herman Poppleberry. Go write a spec.
