Facilitates the second step of a proven ideal-customer (ICP) method: distilling raw company observations into the few deep-truth attributes that matter, then classifying each as a strength, a weakness, or deliberately both. Takes an observations list (O1, O2, … — file or pasted), proposes attributes

Strengths & Weaknesses: The Attributes That Matter Raw observations are evidence; strategy needs a verdict. This skill turns a pile of honest facts about a company into a short chart of classified attributes — the strengths a future ideal customer will love you for, and the weaknesses she'll either tolerate or be repelled by. Two moves, in order: distill the observations into the few deep truths underneath them, then classify each one with a rubric that resolves the paradox that almost anything can be argued either way. The mental model Observations → deep truths The facts we notice are usually consequences of something deeper. "Customers post screenshots on Reddit of long ticket wait times" reveals the attribute "slow tech support." "Customers brag by posting side by side screenshots next to a competitor" reveals "delightful, remarkable design." Distilling asks of each observation (or cluster of observations): what deep truth about the product and company does this reveal? Fewer, stronger attributes beat many weak ones — a smaller set is easier to hold in mind, easier to act on, easier to set in stone. Merge observations that point at the same truth; drop ones that point nowhere. The genericness trap and the Opposite Test The fatal failure mode of distillation is generalizing an attribute into banality. "We love our customers" is so generic that nearly every company says it (even when it's false) — it's not actionable and it will never create the edge that separates an ideal customer from everyone else. If the truth is that you go above and beyond, the attribute cites the mechanism: "any employee can spend up to $2,000 to fix a customer's problem without approval." If the truth is genuine relationships, it's "quarterly business reviews with every account; only knowledgeable humans answer the support line." The gate is the Opposite Test : construct the claim's opposite and ask whether any successful company would rationally choose it. "Easy to use" fails — nobody claims "difficult to use." "Transparent, simple pricing" passes — enterprise software is proudly call for pricing, and the top clouds thrive on pricing so complex that entire companies exist to manage it. An attribute that fails the Opposite Test is not recorded, in any form, however warmly the user feels about it — there is always a specific version of a true attribute, and finding it is the work. (One sanctioned exception, from the source: a claim whose opposite nobody would say can still pass when you dominate the field on it by a wide margin — "four times faster than the competition, measured" is a real attribute even though nobody claims "slow." The domination must be specific and large, not vibes.) For a weakness shaped attribute — an absence or a shortfall — the test runs mirrored: is having the thing a real strategy someone proudly pursues? "No scheduling module" passes because best of breed vendors deliberately don't bundle and bundlers proudly do — the absence is a genuine position, not filler. "Our website has typos" fails; nobody strategizes toward typos, so it's a defect note, not an attribute. The classification rubric Whether an attribute is a strength or weakness is entirely in the eye of the beholder — "inexpensive" attracts price conscious buyers and repels serious ones. So the call is made with two concrete questions: 1. Strength — is at least one of these true? a. More than one third of the market considers this a strength. b. Some customers love or need this so much they will buy for this reason alone. 2. Weakness — is at least one of these true? a. More than one third of the market considers this a weakness. b. For some customers this makes the product impossible to use; they will refuse to buy for this reason alone. Typically only one comes up yes: a lightning fast interface is a strength (1a) and nobody calls it a weakness. Lacking security certifications is a weakness (2b) even though most of the market doesn't care. But two other outcomes matter just as much: Yes to both → the attribute is both , listed in both columns and flagged: different market segments disagree about it, which means a clear strategic choice is waiting ("one hundred features" is completeness to some, bloat to others — you will eventually have to pick whom to please). These are the most useful attributes to find, not a problem to resolve away. No to both → nobody cares. The attribute is dropped — recorded in a cuts list with one line of reasoning, so attention stops going to things without an audience. Aspirations are not attributes The observations file often contains say we're great but aren't entries (claimed reliability with a record of outages, "seamless integrations" that are nightly CSV jobs). These classify by the record , not the claim: the underlying truth is usually a weakness candidate ("integration breadth is claimed but shallow"), never a strength. The wish itself may be strategy input later; it is not an attribute of who you are today. Vocabulary Attribute — one distilled deep truth about the company or product, worded specifically enough to pass the Opposite Test. S1, S2, … / W1, W2, … — classified attributes; a both attribute carries a number in each column, cross referenced. Both — yes to both rubric questions; flagged as a pending strategic choice. Cut — no to both; dropped with its reasoning on the record. [O numbers] — the observations an attribute distills; every attribute cites its evidence. The classifier's posture Be clear, not clever Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it. Restate references; never cite a bare token When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss. Propose from evidence; the user corrects Unlike gathering (where inventing content poisons the file), distilling is analysis of evidence already on the record — so here you may propose freely: read the observations, cluster them, and offer one candidate attribute at a time with its [O number] citations and proposed wording. But the user corrects and confirms each one — they know which reading of the evidence is true — and batch nodding is declined; every attribute earns its place individually. Where the observations support two different distillations, show both and let the user pick. The Opposite Test is not negotiable A generic attribute never enters the file, however the user insists — "it's true though" is not the bar; distinctive is the bar. Run the test visibly on every candidate, including your own. A predefined way to press harder: if a devil's advocate interrogation skill is installed in the environment (for example Rude Q&A / asb rude qa , from the same author as this method), invoke it against the draft attribute list with this brief: attack these attributes — find every entry whose opposite no successful company would claim, every one too generic to separate an ideal customer from everyone else, and every one that flatters an aspiration rather than describing the record; don't accept vague or wishful defenses. If no such skill is available, run that interrogation yourself, visibly. Timing: the per candidate test happens inline before anything is recorded; the delegated (or self run) batch attack is the Phase C re pass over the whole chart. The refusal is always of the generic wording, never of the underlying truth — keep offering sharper rewrites until one passes. Classification is the user's call, made against the rubric You supply the rubric, the evidence, and a candidate answer; the user supplies market judgment ("would a third of our market see it that way? has anyone ever bought for this alone?"). When the observations themselves answer a rubric question — a cancellation email is buy/refuse for this alone evidence — cite it. When the user's call contradicts their own evidence file, make them defend it once ("O5 says two customers canceled over this; you're saying nobody would refuse for it?"), then record their call — with one carve out: the craft rules outrank the deference. An aspiration never classifies as a strength against the record, a generic wording never enters, and a both never collapses into one column, however the user insists after the defense; those are the gates that make the chart mean something downstream. Never leave an attribute unclassified to avoid the argument. One attribute per exchange Propose it, cite it, test it, classify it, record it — then the next. Never a wall of candidate attributes. The opening move is small: what was read, roughly how many attribute clusters you see, then the first candidate. If the user asks to speed up, compress ceremony (shorter displays, token confirms for obvious ones), never structure. Park downstream discoveries; don't solve them here Distilling surfaces things that belong to later steps — a weakness so absolute it reads as a deal breaker, a trigger that clearly incites a purchase, a market segment worth remembering for the keystones. Don't chase them: this step classifies attributes, not deal breakers, inciting events, or keystones, and solving them here muddies the chart. But don't lose them either. Record each in a dedicated Notes for downstream steps section — one line, tagged with the step it's for — kept strictly separate from the strength/weakness attributes so the chart stays clean and the finding still travels forward. When the user surfaces one, acknowledge it, park it there, and return to the attribute at hand. (This is distinct from the strategic notes idea: those are true but not customer facing facts about today ; these are findings addressed to a future step of the method.) How to use this skill Phase A — Ingest Read the observations (default: OBSERVATIONS.md in the current directory; or pasted). Note the context preamble — it carries the company background — and the side list, which stays untouched. If no observations exist at all, don't distill from nothing: offer the honest on ramp — either run the gathering step first (if an observation gathering skill from this method's author is installed, for example Observations / asb carol observations , name it), or capture a quick in chat set now, holding the same specificity bar, with the caveat that a thin base yields a thin chart. For the quick capture: three prompts cover the loudest ground — what customers actually praise (a quote, an incident), the complaint you have no defense against, and what separates your best customers from your worst. Number the captures O1, O2, … as they settle, offer to write them to an OBSERVATIONS.md so a later full gathering pass appends rather than restarts, and note in the chart's preamble that the base came from chat. The Phase C size guidance doesn't apply to a thin base — two strengths from six observations is honest, not undersized. If a STRENGTHS WEAKNESSES.md already exists at the target location, read it: an in progress header means resume — pick up where it says, don't re litigate settled attributes. Marked complete means ask whether to revise or replace. Output location: STRENGTHS WEAKNESSES.md in the same directory as the input file. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current dire

asb-carol-strengths